[CF-Devel] button.c magic mouth suggestions

[Kurt Fitzner]

On 08-Sep-2002 Mark Wedel wrote:
>
     
        At some point, I think we have to say to some things 'it should be done
     
     >
     
      the right way, not the fast way'.
     
     
The problem is that it hasn't been done the right way from the beginning. 
I'm not trying to point any fingers here - the way it is now is a natural
progression from where it started to where it is.  What I'm saying, though,
is we can add a gazillion flags for everything.  Letting the flags/attributes
grow ad-infinitum will only cause more problems than it will solve.  Memory
wastage is one.  CPU wastage for memcopies is another.  But really, the issue
becomes planning for the future.  This is a policy decision that will come
back and bite you in the heiny.  Two years from now when there are a million
new features and you're looking at bloated objects and an organizational
nightmare, you'll regret going with 'new feature, new flag' for every little
type-specific behavior you want to add to the system.  Your rule needs to be
'if the property of flag is meaningful to the majority of object types then
give it its own value in the object struct - otherwise, use existing space'.  I
promise you, anything else will be more of a nightmare than overloading is now.

What I suggest we do that will (I believe) solve both issues is we
create 32 bits of new flag space in each object, 16 ints, pointers and
floats (that count was picked out of the air - we can choose more or less, or
expand later).  We designate these as "type-specific storage" and make nice
#define's for them like TYPE_FLAG_1, TYPE_INT_1, etc.  We then use
them for any type-specific storage.  Anything that makes sense only for one
object type.  The reversal flag on buttons (currently sp = 1), the activate
only on button press/rel easef or signs (currently sp = 1/-1) etc.  The way we
make it readable, then, will not be in the map editors though.  I would
suggest that this is not the appropriate place to hide the complexity.  We
make it readable by overloading their meaning in loader.l.  We can assign
"ACTIVATE_ON_PUSH_ONLY" to set TYPE_FLAG_1 (bit 1 of the type-specific
flag area).  I don't even suggest we make loader.l context-sensitive.  Of
course, this will make it so that if that is set on the wrong object type,
then wierdness will result. This is where the map editors would need to show a
little inteligence, only writing "ACTIVATE_ON_PUSH_ONLY 1" to the map file for
signs/magic mouths.  If, in the future, there is a lot of problem with the
wrong flags ending up on the wrong object types, we can start to add
contextual sensitivuty to the loader.  I don't foresee this as a problem,
though.

The good news is this is something we can do today.  It's a couple hours worth
of work to get the initial support in for it.  Once it's started, we can even
begin to un-overload the existing stuff into the type-specific areas.  There
will have to be a few caveats.  I suggest we enforce a documentation rule
where we have an external document that outlines what type-specific flag, int,
float, and pointer means in relation to each object type.  I suggest we
religeously maintain this, and also put copious documentation into the source
and into loader.l each time we support a new name in it.

I'll be happy to make the initial changes.

        Kurt.