[CF-Devel] Materials (was FW: DIAMONDS)

[crossfire-devel-admin at archives.real-time.com]

Todd wrote:

  Just a note, I think you are confused by what I mean when I say 'artifacts'.

  There are two types of artifacts in crossfire:

'true' artifacts are things like bonecrusher, darkblade, defender.  Objects 
which have a specific archetype entry, and specific entries on the treasure list.

'random' artifacts.  These are things like the 'of zormola' or 'of lythander' 
objects, and are controlled by the lib/artifacts file.  These random artifacts 
may not in fact be suprerior items, as witnessed by the 'of mass' and 'of great 
mass' objects.  In retrospect, calling this file artifacts was a terrible idea, 
but I didn't code it (I actually don't have a better name for it off the type of 
the head, but since the file is caleld artifacts, it only creates confusion when 
the word 'artifact' is used).

  In all my discussion in this thread about 'artifacts', I'm talking about 
random artifacts above.

>>
     
      ...
     
     >>
     
       Or do you just mean convert the material file to archetypes (which 
     
     >>
     
      wouldn't be hard), and have a special material type to denote this 
     
     >>
     
      (sort of like skills are now).  Thus, instead of having yet another 
     
     >>
     
      file format, you could just have a 'materials' directory in the arch 
     
     >>
     
      to customize/add new materials.
     
     >
     
     
     >
     
     
     >
     
     
     >
     
      That was my thought, yes.  Skills as archs, spell arches, ability 
     
     >
     
      arches, treasure lists arches (kind of like the random map styles are 
     
     >
     
      now...),  material arches....
     
     
  I actually think this is a pretty good idea. The only thing currently in the 
'materials' file that won't transfer is the saving throw values.  So you'd now 
need to copy in saving throws into the object structure, or find some other 
clever way to handle that.

  As a note, if materials were done in this way, rather than the object 
containing the material, it'd probably just be easier to have an 'object 
*material' pointer.  However, you'd actually need to use something like 
objectlink pointer if you plan to have more than one material in an object.


>
     
     
     >
     
      This is where I was imagining inheritance played a part.  General class 
     
     >
     
      characteristics inherited by the specific materials so you don't need to 
     
     >
     
      configure every little setting (but you could...).  Note imagine is the 
     
     >
     
      operative word since this was speculation on my part.
     
     
  I'm not sure how this work.

  At one level, I could see something like tree >> spear >> club >> arrow.  IS 
that what your talking about?

  Even that, isn't a perfect method.  A spear can't be converted to a club and 
vice versa (at least not in real life).  This is sort of say I want to convert a 
2"x4"x72" beam into a an 8.3" x 8.3" x 8.3" cube of wood.  It just doesn't 
really work that way (ok, maybe with enough glue or whatever).  but 
structurally, you see the point.

  I'd also think that such inheritence would just be even more confusing.


>
     
      Ya, but you could also have monsters turning gold to lead or steel into 
     
     >
     
      tin.  I knew steel to gold would be a provocative example, but it would 
     
     >
     
      work both ways.  Plus you can make these things prohibitive - iron to 
     
     >
     
      gold abilities would be a heck of a lot less common than the steel to 
     
     >
     
      tin abilities.  Remember the disenchanter beast?  How about a little 
     
     >
     
      fellow that turns sangunite to lead?
     
     >
     
      I know you can do this otherways but, it nice when it's as simple as 
     
     >
     
      twigging the material.
     
     
  You could have some monsters do that I suppose.  However, IMO, the ability to 
balance that is close to 0%.  The real problem is how do these abilities work? 
If it is jus a matter that it is hard for a player to learn the lead to gold 
ability, that might sound good, but once he learns it, things are really screwed 
up.  I suppose you could make this ability only appear in the scrolls.  That 
might be interesting then..  Hmmm, I have a 'steel to mithril' scroll.  Having 
this steel sword be mithril might be nice.  And if the value/cost of these 
scrolls was more than the likely value you'd get from the item, no big issue there.

  I'm not sure to really put this as monster abilities. That rust monster should 
live up to its name, and really rust items (as of now, it just attacks with 
acid).  Only material that really rusts being iron and steel.  Thus, having the 
bronze armor/weapon in this case could be useful.  However, you'd also need 
smarter monster logic - imagine that rust monstering wandering around, and if he 
steps onto a space with iron, he'd eat it (rust it out).  So imagine a player 
coming into a dungeon, and seeing that there is no iron about, but plenty of 
bronze and tin and whatever else items.  HE may get some clue.

>
     
     
     >>
     
       One could certainly do something like that - to follow AD&D, warp 
     
     >>
     
      wood - checks inventory of target, and warps some number of wood 
     
     >>
     
      objects, making them unusuable.  However, for this to really work, you 
     
     >>
     
      then need to have some method of saying these are warped.  Things like 
     
     >>
     
      heat/cool metal are a lot trickier to track. 
     
     >
     
     
     >
     
     
     >
     
      Not really you don't have to actually have heat or cold, just assign an 
     
     >
     
      amount of damage per measure of iron.  Now you want to wear that plate 
     
     >
     
      armour when fighting fire elementals Pepe?
     
     
  But a little trickier - you somehow have to know that the fire elemental can 
heat that armor.  Is this a spell like ability, or happens if you just stand 
next to it (does anything that attack with fire do this?) And how often do you 
make this check.  It can certainly be done, but I'd not consider this an easy 
change.


>>
     
       There is no harm listing artifact combinations in the file that can't 
     
     >>
     
      possibly exist. 
     
     >
     
     
     >
     
     
     >>
     
       And if you don't, all that really happens is that your object won't 
     
     >>
     
      appear with these new special abilities/materials.  Your item will 
     
     >>
     
      still continue to work.
     
     >
     
     
     >
     
     
     >
     
      no but it does get messy over time and you need to get into the server 
     
     >
     
      files to make maps
     
     
  No more than right now. (eg, if you want to add a new archetype, you need to 
get onto the server to make that entry). the random artifact code really only 
works for archetypes, so if you add one, add the artifacts entry for the other 
(if appropriate).  This is no different than adding the image and treasure for 
your new archetype also.


>
     
     
     >
     
      That's interesting, material bonuses should be applicable for what ever 
     
     >
     
      object they constitute.  I didn't think of an example like this.   
     
     >
     
      Either this type of bonus has to be taken out of the material code so it 
     
     >
     
      works universally or pseudo-logic can be applied to say that Yew is 
     
     >
     
      lighter but harder thus more the club weilder is more nimble, thus more 
     
     >
     
      damage (since damage can be seen as factoring in chance to hit as well 
     
     >
     
      as actual injury).
     
     
  I think we're talking past each other right now.  As the code stands now, the 
material bonus is universal.   yew wood gives a +2 damage bonus for any weapon 
that gets made out of it, whether that weapon is a bow, club, spear, axe, etc. 
To me, that is wrong.

  Another case - lead has a -2 damage penalty.  That is reasonable to see in the 
case of things like swords - lead can't keep a sharp edge.  But for things like 
sling bullets (if they existed), or hammers, lead should probably cause more 
damage (heavier weight = more damage in those cases).  As the code stands now, 
there is no way to make that distinction - it just says that anything made of 
lead has a -2 damage bonus.

  Just as a nit, I have no idea where Tim got his weight allowances for 
materials - they certainly don't match real life (platinum is more dense than 
lead for example)


