Standard game problems in windows (20031214) version

Standard game problems in windows (20031214) version

[Martin Fehlhaber]

Yesterday evening I played the standard game - by the way: which game would you
suggest as being moderately more advanced? - and had trouble unloading my
transports. I could only disembark directly into cities. I was able to build a
transport in a city  connected to the sea by a river (one hex), but was unable
than to slip into the sea.

The computer players did poorly, but I missed one transport of the last player.
So he retained score 1. I handed over to the AI to let it finish, but couldn't
bear to watch it crash my planes in hordes.

Besides: Units keep sharing fuel without my consent. This is especially
irritating with planes.

After having entered a flight path, planes keep halting after having spent half
of their fuel, despite the fact that there is a city waiting for them.

Have I mentioned yet, that I would love to see patrols implemented?

Still a fun game to play...

Regards,
Martin

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: Standard game problems in windows (20031214) version

[Hans Ronne]

>Yesterday evening I played the standard game - by the way: which game
>would you
>suggest as being moderately more advanced? - and had trouble unloading my
>transports. I could only disembark directly into cities. I was able to build a
>transport in a city  connected to the sea by a river (one hex), but was unable
>than to slip into the sea.
>
>The computer players did poorly, but I missed one transport of the last
>player.
>So he retained score 1. I handed over to the AI to let it finish, but couldn't
>bear to watch it crash my planes in hordes.
>
>Besides: Units keep sharing fuel without my consent. This is especially
>irritating with planes.
>
>After having entered a flight path, planes keep halting after having spent
>half
>of their fuel, despite the fact that there is a city waiting for them.
>
>Have I mentioned yet, that I would love to see patrols implemented?
>
>Still a fun game to play...

Thanks. The problems with loading/unloading transports are probably related
to the path-finding problems that Lincoln Peters and others have reported.
Same goes for the resupply problem. As you may know, we incorporated Peter
Garrone's new path-finding code recently. It is a major improvement, but
there are still three problems with it that need to be fixed:

1. Desynch of network games. The path cahce has been disabled as a
temporary fix, but this in turn slows down the AI a lot, something that
people also have complained about.

2. Transport-related problems.

3. Resupply-related problems.

Peter has been working on fixes for all three problems. I would rather wait
a few week for these fixes than back out of the path-finding code since I
think the latter adds a lot to the game. Meanwhile, please have patience
with these bugs.

There are also some other bugs that we are working on. Some games (such as
flattops) now crash in the Windows and Mac tcltk interfaces. And there are
some problems with running network games from saved files on Windows. These
problems may be related to the recent changes in the game loading and
network code.

As for a more advanced game, I would recommend either Eric McDonald's
Bellum or my own Advances game.

Hans

Re: Standard game problems in windows (20031214) version

[Eric McDonald]

Hi Martin, others,

On Tue, 16 Dec 2003, Martin Fehlhaber wrote:

> The computer players did poorly, but I missed one transport of the last player.
> So he retained score 1. I handed over to the AI to let it finish, but couldn't
> bear to watch it crash my planes in hordes.

The poor handling of aircraft is something that I think has 
appeared in the past 1.5 months. I am tempted to address it with a 
temporary fix, but I am currently waiting for Peter, since he is 
probably in a better position to produce a more proper fix.

> After having entered a flight path, planes keep halting after 
>having spent half
> of their fuel, despite the fact that there is a city waiting for them.

This behavior was present in Xconq prior to the new path 
code. I agree that it is annoying. If you move any unit past its 
SupplyLow threshold, you will see this behavior. Again, I am going 
to wait for Peter to make his move first before trying to do 
anything about it.

There is at least one complication here:
Suppose that a unit's path becomes blocked or its destination 
is captured while it is en route. If we blindly follow the path, 
ignoring the SupplyLow indicators, then we risk losing or 
paralyzing the unit due to overconsumption of supplies. I suppose 
that one could recheck the path for blockage after each move, but 
this might be costly in terms of CPU (it would still be cheaper 
than recomputing the path after each move, I think).

> Have I mentioned yet, that I would love to see patrols implemented?

I think we all would. This is one of the things I intend to look 
into once we have 7.5 released.

> Still a fun game to play...

Thanks. I think so too.

  Regards,
    Eric

Re: Standard game problems in windows (20031214) version

[Bruno Boettcher]

On Tue, Dec 16, 2003 at 11:42:51AM -0500, Eric McDonald wrote:
Hello!

> This behavior was present in Xconq prior to the new path 
yep!
i address it with standing orders :D

> code. I agree that it is annoying. If you move any unit past its 
true!

> SupplyLow threshold, you will see this behavior. Again, I am going 
> to wait for Peter to make his move first before trying to do 
> anything about it.
that would be really nice!

