[CF List] problem with some diseases
Mark Wedel
mwedel at sonic.net
Wed Jul 10 22:23:07 CDT 2002
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).
More information about the crossfire
mailing list