[crossfire] Materials

[Mark Wedel]

Nicolas Weeger wrote:
> Hello.
> 
> I'd dug some in the material code, and it is quite messy. But I'm not sure how 
> to fix/change it.
> 
> Here is how it works.
> 
> Material is used for saving throws against attacktypes (against fire, 
> ice, ...).
> When NEW_MATERIAL_CODE is defined, material will also affect an item's 
> resistances, damage, speed, wc, ac.
> 
> There are 2 related fields, "material" which is a bitmask and "materialname" 
> which is a string.

  Yes - the bitmask is the old/original code, and materialname came later as a 
more flexible material system.

> 
> lib/materials contains a list of materials, first "regular" materials (which 
> all got neutral resistances / modifiers), then special ones (with special 
> resistances / modifiers).
> Each material type (metal, dragonscale, ...) corresponds to a type, check 
> include/material.h (M_xxx) for their values.
> 
> If "materialname" is NULL, it is initialized with a material 
> matching "material"'s bitmask.
> When NEW_MATERIAL_CODE  is defined, this material "incarnation" is chosen 
> randomly based on map's difficulty and item's magic (thus having a material 
> of 2 can translate to iron, silver, gold, lead, steel, ...).
> When NEW_MATERIAL_CODE is not set, the first matching material is used (thus 2 
> will always do iron).

  Yes - the reason this was added is that having a huge number of different 
materials really got annoying.  Instead of having say 6 shortswords non merging 
shortswords like you do now if you clear out a dungeon (those six being 
different in some way - a couple may be cursed, 1 would be normal, a few magical 
of different ways, etc), you'd have like 20, because in addition to those 6 
types above, you'd get bronze, steel, iron, etc.  And so now you got really long 
list of items and it just proved more annoying.

> 
> So the plan is obviously to fix multi material handling - and for instance use 
> a random material for saving throws, the hit can be on a "random" part of the 
> item.
> Keeping specific saving throws seems logical, since gold doesn't behave like 
> iron for instance (but they got the same "material" value, 2).
> 
> 
> The 2 things I'm wondering whether to keep (and maybe enable?) or remove 
> totally are:
> * random material choice if not set.
> * resistances / stats modifier
> 
> 
> Activating this could lead to more random items, and interesting combinations. 
> Current eg resistance modifiers in the lib/material aren't that important 
> (around -5 to 5), but could add variety to items.
> On the other hand, it would introduce quite many different items, non merging, 
> things like that.

  Which is why in most cases it is turned off.

  I think different materials are interesting, but I also think some better for 
of what gets created is needed.  Having a pine arrow and oak arrow is fine, but 
if the only difference is that the pine arrow is 5 grams lighter, who really 
cares - in that case, it becomes a bother.  And that is generally what is was 
with the material system in place.  A problem is that material can apply to 
everything - thus, anything made of iron could now become made of any of the 
'metal like' materials - that is fine in one way, but for some items, it makes 
no effective difference, because the adjustments don't apply (a material that 
gives extra armor benefit I believe has no effect if applied to an item that 
doesn't have any armor value in the first place, like a sword).


  I think in the past there was some thought to basically add material 
transmutation into the artifacts file, since that does provide a good level of 
control.  Thus, you could limit it to things that make sense (that steel sword 
does 1 more point of damage than that iron one).  Doing that in itself isn't 
hard - I think the slightly harder part was some logic about having it be too 
pass or reentrant was need - you should be able to get a steel sword of 
lythander for example, but right now, the artifact processing will only do one 
artifact type.

  IT may be to do something like this in the material file - similar format 
(which is nice - you can then dictate what steel armor gives vs steel weapons) - 
it could perhaps even use the same parsing/naming structure, as well as odds, 
but put the data into a seperate array.  So basically, it does a treasure. 
First, it calls the material code to see if it should change material, and after 
that (regardless of any change), it then calls normal artifact processing.