Re: [Alephmodular-devel] Re: CVS Troubles (was Re: Map Editing and Liquids (and Project Builder / CVS woes))

[Woody Z. I. <woo...@sb...>]

On Monday, February 17, 2003, at 03:55  PM, Br'fin wrote:

> Still, at some point (far distant, alas) I'd not mind trying to expand 
> the action flags.  Thus letting some sub-project have more available 
> actions and be able to map them to normal keys and have them handled in 
> a way which works with both network and replay facilities.

In the meantime there should at least be (if there aren't already!  :) ) 
code changes like, giving them their own type and custom methods for 
duplicating, packing, and unpacking them, accessing their contents 
through a macro or inline function or something, etc.  And maybe at some 
point just doubling the number of bits to make some room would be 
sufficient.

Oh and it would probably be nice (this is not action_flags of course, 
but) if the various game-option keys (adjust screen size, adjust volume, 
etc. etc.) were sort of generalized at some point too, so they could be 
configured and new ones added etc. with minimal fuss.  (I don't remember 
whether A1/Carbon (or AM, indeed) is among the builds that does this, 
but... I use the Dvorak keyboard layout rather than QWERTY, and so when 
I use the key labelled "E" on my keyboard to move forward, well that's 
really the "period" key, so some versions of A1 won't let me use it (and 
some others let me configure it, somehow, but in the game, running 
forward turns up the volume).  So anyway it'd be awfully nice to be able 
to configure, say, "volume up" to be something else... and being able to 
do so of course suggests generalizing the keyboard-handling stuff.)

Random thought: it would be nice if structures that are re-used are 
explicitly invalidated somehow.  For example, my recent A1 work in 
resuming saved-games as netgames led me through the initialization 
stuff, where I just have to kind of hope/trust (thanks to the overall 
complexity in there) that all the relevant parts of the game state are 
getting reinitialized somehow (and that, specifically, none are being 
overlooked and letting stale values from the previous game bleed 
through).  If all this stuff were, say, destroyed when a game ends and 
reallocated (using something like MallocScribble of course) when another 
game begins, or all allocated from some big contiguous memory region 
that could be memsetted, I wouldn't have to worry so much about stale 
stuff - anything I missed should be reasonably apparent and should cause 
the same problem every time (rather than, say, working as long as I 
happened to play that level first as a single-player game, but 
exhibiting weird behaviors if I played some other particular level 
first, etc.).

Shrug, maybe the Marathon code base is already pretty good about this 
and I just don't realize it.

Woody