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


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


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