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. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
