This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Screwy UI Resupply Code
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Hans Ronne <hronne at comhem dot se>
- Cc: xconq7 at sources dot redhat dot com
- Date: Tue, 3 Feb 2004 17:12:08 -0500 (EST)
- Subject: Re: Screwy UI Resupply Code
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