>
     
     
     >
     
      But if the artifact file randomly changes the items randomly after the 
     
     >
     
      map has been created (when somone enters it presumably) then you have no 
     
     >
     
      control over specific implementation.  In this case if you wanted a ruby 
     
     >
     
      club particularly how would you do it without creating a new arch?
     
     >
     
      Of course you could claw back some of those sort of bonuses from 
     
     >
     
      material type while leaving basic modifiers such as value, weight and 
     
     >
     
      saving throws.
     
     >
     
      Really I haven't got an answer for this - there seems to be a 
     
     >
     
      particle/wave thing going on here.
     
     
  That is true.  Of course, that ruby club example doesn't work right now either.

  Presuming we have some way to know if the item has been processed, or needs to 
be processed on this load, I'd suggest this (presuming we know the object needs 
to be processed):

  First, the code would look to see if there is a random artifact entry for ruby 
clubs.  Presumably it doesn't find one.  So it then falls back to the basic 
properties of ruby, and applies that.

  This may not be as perfect.  OTOH, this case is less a concern to me.  IF the 
mapmaker really wants it accurate, he can override the values appropriate and 
set the 'don't process me special' flag so the server ignores the material 
stuff.  Since a ruby club would never show up randomly, how the user customizes 
this is not a big concern.

  I'm much more concerned about the cases like 'mithril sword' vs 'steel sword'. 
  Since mithril swords may very well show up randomly, I'd want any that are 
specificly set that way in a map by a designer to get created just as if it was 
a random object, so it merges and otherwise behaves properly.



