This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cow patties, and keeping them asleep


On Tue, 11 May 2004, Eric McDonald wrote:
> your new table definition, but there is an issue with the patch to
> plan.c. The 'wake all' command ("W") in the user interfaces is
> specifically designed to wake all units in a transport, and it calls
> 'wake_unit' with the 'wakeocc' flag set. In this case, I do not think it
> would be wise to trump designer's wishes over player's wishes.

No biggie if the patch isn't usable - I warned that it might create other
issues when I posted it.  (Which is why I didn't spend time finding out
how to document it; at such time as I submit a patch really meant to be
usable, I'll document that.)  I also mentioned the issue you raise - the
change applies to *all* recursive wakes, including the user-initiated one,
and that might not be a good thing.

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.  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.

> (1) I am making a test of 'can_have_enough_acp' against 1 ACP. Even the
> unit appears to be ACP-less based on its type, it still needs to be

> (2) I am using your table in 'react_to_seen_unit' in side.c in the case

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.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]