Andreas Vogl wrote: > > No doubt it's bad style, but unfortunately the CF object structure is > not as flexible as we'd like it to be. If unique variables and flags get > added for different object types (like the "disease-adjuster" you > proposed), that would cause a big overall increase in memory consumption. > The problem is that all objects have the same structure. Best you can > do is link-in substructures with pointers - But that's no perfect solution > either (danger of null-pointers getting accessed). I think the problem is more that way back in the history of crossfire, trying to conserve every byte for the object was considered very important, so all sorts of fields go overloaded with strange meanings depending on the object. Now there is certainly reason to not bloat the object up excessively, but the amount of ram in machines has grown a great deal - more so than the number of objects crossfire typically would have loaded at any time. So adding more fields to the object structure isn't that big a deal. The problem is updating all the code - in some cases, macros are used to access the member, so updating those are easy. But in many cases, the structure member is access directly. I should say that in this particular case, the use of negative damage to denote something different isn't that bad. As said, the docs say that is the case. It was really just one line that created the problem. In doing the change of apply method, I have made a lot of cleanups - really going forward, anything that needs a new field should add a new field to the object structure and not overload something. It should now be much simpler to do that in the past (which perhaps was never really hard, just cryptic).