> There is at least one complication here:
> Suppose that a unit's path becomes blocked or its destination 
> is captured while it is en route. If we blindly follow the path, 
> ignoring the SupplyLow indicators, then we risk losing or 
> paralyzing the unit due to overconsumption of supplies. I suppose 
> that one could recheck the path for blockage after each move, but 
> this might be costly in terms of CPU (it would still be cheaper 
> than recomputing the path after each move, I think).
what about recomputing the path to the nearest resupply source when we
hit the low supply case (and eventually compare it to the destination)?

> > Have I mentioned yet, that I would love to see patrols implemented?
> 
> I think we all would. This is one of the things I intend to look 
> into once we have 7.5 released.
wheres the problem? they are allready implemented???
i use regularly patrols since years now??? .....
the solution are standing orders....
the only problem i have is that i seem unable to clear standing orders,
  i can only redirect them, since the 'none' task has a real bad
  behaviour on fighters :D

> Thanks. I think so too.
yup definitely :D

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

Re: Standard game problems in windows (20031214) version

[Eric McDonald]

Hi Bruno ("Mr. Standing Orders"),

On Tue, 16 Dec 2003, Bruno Boettcher wrote:

> > paralyzing the unit due to overconsumption of supplies. I suppose 
> > that one could recheck the path for blockage after each move, but 
> > this might be costly in terms of CPU (it would still be cheaper 
> > than recomputing the path after each move, I think).
> what about recomputing the path to the nearest resupply source when we
> hit the low supply case (and eventually compare it to the destination)?

I don't think we should automatically move in any direction other 
than that specified by the user. Second-guessing the player is 
generally not a good idea.

> wheres the problem? they are allready implemented???
> i use regularly patrols since years now??? .....
> the solution are standing orders....

If you feel like creating 3 or 4 for various coordinates, __in a 
graphical interface. Look, I am a keyboard's best friend, but 
there are times when a few clicks are better at getting the job 
done (except in the curses interface :-). This is how patrols are 
set up in Strategic Conquest and Empire Master, and I think it is 
more efficient to do things this way. Also, it just might give 
some better competition to people who use standing orders 
heavily.... :-)

  Regards,
    Eric

Re: Standard game problems in windows (20031214) version

[Bruno Boettcher]

On Tue, Dec 16, 2003 at 02:22:55PM -0500, Eric McDonald wrote:
> Hi Bruno ("Mr. Standing Orders"),
  :D

> > what about recomputing the path to the nearest resupply source when we
> > hit the low supply case (and eventually compare it to the destination)?
> 
> I don't think we should automatically move in any direction other 
> than that specified by the user. Second-guessing the player is 
> generally not a good idea.
true, but claiming low supply with resupply possibilies nearby isn't
very optimal either... besides the engine knows where the unit should
go, isn't it? if the path seems clear, there shouldn't be IMHO a
questioning about low supply, that was all i was suggesting :D

> If you feel like creating 3 or 4 for various coordinates, __in a 
> graphical interface. Look, I am a keyboard's best friend, but 
heh if you remember i am whining for years now for a better support of
standing orders in the GUI's :D

> there are times when a few clicks are better at getting the job 
> done (except in the curses interface :-). This is how patrols are 
> set up in Strategic Conquest and Empire Master, and I think it is 
> more efficient to do things this way. Also, it just might give 
i would allready be happy if clicking in a cell whilst editing a
stnading order the cell-coordinates would be inserted into the command
line...

> some better competition to people who use standing orders 
> heavily.... :-)
:D :D
BTW i made just this lunchtime break a tutoring game with my friends
here (means we played with all 3 visuals on one machine) and i showed
them (finally ;) the standing order mechanism, and there appeared that
as i thought, that mechanism moves the units way more efficently than
you can do by hand, due to the order in which the units are presented!

so indeed and as ever: standing order rules! :D

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

Re: Standard game problems in windows (20031214) version

[Jim Kingdon]

> true, but claiming low supply with resupply possibilies nearby isn't
> very optimal either... besides the engine knows where the unit should
> go, isn't it? if the path seems clear, there shouldn't be IMHO a
> questioning about low supply, that was all i was suggesting :D

In the case where the player has given a destination which would
resupply the unit, this seems fair.

Otherwise, seems like the player should need to explicitly hit the "r"
(resupply) key if that is what they want.

Re: Standard game problems in windows (20031214) version

[Peter Garrone]

On Tue, Dec 16, 2003 at 06:09:46PM -0500, Jim Kingdon wrote:
> > true, but claiming low supply with resupply possibilies nearby isn't
> > very optimal either... besides the engine knows where the unit should
> > go, isn't it? if the path seems clear, there shouldn't be IMHO a
> > questioning about low supply, that was all i was suggesting :D
> 
> In the case where the player has given a destination which would
> resupply the unit, this seems fair.
> 
> Otherwise, seems like the player should need to explicitly hit the "r"
> (resupply) key if that is what they want.

