Re: Screwy UI Resupply Code

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

Hi Hans, others,

On Tue, 3 Feb 2004, Hans Ronne wrote:

> >  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 would definitely agree with (2) but not with (1). GDL should be as
> consistent as possible, and acp-to-do-something being set to 0 always means
> that the action is impossible.

Yes. I was aware that proposal 1 went against the grain in this 
regard. However, it did get me thinking about whether 0 
acp-to-do-something should ever mean not able do something. (I am 
not advocating such a drastic alteration prior to the 7.5 release, 
of course). Redefining 0 to mean "does not use any ACP to perform 
this action" would be sensible I think. This would allow an 
otherwise acp-dependent unit to be acp-independent for specific 
types of actions. There is a danger of infinite repeatability of 
those actions within a given turn if proper material constraints 
are not placed on them. To help the game designer avoid such 
dangers, the game initialization code would probably have to check 
for any 0 acp-to-do-something cases, and then for those cases, 
check to make sure that material-to-do-something and 
consumption-per-doing-something for them were greater than 0. If 
not, then issue an init_warning.

> The correct thing to do if we want to enable
> material transfer in all games is therefore to change the default to 1.

Ouch. Costly, I think. Especially, if Peter's code may be 
automatically refueling a unit.

> OTOH, if we want transfer to be acp-less, but still restricted to only
> certain units, acp-to-load should really be replaced by something else
> (e.g. can-load-material).

I agree with this approach in the short term. I think we should 
pursue it prior to 7.5.

> function) or make it use acps like all other actions. I can see the reason
> why it does not use acps (run_economy calls transfer_supply without using
> acps, so material transfer is supposed to be more or less automatic and
> costless).

Well, for run_economy, I believe that the at_turn_start flag is 
set. You could just simply prevent ACP deduction (and ignore ACP 
checks) if that flag is popped up. I do this with the auto upgrade 
stuff I added recently.

> One easy solution would be to get rid of acp-to-load and acp-to-unload
> altogether, and make all material transfer, whether or not part of collect
> tasks, both possible and costless.

I would vote for this, as long as we planned to provide  
can-{load,unload}-material tables. Those would be to prevent 
silliness like fuel being taken from a Destroyer and put on a 
in-flight Fighter, a scenario which Skeezics mentioned.

> This would be kind of logical,
> considering the fact that run_economy works this way. However, acp-less
> actions can cause unexpected problems, as I found out when I wrote the
> acp-independent build code. So one would have to do some careful testing
> first.

I certainly agree that infinitely repeatable action execution 
could be a problem for certain types of actions. But the transfer 
action, by its nature, limits itself. As long as the AI doesn't do 
something weird like donate materials back and forth between 2 
units over and over again in the same turn, I think it should be 
fine. (Famous last words...?)

  Regards,
    Eric