[crossfire] Obsolete flags
Hello. There are quite many obsolete things in loader.l, so I'd like to remove'em, but not sure on some things. Also it'll require some map/arch cleaning. First, those flags: * has_ready_rod * has_ready_horn * has_ready_wand mapped to FLAG_READY_RANGE From what i read from the monster handling code, this ready_range flag is actually not required, it'll be calculated again. So IMO those three flags should be removed totally. * can_use_wand mapped to FLAG_USE_RANGE many archetypes use this flag, many in maps... So should be cleaned like crazy :) * immune * protected * vulnerable those kind of conflict with the resist_ values, they'll override or mess with them. Unfortunately many (~400) maps still use those, so updating won't be easy. * armour, which should be resist_physical, doesn't seem to be used much. Any volunteers for helping to clean ? :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'aléatoire !] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Discrete damage type
Hello. I just committed to SVN trunk changes that enable weapons to have discrete damage for each attack type. It works quite simply: * new object fields 'damage_attacktype', so 'damage_fire' and so, like the 'dam' field in living structure * if at least one field is set, 'dam' is ignored for attack, and the discrete values are used instead Implementation details, issues to check/fix: * the discrete damage are stored in a 'discrete_damage' array allocated only if one value is set in archetype definition * i only changed hit_player_attacktype to handle this discrete damage. It is used by many things, including spells attacks, i think. * i know some parts (specially spell attacks) alter dam based on casting spell level. Thus that code should be changed to modify discrete_damage instead - shouldn't be too hard Feel free to flame/comment/..., as usual. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'aléatoire !] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Obsolete flags
Nicolas Weeger wrote: Hello. There are quite many obsolete things in loader.l, so I'd like to remove'em, but not sure on some things. Also it'll require some map/arch cleaning. First, those flags: * has_ready_rod * has_ready_horn * has_ready_wand mapped to FLAG_READY_RANGE From what i read from the monster handling code, this ready_range flag is actually not required, it'll be calculated again. So IMO those three flags should be removed totally. Probably true - I can't remember now, but certainly at one point, they were used internally - I don't know if they were ever saved out to any maps. * can_use_wand mapped to FLAG_USE_RANGE many archetypes use this flag, many in maps... So should be cleaned like crazy :) At the same time, are there any other can_use_... flags out that that have been replaced/supserseded? * immune * protected * vulnerable those kind of conflict with the resist_ values, they'll override or mess with them. Unfortunately many (~400) maps still use those, so updating won't be easy. yes - like most things in the loader, it supported using these values along with the new, but having both set in the same object was never really considered supported. * armour, which should be resist_physical, doesn't seem to be used much. Any volunteers for helping to clean ? :) Can't most of this be automated with scripts? For flags that just go away, it'd seem to be a simple 'remove this line' type of logic - not hard at all. The immune/protected/vulnerable may be a little trickier, because if an object is using those plus the resist values, just putting in the corresponding values based on the immune may conflict with those other ones. However, I'd think that would be something pretty easy to catch - only in those cases where that is happening would manual interaction be needed - otherwise, this could be automated. It'd also seem to be that baseline scripts that do this conversion would be useful - it would be a good starting point so if down the road, something else is obsoleted, change the script a little bit and you are good to go. I think there may already be some scripts out there that do this sort of thing. I know I wrote some for the map updates (to update exits whatnot). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Discrete damage type
Nicolas Weeger wrote: Hello. I just committed to SVN trunk changes that enable weapons to have discrete damage for each attack type. It works quite simply: * new object fields 'damage_attacktype', so 'damage_fire' and so, like the 'dam' field in living structure * if at least one field is set, 'dam' is ignored for attack, and the discrete values are used instead Random question to everyone at a whole - should the old 'dam' field go away at some point, that is to say, everything should use the discrete damage? This would require map archetype updates, but that could all be automated - if attacktype is set for say AT_FIRE and AT_PHYSICAL, and dam is 10, then script would just remove that and add damage_fire 10 and damage_physical 10. It also means that attacktype basically goes away - instead, that information is conveyed in the discrete damage fields. Which leads to an interesting question right now: If I set up the discrete damage values for an item, but don't update the attacktype to include those attacks, what happens? I can think of 1 of 2 things: 1) Attacktype is ignored - if the discrete damage is set, that is used no matter what (meaning that attacktype basically could go away if everything was updated) 2) The discrete damage isn't used, since the attacktype isn't set. If #2, should probably be documented someplace. Implementation details, issues to check/fix: * the discrete damage are stored in a 'discrete_damage' array allocated only if one value is set in archetype definition Are things smart enough to handle the case where I modify an archetype on the map to included a discrete damage type? For example, suppose I take the standard longsword, which just has a standard dam value, but want to make a specialized weapon - something that still does mostly physical, but a little bit of fire, so I use the discrete damage values to do that. Will that work? IMO, it should, because that is a pretty likely scenario, and from a map maker perspective, I shouldn't have to know the internals of how things work - I should be able to set up discrete damage types and just have it work. * i only changed hit_player_attacktype to handle this discrete damage. It is used by many things, including spells attacks, i think. * i know some parts (specially spell attacks) alter dam based on casting spell level. Thus that code should be changed to modify discrete_damage instead - shouldn't be too hard Don't know if done, but I'd also suggest that things like examine object should dump that information. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