As I have indicated previously, I am thinking of implementing it so that
aircraft will fly from A to B via a refuel point C automatically.
Otherwise it all gets a bit too tedious.

Re: Standard game problems in windows (20031214) version

[Peter Garrone]

On Tue, Dec 16, 2003 at 06:18:55PM +0100, Bruno Boettcher wrote:
> On Tue, Dec 16, 2003 at 11:42:51AM -0500, Eric McDonald wrote:
> Hello!
> 
> > This behavior was present in Xconq prior to the new path 
> yep!
> i address it with standing orders :D
> 
> > code. I agree that it is annoying. If you move any unit past its 
> true!
> 
> > SupplyLow threshold, you will see this behavior. Again, I am going 
> > to wait for Peter to make his move first before trying to do 
> > anything about it.
> that would be really nice!

I better reply in some detail about how I intend to address this.
The path-finding node state will include not only the geometric position
but also the amount of material in each category. As the unit passes a
refueling point, the supply will be repleneshed. Two nodes will have
equivalent state if their material supply and geometric position are
equivalent, also their transportation state. I am currently modifying
path.c and task.c, but certainly cant yet compile the code, its still
in a design phase really.

I still havent quite worked out how to ensure the unit gets to point B
with enough fuel to fly back to a resupply point. Possibly a pseudo
target of getting to a resupply point after reaching the destination
would work here, so that a destination is re-fuelable, for the AI anyway.
The statenode, when it reaches its x,y target, gets a flag set, so
that the final target is a refueling point, and the unit has enough fuel to return
across whatever terrain is there.

> 
> > There is at least one complication here:
> > Suppose that a unit's path becomes blocked or its destination 
> > is captured while it is en route. If we blindly follow the path, 
> > ignoring the SupplyLow indicators, then we risk losing or 
> > paralyzing the unit due to overconsumption of supplies. I suppose 
> > that one could recheck the path for blockage after each move, but 
> > this might be costly in terms of CPU (it would still be cheaper 
> > than recomputing the path after each move, I think).
> what about recomputing the path to the nearest resupply source when we
> hit the low supply case (and eventually compare it to the destination)?

The attention post 7.5 is to move the path-finding above the networking,
so the cpu problem isnt so bad. It should also be possible to inspect
the cached path to ensure that all nodes are outside zoc and also that
all refueling points are available, and if waiting for a ferry if the
ferry is not sunk. Also a path recalculation every N
hexes or perhaps every move probably is reasonable, if a ferry isnt
scheduled to pick the unit up.

Unfortunately the AI seems to generate distant targets in some games.

Peter

Re: Standard game problems in windows (20031214) version

[Peter Garrone]

On Tue, Dec 16, 2003 at 02:22:55PM -0500, Eric McDonald wrote:
> Hi Bruno ("Mr. Standing Orders"),
> 
> On Tue, 16 Dec 2003, Bruno Boettcher wrote:
> 
> > > paralyzing the unit due to overconsumption of supplies. I suppose 
> > > that one could recheck the path for blockage after each move, but 
> > > this might be costly in terms of CPU (it would still be cheaper 
> > > than recomputing the path after each move, I think).
> > what about recomputing the path to the nearest resupply source when we
> > hit the low supply case (and eventually compare it to the destination)?
> 
> I don't think we should automatically move in any direction other 
> than that specified by the user. Second-guessing the player is 
> generally not a good idea.

I disagree. The path-finding implies that a move is possibly different.
An aircraft, directed to go from A to B, might fly to C to get some
fuel.

Re: Standard game problems in windows (20031214) version

[Eric McDonald]

Hi Peter, others,

On Wed, 17 Dec 2003, Peter Garrone wrote:

> > I don't think we should automatically move in any direction other 
> > than that specified by the user. Second-guessing the player is 
> > generally not a good idea.
> 
> I disagree. The path-finding implies that a move is possibly different.
> An aircraft, directed to go from A to B, might fly to C to get some
> fuel.

I don't entirely disagree when one is precomputing a path, though 
I still think that one must think about how tight do you want to 
keep the fuel budget when determining a path. If you say that a 
unit should refuel once it has traversed enough path to use 50% of 
its fuel, then you are quite possibly producing a very inefficient 
path, even if it is the only one that is essentially guaranteed to 
be safe. 

The case I was looking at was: what happens if we get a certain 
distance along a path and find that our primary refueling 
opportunity might have vanished? And my answer is the same as 
Jim's: the user needs to decide. Obviously if the 
refueling point is on the path and can be reached/utilized, then 
you let the automatic movement continue without user intervention; 
I certainly was not disputing that....

  Regards,
    Eric