Screwy UI Resupply Code

Screwy UI Resupply Code

[Eric McDonald]

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

Re: Screwy UI Resupply Code

[Jim Kingdon]

> put the UI into a prompting mode which would first ask which
> material type to transfer, and then ask which unit to give to/take
> from

Also, how many units to transfer.

Right now, a numeric arg means to give the number of units to
transfer, but yeah, that doesn't say which material or which unit.

Re: Screwy UI Resupply Code

[Peter Garrone]

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

Re: Screwy UI Resupply Code

[Jim Kingdon]

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

How does it know whether I want my bomber to take fuel from a base, or
give fuel to the base?  I do both things, depending on what I'm trying
to do.

Trying to make resupply more automatic is probably a good thing, but
getting rid of manual transfers entirely doesn't strike me as a step
forward.

Re: Screwy UI Resupply Code

[Skeezics Boondoggle]

On Mon, 2 Feb 2004, Jim Kingdon wrote:

> > 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.
> 
> How does it know whether I want my bomber to take fuel from a base, or
> give fuel to the base?  I do both things, depending on what I'm trying
> to do.

Actually, automatic resupply can get in the way at times.  Sometimes, for 
instance, I'll send a bomber out on a long-range mission, while a fighter 
is returning to land and refuel.  If the fighter ends up in the same hex 
as the bomber, it'll resupply itself - and I have to turn the bomber 
around and refuel, or try to steal the fuel back from the fighter to 
continue.  It's kinda silly. :-)

