This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Screwy UI Resupply Code
On Fri, Jan 30, 2004 at 09:52:36PM -0500, Eric McDonald wrote:
<snipped>
> My proposal is the following:
> (1) Slightly alter the semantics of the um_acp_to_load and
> um_acp_to_unload tables. Make -1 a possible table value, and let
> it mean impossible action. Leave 0 as the default, but change its
> meaning to "expends no ACP to perform action".
> (2) Make all UI and AI code go through the
> check_transfer_action/net_prep_transfer_action mechanism, once
> above fix is in place. (Not doing this may be a possible source of
> sync errors, I would think.)
I couldnt agree more with proposal two, and dont have any problems
with proposal one.
>
> At the time of these modifications, we could consider
> implementing a feature request from Lincoln Peters (IIRC) last
> year. That would be to allow quantified transfer of supplies in
> the UI's. Meaning, one could type in a prefix arg before the
> transfer key code, and this would put the UI into a prompting mode
> which would first ask which material type to transfer (ENTER could
> possibly mean "any available/wanted"), and then ask which unit to
> give to/take from (ENTER could possibly mean "any which can
> donate/want"). A non-prefixed transfer key code (or menu item
> selection) would continue to have the existing meaning in the
> user interfaces....
>
> Your thoughts?
>
> Thanks,
> Eric
I disagree in general with having to expend key strokes resupplying
units. The "take" action calls a ui function "do_one_take" from memory
which is basically unavailable to the ai, which has to push a resupply
task. I think this "do_one_take" sidesteps the task/prep-action
procedure. So I would remove the "take" action entirely.
With the fueling development I am working on
it is virtually never necessary to push a resupply task, as the units do
it automatically, and the end of turn resupply code can handle the rest.
I think that a unit should only get fuel by occupying the supply unit
directly, for those units that can only recieve fuel from distance zero.
A worthwhile development would be to adjust the resupply task so that it
doesnt waste acp by waiting till the next turn, and also when units have
not actually entered a resupply unit and are full up again the task
completes.
Peter