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: Screwy UI Resupply Code


>  So the question is: what do we do about this mess, if anything?
>
>  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. The correct thing to do if we want to enable
material transfer in all games is therefore to change the default to 1.
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).

The question is what is this code really supposed to be used for? It seems
that give_supplies was added in 1998 when Stan wrote the collect code. The
collect code is used in only one game, the never completed AOE-like
ancient-days (to pick berries from berry bushes etc). This is also the only
game where acp-to-load and acp-to-unload are enabled, so it makes sense.
Furthermore, do_collect_task does call check_transfer_action and
prep_transfer_action, as expected. I would therefore say that give_supplies
was never intended to be used in other games, but since it does not do the
proper calls to check_transfer_action etc it is in fact generally
available. But is it actually ever used by players in e. g. the standard
game?

OTOH, take_supplies has been in ui.c for as long as there are ChangeLog
records. Presumably, this is really intended to be an action that does not
use acps, and which is enabled in all games with materials. The question is
if we should keep it that way (which would require a separate check_
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).

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

Hans




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