Re: Cow patties, and keeping them asleep

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Wed, 2004-05-12 at 05:23, mskala@ansuz.sooke.bc.ca wrote:
> 
> No biggie if the patch isn't usable - I warned that it might create other
> issues when I posted it. 

Well, I am using the new table, so it was at least partly usable. ;-)

> I think the real issue is that when wake_unit recurses, it only passes
> down a boolean flag, instead of more information about the *reason* for
> the wake.  Occupant units then don't have the opportunity to make a
> decision between "I care about user-initiated 'wake all' commands" and "I
> don't care about the transport waking up in response to 'enemy seen'"; the
> occupant is just told "the transport is waking up for some reason and
> wants to notify you" and then the occupant has to scramble for information
> on why.
> 
> I think the best solution (which would, unfortunately, require even more
> coding) would be to define some kind of information (possibly an
> enumerated type) to represent the reason for waking up, and to carry that
> through all wake_up calls. 

I would prefer not bloat the wake_unit function too much. Like I said, I
did put in a check regarding the ACP of the unit, since I think that
check does belong at the atomic wake_unit level. However, things such as
conditionally recursively waking a unit do not go in the atomic
wake_unit function, IMO. What I ended up doing before I sent you my
final email last night, was to create a conditionally_wake_unit function
that calls wake_unit, based on guidance from uu_can_recursively_wake.
Thus the "wake-all" command (and others) can still call wake_unit
directly with the 'wakeocc' flag set according to desire, but functions,
such as the one which reacts to a seen unit, can call
conditionally_wake_unit. This model could be extended further in the
future with additional higher level functions and tables to specifically
handle things such as 'wake-on-enemy-seen' and 'wake-on-attack'. For
now, I will be content just to have the general recursive wake behavior
defined.

>  That would lay the groundwork for (in the long
> term) the idea you described of user-controllable waking doctrine, and (in
> the short term) something like the can-recursively-wake table that would
> nonetheless NOT override user-initiated "wake all".  I'd be willing to
> look at writing some code for that solution if there's agreement that it
> would be worth doing.

I think there are two aspects to a player-controllable wake doctrine:
(1) Overriding _unit type_ defaults.
(2) Overriding _unit_ defaults (which are initially inherited from the
unit type defaults).

The latter would probably require a new bit vector to be added to the
unit struct, and then each UI would have to be given a means for the
player to toggle the condition bits. Thus, the latter might be regarded
as a longer term project.

But even the former would require:
(a) Using some new user-settable doctrine.
(b) Using doctrine fields instead of a table lookup like we are now.

Yes, I think it's worth doing, but there will be a little work involved,
especially with (2) above.

> Those changes might be worthwhile, but I think the result wouldn't address
> the situation for which I wrote the patch, because I want the occupants to
> be able to be unloaded (technically, transferred - it's not necessary
> (although might be nice) for them to be unloadable onto terrain), and I
> think that requires them to have ACP.  If it were possible to transfer
> occupants from one transport to another without them having positive ACP
> (for instance, by allowing whatever actions are needed for a transfer to
> be done with "ACP debt", driving the ACP below zero with a negative
> acp-min) then that would be addressed, but then no patch would be needed
> anyway because the units wouldn't wake anyway.  I'm pretty sure that a
> unit can't wake up, or at least, can't wake up enough to be annoying in
> the UI, if it has no ACP - your first check appears to already exist
> somewhere.

I am doing parts of the patch for other reasons besides yours. For
example, units such as mines, which are used in Bellum and Bellum II,
should not wake ever, hence the ACP check in wake_unit is quite
appropriate for them.  Basically, I am trying to take care of multiple
related items of business.

Still, the call to 'conditionally_wake_unit' in react to seen unit code
should address one of the problems we discussed regarding your game.

Eric