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: xconq7 at sources dot redhat dot com
- Date: Wed, 4 Feb 2004 22:29:25 -0500 (EST)
- Subject: Re: Screwy UI Resupply Code
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