[CF-Devel] button.c magic mouth suggestions

[Mark Wedel]

Andreas Vogl wrote:
>
     
      Mark W. wrote:
     
     >
     
     
     
>
     
      Guess we had this topic already once, but I don't think overloading
     
     >
     
      is so bad, given the way our code currently works.
     
     >
     
      If we add new flags and variables for every object, memory
     
     >
     
      consumtion would explode and we can't afford that IMO.
     
     >
     
      The server is already seriously memory-hungry.
     
     
  Off topic, but I disagree a bit here.

  Metalforge, with 3 active players, was using about 30 MB.  The 14,000 objects 
acount for about 10.5 MB.  Size of the current object is 760 bytes.

  I would estimate that it would take just a couple hundred bytes to completely 
eliminate the overloading of values in the object structure.  Means the server 
would use maybe 4 more megs.

  Now you can say the metalforge isn't in really heavy use right now.   But if 
we say had 10 times the memory consumption, that is just a difference of 40 MB - 
this would probably make the resident size of crossfire somehwere around 200 MB.

  Given the current systems out there, I don't consider it that big a deal.  And 
of course, memory usage isn't linear with players - If you have 10 times the 
players, you probably don't have 10 times the number of maps in memory - likely 
that several will be in town at the same time, or on the same world maps, etc.


>
     
      I could update "types.txt" for the JavaEditor and there it will
     
     >
     
      show all the "real" meanings of the fields. Nobody has to
     
     >
     
      keep in mind the overloaded variable names like sp, last_eat,
     
     >
     
      and all that. That is only the internal way values get stored.
     
     >
     
      Mapmakers have the masked GUI from the editor to understand
     
     >
     
      things. Even developers can take a look there if in doubt.
     
     
  You can hide it from mapmakers, but the problem is for developers.  More than 
one bug has been because a developer used a field they that was free but was in 
fact overloaded with something else.  Is that extra hassle/debugging worth the 
extra few MB?  probably not.  And in this specific case, the amount of memory we 
are talking about is 2 bits - which means on metalforge, we're talking about 28K 
more memory consumption (realistically, it would be 0 more memory consumption, 
because the flags fields are already allocated and wouldn't be increased).

  And I can already think of a case where using SP doesn't work - any connected 
item that you want to cast a spell would hold that spell in 'sp' (or should).


>
     
     
     >
     
      In spite of what I said before, I agree to you in this case.
     
     >
     
      It would be nicer to use flags here, because they can be used
     
     >
     
      in multiple objects, as said. Though I would name them
     
     >
     
      like 'FLAG_ACTIVATE_AT_PUSH' or something.
     
     
  Thats good at least.  The only issue with doing it this way is the objects 
would need to get updated.  I really like to try to keep flags 'positive', eg, 
if the flag is set, the action happens if the conditions are right.  Vs using 
inverse flags like 'flag_dont_activate_on_unpush' or the like, which makes life 
confusing.

  So that said, probably would need to do something like 'FLAG_ACTIVATE_AT_PUSH' 
and 'FLAG_ACTIVATE_AT_RELEASE' or the like, and update the archs.

>
     
     
     >
     
      However, the patch from Kurt already exists. The solution
     
     >
     
      with flags does not. Would you do it? Would Kurt do it?
     
     >
     
      I'd really like to have this feature - one way or the other.
     
     >
     
      And to me Kurt's patch seems quite good enough.
     
     
  At some point, I think we have to say to some things 'it should be done the 
right way, not the fast way'.

  I'll do the appropriate changes - it may just be a few days before it gets done.