>
     
      See I would tend to never actually have a general material used in an 
     
     >
     
      object. This is why I suggested changing iron to metal and such.  The 
     
     >
     
      material would always be specific.  You could have an item with no 
     
     >
     
      material, but never an item of 'wood' (it would always resolve to be a 
     
     >
     
      type of wood) for example.
     
     
  That's fine.  But in that case, I don't see any harm in saying 'random_wood' 
or 'random_metal' vs just wood or metal.  It is much clearer what is happening 
when you say 'random_wood'.

  Otherwise, you also get the confusion of something like 'is paper a specific 
material or not?'  As of now, it is - there is only 'paper', and not things like 
velum or parchment.  So if you had 'random_paper', as of now, you'd always just 
get it turned into paper.

  But suppose down the road you add 'velum' and 'parchment'.  What used to be a 
specific meaning is now generic.  Something of materialname 'paper' would now 
get turned into velum or parchment (and presumably, 'paper' is still a valid 
specific entry for things you write on).  You don't have any of these problems 
if you prefix the materialname with random_ if you want it randomized.

  you also have cases right now where the generic name may also be the final 
result.  Bone is an example.  It is a generic name, but can also be the final 
name (there is only about a 30% chance of bone material not showing up as bone). 
  So how do you differentiate that of 'I really mean this item should be made of 
bone and not randomized'.  Prefixing the random_ once again fixes that.


>
     
      Ya, it would be a lot of work for sure making a standard 8 bit palette 
     
     >
     
      and redoing most of the arches to use it - I didn't imagine I would live 
     
     >
     
      to see it.  Then again if we implement a standard 8 bit pallete now for 
     
     >
     
      new graphics, some day our grandkids will thank us for it.
     
     
  As said, I just can't see much advantage to that over just making unique 
images for the different colors.

  If we got to the point where enough of the images were done in enough 
different colors to say 'we really need a better method for this', then I might 
change my mind.  But given the work needed to do palletized images (simply put, 
A LOT), I can't see doing this.  And since seperate images give all the same 
benefits (it looks different) with almost none of the work, it is a sure term win.

  And I'd bet that down the road, if we did decide to go to palletized images, 
I'd expect that there could be tools which would take 5-6 images that are the 
same except for colorization and convert them into a palletized image.

  But even then, it is unclear why this is better.  Most likely, even in this 
case, the client might still decide to render the image once and not at each 
draw.  So in this case, it would just render 6 images (or whatever) - one image 
for each pallette.

  The only real advantage woudl be that palletized images would presumably take 
less space than a unique image.  But as time passes, even that becomes less and 
less and image (bandwidth increases, disk space increases, etc.)



>
     
     
     >
     
      Ya lowest.  The other can of worms would be related to item 
     
     >
     
      deconstruction of which I know only rumours...  Wood ash is a prime 
     
     >
     
      ingrediant in some recipies, there are examples of other items which 
     
     >
     
      have partially survives massive trauma (
     
     
  Well, it would be nice to somehow denote what happens to the object when 
destroyed.  But this gets tricky.  While wood ash makes sense if the object is 
incinerated, if the object is destroyed by acid, you shouldn't get that. 
However, to list all the combinations is probably not possible.

  But therefore denoting what this object turns into could be interesting.  As 
well as perhaps what portion survives (eg, wood -> ash, you'd lose a lot of 
mass, presuming you can collect all that ash.  metal -> melted metal, the mass 
would be near the same, its just now in a less useful form (that iron sword 
turned into a 'melted mass of iron'.)

  We'll ignore the issue that if you melt tin and copper, you should really get 
a pool of bronze - trying to figure out those mappings is another can of worms 
not worth dealing with.


>
     
      Well this tree arch in question would have had a materialname set when 
     
     >
     
      it was placed (by man or machine).   If it was set to 'wood', you would 
     
     >
     
      get a random wood, if it was  set to 'oak' - you would get oak.
     
     
  Ok.  Presumably, the random map/herb code could also make adjustments.  Eg, 
growing conditions say this is good for oak, so let me set that material name. 
Over here, growing conditions are good for pine.

  This is trickier for the mountain spaces - presumably you should be able to 
mine some of the metals as well as some of the stones.  However, weather doesn't 
really play into that - I guess some small number of mountains could get turned 
into quarries/mines.  Ideally, over time, you might want thse to move around 
(eg, just don't always go to X to mine mithril).'


>
     
     
     >
     
     
     >
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel