Re: [crossfire] Materials
Hello. Considering the global response, I've removed that code, and associated data from the file (but leaving extended material in case someone wants to have fun with it). Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Materials
On 06/26/11 05:28 AM, Nicolas Weeger wrote: Hello. In the code is support for NEW_MATERIAL_CODE. Enabling it randomizes the material for many items, leading to proliferation of items with different materials and properties (more damage to weapons, different resistances, and such). Material support is half-written for multiple combinations (iron + paper for instance), but not totally everywhere. I wonder whether to enable that (extended material) support by default and fix issues, or totally remove it. Leaf did pretty well summarize the issues, but there was another annoyance I found with it: For most items, the material made very minor difference. So following on Leaf's example, no only would you have 6 different boots of speed (instead of them stacking), but save for maybe 1 point of resistance here or there, or one being a little bit lighter, they were all basically the same. So you got a lot of inventory clutter for very little gain. And the way the code work, it would find something of 'iron', and then randomize the material for all the things that could be iron. Some materials might make a difference for armor, but not weapons, and vice versa, but the material code itself had no way to restrict that. so you would have 6 times of metal armor, with maybe only one or 2 of the materials being different enough to really care about. So I would say that the material logic could be removed. If one was to improve it, these are my thoughts: 1) Make it more like the artifact code, where one can restrict it to different items. Thus, a yew bow may be really good, so you would find normal wood bows and the better yew bows, but wouldn't find pine, spruce, etc. OTOH, this starts to look like just another stack of item bonuses, and is it worth it to do it via material instead of just making some bows better and in the description say they are made from yew? 2) Ability to regionalize materials. It might make perfect sense in the area far to the north where only pine trees grow that the vast majority of wooden items would be pine, in a jungle area, bamboo, etc. That would sort of eliminate some of the stacking problem - since you would typically do your adventuring within an area and then go to the shop to sell at once, most of your items would be made from the same local material. But even then, I would have to ask if the changing of materials really gains that much? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Materials
Hello. In the code is support for NEW_MATERIAL_CODE. Enabling it randomizes the material for many items, leading to proliferation of items with different materials and properties (more damage to weapons, different resistances, and such). Material support is half-written for multiple combinations (iron + paper for instance), but not totally everywhere. I wonder whether to enable that (extended material) support by default and fix issues, or totally remove it. What do you think? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Materials
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wonder whether to enable that (extended material) support by default and fix issues, or totally remove it. What do you think? What I found to be irritating about the material code was it made inventory management much more annoying. Specific example was Boots of speed. Instead of have (let's say..) a stack of 6 boots, you would see all individual boots because they were all made of different material (leather, snakeskin, etc.) So, only way to see that items were made of different materials is to have them show up individually in your inventory or item stack. On a side note.. As I recall, the intent of the original author was to deploy a questing system where a NPC would ask for something like a gold dagger and then the player would provide that to get a new item request (i.e., granite stone axe.) I personally liked such a concept, but not enough to really want to endure the issues it causes and mentioned above. So, unless some new ways to deploys this can come together, I would vote for removing this feature. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOB4avhHyvgBp+vH4RArETAKCN1W9+ZiR6VWXgm4Bt3cmmeIPb+QCeImjl Af5fojNj+3v76pqBiveExnA= =V+4Z -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Materials
Rick pretty well summarized my feelings on the matter... nice concept in theory if unintended side rffects on stacking etc. were dealt with, but that seems a big challenge considering current game mechanics and what not. Rick Tanner l...@real-time.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wonder whether to enable that (extended material) support by default and fix issues, or totally remove it. What do you think? What I found to be irritating about the material code was it made inventory management much more annoying. Specific example was Boots of speed. Instead of have (let's say..) a stack of 6 boots, you would see all individual boots because they were all made of different material (leather, snakeskin, etc.) So, only way to see that items were made of different materials is to have them show up individually in your inventory or item stack. On a side note.. As I recall, the intent of the original author was to deploy a questing system where a NPC would ask for something like a gold dagger and then the player would provide that to get a new item request (i.e., granite stone axe.) I personally liked such a concept, but not enough to really want to endure the issues it causes and mentioned above. So, unless some new ways to deploys this can come together, I would vote for removing this feature. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOB4avhHyvgBp+vH4RArETAKCN1W9+ZiR6VWXgm4Bt3cmmeIPb+QCeImjl Af5fojNj+3v76pqBiveExnA= =V+4Z -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Materials
Nicolas Weeger wrote: Le samedi 09 juin 2007 23:49, Lalo Martins a écrit : what about... keep materialname and lib/materials, and kill the material field? Err, can't for now, Gridarta (which is hopefully the official editor doesn't handle this materialname field :) This should be no argument if it is just that one field is missing: adding (or changing or removing) a field to/from Gridarta is a simple change. That is, if you decide on which way to go, I can update the editor in no time. Andreas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Materials
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. 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). materialname is used when doing saving throws, pointing to the material's intrinsic resistances. It is also used when describing the item - thus gold coins have a it is made of: gold even when its material value is 2 (iron) in the archetype. Consequently also, gold coins will use the 'gold' values for saving throws. There are some issues with the current implementation: * when NEW_MATERIAL_CODE is defined, objects have modified resistances / stats based on their material and also random materials, thus leading to massive non merging things * materialname only reflects one material - if I set material 3 in the archetypes, it will only be paper, not paper and iron. This also influences the saving throw, which will only be paper, not iron. * if material name is set to a special value (paper and glass - anything not listed in lib/materials), the item is then indestructible. * material is effectively useless when materialname is set, even to an invalid value 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. If I were to decide right now (but that may change), I'd probably keep/enable modifiers and random materials. But I would link that to loot diminution, ie reduce the junk players find. Thus less items, but more varied. I would also add materials with higher modifiers and penalties (eg: +20 fire, -20 cold - you get a bracers of that type, keep it?). And maybe even add other modifiers (reduce/increase hp regen, ...) Of course, that would mean more time required to sort/test all the junk :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'aléatoire !] pgpmVSYJZ2OVJ.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Materials
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
