Screwy UI Resupply Code

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

Hello fellow Xconq developers (and any other interested parties),

  I have been looking at the way the Xconq UI's handle give/take 
of supplies and was fairly unimpressed to discover that they 
"cheat" (circumvent the standard action checking/execution 
mechanism). Instead of doing a check_transfer_action followed by a 
net_prep_transfer_action, they do "raw" calls to transfer_supply, 
a function which is actually called by do_transfer_action.

  Of course, by avoiding check_transfer_action, transfer of 
supplies actually works. If an UI or AI was to call 
check_transfer_action, transfer of supplies would cease to work in 
essentially all of the game modules. This is because the default 
for um_acp_to_load and um_acp_to_unload is 0, and 
check_transfer_action treats 0 as not allowing the action.

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

  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