Re: Screwy UI Resupply Code

[Peter Garrone <pgarrone at acay dot com dot au>]

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