[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