I could see that having in-flight refueling from a "bomber" could arguably
be a simplified case of not requiring separate tanker units; the standard
game has a reasonable balance between selection and simplicity (it might
be nice to have patrol boats, or a cruiser type in between destroyer and
battleship, but then you're moving into the advanced game territory).  

However, sometimes if a fighter goes too far out and there's a bomber
nearby that can refuel it, that's a great way to keep from losing units if
they're unexpectedly out of range.  But since fighters can even refuel
from destroyers, why build carriers?  That could be considered a bug...

> Trying to make resupply more automatic is probably a good thing, but
> getting rid of manual transfers entirely doesn't strike me as a step
> forward.

I agree.

-- Chris

Re: Screwy UI Resupply Code

[Eric McDonald]

Hi Skeezics, others,

On Mon, 2 Feb 2004, Skeezics Boondoggle wrote:

> Actually, automatic resupply can get in the way at times.  Sometimes, for 
> instance, I'll send a bomber out on a long-range mission, while a fighter 
> is returning to land and refuel.  If the fighter ends up in the same hex 
> as the bomber, it'll resupply itself - and I have to turn the bomber 
> around and refuel, or try to steal the fuel back from the fighter to 
> continue.  It's kinda silly. :-)

Agreed. If the materials donor was immobile though, I can't see 
that it would be much of a problem.

> However, sometimes if a fighter goes too far out and there's a bomber
> nearby that can refuel it, that's a great way to keep from losing units if
> they're unexpectedly out of range.  But since fighters can even refuel
> from destroyers, why build carriers?  That could be considered a bug...

Well, if the UI resupply code actually looked at the acp-to-load 
and acp-to-unload tables then this could be easily addressed 
(without having to create separate fuel types for air units and 
sea units).

Eric

Re: Screwy UI Resupply Code

[Eric McDonald]

On Mon, 2 Feb 2004, Peter Garrone wrote:

> task. I think this "do_one_take" sidesteps the task/prep-action
> procedure. 

Yes. This is what I referring to in my original message in this 
thread.

>So I would remove the "take" action entirely.

I disagree. As Jim points out, there are times where manual 
give/take is still useful. This functionality should continue to 
be available, even if much of it can be automated in many cases.

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

One of the things I was looking into was to scan each cell, as a 
unit is executing a move-to task, to see if any units can serve as 
willing donors to provide materials for free (costing no ACP). It 
was this investigation that turned up the UI resupply screwiness, 
once I realized that the GDL default was to disallow resupply.

As a side note:
I don't see this ["free" on-the-fly resupplying] as necessarily 
being at cross-purposes with refueling automation you might 
have included in your new pathing code. It is one thing to plan a 
path to cross resupply points, but another thing to utilize 
resupply points while moving. I am interested in improving the 
latter.

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

Technically, anything that is in the same cell is distance 0. Why 
should a carrier at sea have to enter a tanker unit in order to 
resupply, when "running some hoses between the ships" would 
suffice?

> 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

I started to address this some time ago. It is currently #if 0'd 
out right now, but it is definitely on my agenda to complete.

> not actually entered a resupply unit and are full up again the task
> completes.

If you mean units which have been resupplied by supply lines 
between turns, and thus no longer need to do an explicit move-to 
and resupply, __I addressed this a week or two ago. Judging 
from your comments here and in the next email, it would seem that 
you have not done a CVS update in a few weeks....

Eric

Re: Screwy UI Resupply Code

[Hans Ronne]

>  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

Re: Screwy UI Resupply Code

[Eric McDonald]

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

Re: Screwy UI Resupply Code

[Peter Garrone]

On Mon, Feb 02, 2004 at 11:36:00AM -0800, Skeezics Boondoggle wrote:
> On Mon, 2 Feb 2004, Jim Kingdon wrote:
> 
> > > 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.
> > 
> > How does it know whether I want my bomber to take fuel from a base, or
> > give fuel to the base?  I do both things, depending on what I'm trying
> > to do.
> 
> Actually, automatic resupply can get in the way at times.  Sometimes, for 
> instance, I'll send a bomber out on a long-range mission, while a fighter 
> is returning to land and refuel.  If the fighter ends up in the same hex 
> as the bomber, it'll resupply itself - and I have to turn the bomber 
> around and refuel, or try to steal the fuel back from the fighter to 
> continue.  It's kinda silly. :-)
> 
> I could see that having in-flight refueling from a "bomber" could arguably
> be a simplified case of not requiring separate tanker units; the standard
> game has a reasonable balance between selection and simplicity (it might
> be nice to have patrol boats, or a cruiser type in between destroyer and
> battleship, but then you're moving into the advanced game territory).  
> 
> However, sometimes if a fighter goes too far out and there's a bomber
> nearby that can refuel it, that's a great way to keep from losing units if
> they're unexpectedly out of range.  But since fighters can even refuel
> from destroyers, why build carriers?  That could be considered a bug...
> 
> > Trying to make resupply more automatic is probably a good thing, but
> > getting rid of manual transfers entirely doesn't strike me as a step
> > forward.
> 
> I agree.
> 
> -- Chris

Thanks for the argument, if not the conclusion. This is obviously a
difficult issue. I want to be Napolean, not a supply clerk. If I choose
not to do manual transfers, my opponent will do them, and thereby have
an advantage.

The "do_one_take" is not properly integrated into the plan/task/action
code, and the AI cannot take advantage. Also it is curious that aircraft
would be disadvantaged by having to move to a resupply point for
fuel, then be able to do manual takes from troopships, so thats why I
think its a blight on the game. 

Re: Screwy UI Resupply Code

[Peter Garrone]

On Mon, Feb 02, 2004 at 02:21:10PM -0500, Eric McDonald wrote:
> On Mon, 2 Feb 2004, Peter Garrone wrote:
> 
> >So I would remove the "take" action entirely.
> 
> I disagree. As Jim points out, there are times where manual 
> give/take is still useful. This functionality should continue to 
> be available, even if much of it can be automated in many cases.

Of course it is useful. But it is too tedious. If it is disabled, then
no one can do it, and it is fair for all.

> 
> One of the things I was looking into was to scan each cell, as a 
> unit is executing a move-to task, to see if any units can serve as 
> willing donors to provide materials for free (costing no ACP). It 
> was this investigation that turned up the UI resupply screwiness, 
> once I realized that the GDL default was to disallow resupply.

The image that leaps into my mind is a lot of units moving around
stealing fuel off each other. I dont know where you are going here.

> 
> As a side note:
> I don't see this ["free" on-the-fly resupplying] as necessarily 
> being at cross-purposes with refueling automation you might 
> have included in your new pathing code. It is one thing to plan a 
> path to cross resupply points, but another thing to utilize 
> resupply points while moving. I am interested in improving the 
> latter.

The pathfinding will reject a path if it will take a unit into an
unsupplyable situation. But if units take fuel from each other, then its
very difficult to discover if paths are unfuelable.

> 
> > 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.
> 
> Technically, anything that is in the same cell is distance 0. Why 
> should a carrier at sea have to enter a tanker unit in order to 
> resupply, when "running some hoses between the ships" would 
> suffice?

I dont think real navy vessels in general can resupply each other with fuel.
Only designated refuel vessels can do that. Obviously they are at a
combat disadvantage while doing so as well. So a realistic situation
would be to have the unit occupy the refueler, and to have a combat
disadvantage.

Certainly aircraft cannot do air-air refueling, unless its a special
aircraft. As for refueling from say a troopship.

Even ground vehicles cant refuel eachother. You have to drive to and
enter a service station.

The overall development of this game is that units are constrained by
supply, people dont like it, so cheating is being inserted into it.
This gets ridiculous, from the point of playability and realism, and
also from the point of software, because there is one set of software to
impose some constraints, and another set to get around it.

Re: Screwy UI Resupply Code

[Eric McDonald]

On Thu, 5 Feb 2004, Peter Garrone wrote:

> What crap. Still a better read than the shear rudeness you resort to via
> private email. 

If you're referring to the private thread on assertions that we 
had a while back ago, then you had it coming, __trying to jerk my 
chain in the snotty way you tried.

> So if anyone were to have an xconq tournament, the winner would have the
> honor of being the person who can stand the most tedium?

Your question is a bit loaded. But, my guess is that the person 
with the most solid and creative play would probably win. If that 
involved some tedious shuffles here and there, I bet they would 
feel worth it to the winner.

> > With WWII era vessels, you are wrong. With modern ones, I don't 
> > know.  I have seen photos of a destroyer refueling a sub at sea, a 
> > carrier refueling a destroyer at sea, and, of course, 
> > tankers/oilers/supply ships refueling various vessels at sea. It's 
> > a fact.
> 
> Ok I concede here. 
>But the air-to-air is a bit unrealistic.

So what. In the end, none of this realism argument matters too 
much. The point is that a game designer may wish to have a game 
where units within the same cell (but not one occupying another) 
share materials.

But if you insist on a realism argument, then I have already shown 
that two naval units may reasonably resupply each other without 
one occupying the other. Since this case exists, air-to-air or any 
other is irrelavant in addressing the general question whether 
such behavior realistically occurs.

> It should be either explicitly allowed or disallowed in the GDL.
> But I lack in-depth knowledge here. I think this is what you intend
> to do anyway.

Sharing of materials, yes.
The question of sharing range (which I thought we were discussing, 
though its hard to tell with your meandering vagueness sometimes) 
is something that still needs to be discussed.

> > > combat disadvantage while doing so as well. So a realistic situation
> > > would be to have the unit occupy the refueler, and to have a combat
> > > disadvantage.
> > 
> > Having a Carrier _enter_ a Tanker is realistic?! C'mon Peter....
> 
> I dont think you sincerely miss my point, but you know how the code is

Huh? You were arguing that any unit should occupy another unit if 
it wanted to refuel.

> I am suggesting the removal of certain "features".

I know. I am suggesting fixing, rather than removing, the 
give/take feature.

> So there is a resupply key and a take key. What is the difference
> between them then? 

???
The "resupply" key? Are you referring to the "return" key?
If you read the descriptions in cmd.def, which reflect what the 
keys actually do, you might note that "return" key is for 
returning to a resupply point, and "give" and "take" are for 
transferring supplies. There is a big difference.

>If you were designing xconq from scratch, would you
> have both?

I'll answer this once you clarify what you actually meant.

> (Actually T is for the transport task, but this minor consideration has
> nothing to do with it of course.)

I don't see it listed as such. This must be one of your tinkerings 
to which you are referring.

> As for such things as aircraft refueling from troopships, that 
>can well disappear.

Via GDL limitation, not via removal of the give/take 
functionality.

> You are often very vague, and this makes it difficult to have a rational
> discussion.

Perhaps you are confusing vagueness with abstraction. I have 
noticed in the past that abstract thought does not seem to be one 
of your strong points.

> Nevertheless I urge you to continue with what you are doing
> so long as you address some of these refueling anomalies.

Well, gee, thanks for your blessing....
I haven't gone beyond some public discussion on this, because I 
need to coordinate any UI changes with Hans (for the Mac native 
GUI).

> One other anomaly I have noticed is that it is possible for a unit with
> 0 fuel to move one more hex to a refuel point, but otherwise it cannot
> act, which seems odd.

That does seem odd. But perhaps the refuel point had some 
ferry-over stuff set, and the MP to enter it was less than the MP 
to move in the surrounding terrain?

> - plan.c: resupply if low, long term approaches for all plans.

Care to elaborate? You're a bit vague with this one.

> - task.c: resupply, move-to, hit/capture, occupy, pickup

Jeezus, lock down the whole basic AI....

> - mplayer.c : transportation, some stats gathering, exploration test.

So how big is this "totally inseparable" megapatch getting to be 
these days?

> - path.c: very much reorganised with significant bug fixes.

Hopefully among the fixes is one for the 
path-avoids-friendly-cities bug that was reported several 
_months_ ago.

Eric

Re: Screwy UI Resupply Code

[Peter Garrone]

On Tue, Feb 03, 2004 at 06:57:54PM -0500, Eric McDonald wrote:
> 
> *Sigh*  Your argument resembles various societal and legal trends 
> here in the US. Placing a strange notion of "fairness" before 
> "freedom"....
> 
> Actually, you are starting to me remind of the "Handicapper 
> General" in a Kurt Vonnegut short story, "Harrison Bergeron", that 
> the teacher made us read in freshman lit in high school.

What crap. Still a better read than the shear rudeness you resort to via
private email. You are not making any sort of real point here, and
I fail to see how it is supposed to convince anyone of anything.

> 
> If resupply is largely automated, then I fail to see how it can be 
> tedious. And the fact that some people may choose a little tedium 
> to give themselves an advantage is, __how shall I say it, normal 
> and reasonable.

So if anyone were to have an xconq tournament, the winner would have the
honor of being the person who can stand the most tedium?

We should start a thread on tedium, and its advantages.

> 
> > I dont think real navy vessels in general can resupply each other with fuel.
> 
> With WWII era vessels, you are wrong. With modern ones, I don't 
> know.  I have seen photos of a destroyer refueling a sub at sea, a 
> carrier refueling a destroyer at sea, and, of course, 
> tankers/oilers/supply ships refueling various vessels at sea. It's 
> a fact.

Ok I concede here. But the air-to-air is a bit unrealistic.
It should be either explicitly allowed or disallowed in the GDL.
But I lack in-depth knowledge here. I think this is what you intend
to do anyway.

> 
> > Obviously they are at a
> > combat disadvantage while doing so as well. So a realistic situation
> > would be to have the unit occupy the refueler, and to have a combat
> > disadvantage.
> 
> Having a Carrier _enter_ a Tanker is realistic?! C'mon Peter....

I dont think you sincerely miss my point, but you know how the code is
structured and that this would be the most realistic approach, so I
cant be bothered replying in detail. There are cases in WW2 where
attack while refueling was extremely effective, e.g battle of midway.

> 
> > also from the point of software, because there is one set of software to
> > impose some constraints, and another set to get around it.
> 
> This was my original point, and I am suggesting that we remedy 
> that situation. But, not by making it disappear....
> 
> Eric

I am suggesting the removal of certain "features".

So there is a resupply key and a take key. What is the difference
between them then? If you were designing xconq from scratch, would you
have both?

(Actually T is for the transport task, but this minor consideration has
nothing to do with it of course.)

As for such things as aircraft refueling from troopships, that can well disappear.

Besides these examples, I am at a loss to think what you mean here.
You are often very vague, and this makes it difficult to have a rational
discussion. Nevertheless I urge you to continue with what you are doing
so long as you address some of these refueling anomalies.

One other anomaly I have noticed is that it is possible for a unit with
0 fuel to move one more hex to a refuel point, but otherwise it cannot
act, which seems odd.

I would suggest you wait a week or so with the following functions, as
I have been forced to modify them significantly. Actually I am
about 95% happy with this now. Unfortunately I will not have time to 
merge with latest CVS before I leave for a week.

- plan.c: resupply if low, long term approaches for all plans.
- task.c: resupply, move-to, hit/capture, occupy, pickup
- mplayer.c : transportation, some stats gathering, exploration test.
- ai.c : assign_to_offense - consider more parameters.
       : transportation - ensure with pathfinding that waiting units
              are reachable
       : general unit construction. - ensure sufficient materials are
         on hand for creation and a couple of construction turns.
- unit.c : real_operating_range_best function now more accurate.
- path.c: very much reorganised with significant bug fixes.


Peter

Re: Screwy UI Resupply Code

[Eric McDonald]

On Wed, 4 Feb 2004, Peter Garrone wrote:

> > I disagree. As Jim points out, there are times where manual 
> > give/take is still useful. This functionality should continue to 
> > be available, even if much of it can be automated in many cases.
> 
> Of course it is useful. But it is too tedious. If it is disabled, then
> no one can do it, and it is fair for all.

*Sigh*  Your argument resembles various societal and legal trends 
here in the US. Placing a strange notion of "fairness" before 
"freedom"....

Actually, you are starting to me remind of the "Handicapper 
General" in a Kurt Vonnegut short story, "Harrison Bergeron", that 
the teacher made us read in freshman lit in high school.

If resupply is largely automated, then I fail to see how it can be 
tedious. And the fact that some people may choose a little tedium 
to give themselves an advantage is, __how shall I say it, normal 
and reasonable.

> The image that leaps into my mind is a lot of units moving around
> stealing fuel off each other. I dont know where you are going here.

I think it is reasonable to not receive donations from mobile 
units. This avoids the "Fighter takes fuel from Bomber, then 
Bomber needs fuel so it takes it from Fighter" scenario that we 
were presented with earlier.

> I dont think real navy vessels in general can resupply each other with fuel.

With WWII era vessels, you are wrong. With modern ones, I don't 
know.  I have seen photos of a destroyer refueling a sub at sea, a 
carrier refueling a destroyer at sea, and, of course, 
tankers/oilers/supply ships refueling various vessels at sea. It's 
a fact.

> Obviously they are at a
> combat disadvantage while doing so as well. So a realistic situation
> would be to have the unit occupy the refueler, and to have a combat
> disadvantage.

Having a Carrier _enter_ a Tanker is realistic?! C'mon Peter....

> also from the point of software, because there is one set of software to
> impose some constraints, and another set to get around it.

This was my original point, and I am suggesting that we remedy 
that situation. But, not by making it disappear....

Eric