Cannot do anything in water

Cannot do anything in water

[Lincoln Peters]

I was trying to work on my new game module, and now I've found that, if
I try to make a unit move into a water cell (and it can enter water
cells), it expends 1 ACP but does not go anywhere!

I also found that, if a unit can create and build other units at range
>0, and tries to create a unit on water, the newly-created unit instead
appears at a seemingly-random land cell within create-range!

My new module uses the stdterr.g module for terrain, although I don't
see anything in my file or stdterr.g that would cause such behavior. 
Could it be a bug in the new pathfinding algorithm?


Lincoln Peters <sampln@sbcglobal.net>

Re: Cannot do anything in water

[Jim Kingdon]

> I was trying to work on my new game module, and now I've found that, if
> I try to make a unit move into a water cell (and it can enter water
> cells), it expends 1 ACP but does not go anywhere!

Probably the same bug as
http://sources.redhat.com/ml/xconq7/2003/msg00960.html

> Could it be a bug in the new pathfinding algorithm?

That would be my guess.

Re: Cannot do anything in water

[Hans Ronne]

>> I was trying to work on my new game module, and now I've found that, if
>> I try to make a unit move into a water cell (and it can enter water
>> cells), it expends 1 ACP but does not go anywhere!
>
>Probably the same bug as
>http://sources.redhat.com/ml/xconq7/2003/msg00960.html
>
>> Could it be a bug in the new pathfinding algorithm?

Maybe. But not the construction problem since it does not involve
path-finding. If both are manifestations of the same bug, I would rather
suspect the terrain occupancy code.

OTOH, The construction bug sounds more like an undefined action being
allowed following an illegal click. The program should just beep instead
and refuse to do anything if you click in the wrong cell.

Hans

Re: Cannot do anything in water

[Lincoln Peters]

On Mon, 2003-12-08 at 11:39, Hans Ronne wrote:
> >> I was trying to work on my new game module, and now I've found that, if
> >> I try to make a unit move into a water cell (and it can enter water
> >> cells), it expends 1 ACP but does not go anywhere!
> >
> >Probably the same bug as
> >http://sources.redhat.com/ml/xconq7/2003/msg00960.html

It does look similar, although I don't think that I ever saw it happen
to land units as they moved across land (and my new game does not
contain air units).

> >
> >> Could it be a bug in the new pathfinding algorithm?
> 
> Maybe. But not the construction problem since it does not involve
> path-finding. If both are manifestations of the same bug, I would rather
> suspect the terrain occupancy code.

If that code could prevent movement while still causing a unit to
consume ACP, I imagine that it might be the source of the problem.

> 
> OTOH, The construction bug sounds more like an undefined action being
> allowed following an illegal click. The program should just beep instead
> and refuse to do anything if you click in the wrong cell.

That's not what I've observed.  I've often found that if the cell I tell
it to build in is illegal (e.g. try to build a city in the water), but
it can build in a nearby legal cell without moving (the cell is within
its create-range), it will build in that alternate location instead. 
And it never asks if that is what I want to do.

Although I suppose that there could be two bugs at work here...


Lincoln Peters <sampln@sbcglobal.net>

Re: Cannot do anything in water

[Hans Ronne]

>> OTOH, The construction bug sounds more like an undefined action being
>> allowed following an illegal click. The program should just beep instead
>> and refuse to do anything if you click in the wrong cell.
>
>That's not what I've observed.  I've often found that if the cell I tell
>it to build in is illegal (e.g. try to build a city in the water), but
>it can build in a nearby legal cell without moving (the cell is within
>its create-range), it will build in that alternate location instead.
>And it never asks if that is what I want to do.

That's what I meant. The computer should never do that. If you try to do
something which is not permitted, it should just beep at you. So this is
definitely a bug.

Hans

Re: Cannot do anything in water

[Lincoln Peters]

On Mon, 2003-12-08 at 15:24, Hans Ronne wrote:
> >That's not what I've observed.  I've often found that if the cell I tell
> >it to build in is illegal (e.g. try to build a city in the water), but
> >it can build in a nearby legal cell without moving (the cell is within
> >its create-range), it will build in that alternate location instead.
> >And it never asks if that is what I want to do.
> 
> That's what I meant. The computer should never do that. If you try to do
> something which is not permitted, it should just beep at you. So this is
> definitely a bug.

True, but at the time, my game was set up so that one *could* build
stuff on water cells (and those units would not instantly vanish or
wreck).  This was so that, although most units cannot cross bodies of
water on their own, many could build simple boats to carry them across.

I think that this means that there are, in fact, two or more bugs at
work here.


Lincoln Peters <sampln@sbcglobal.net>

Re: Cannot do anything in water

[Lincoln Peters]

I have found that this mysterious water bug affects bolodd2.g, as well
as the new game I'm working on.  If you try to move a naval unit into
the water (I haven't tried air units yet), the unit expends an ACP
without going anywhere.

I also noticed that, in roman.g, an infantry sometimes expends an ACP
while trying to cross a river, but doesn't actually cross the river. 
Even stranger, if I tell it to move to a non-adjacent cell, it seems
that the ACP readout shows "ACP 1", when it should say "ACP 1/2"!  This
usually seems to happen when the unit could have avoided crossing the
river and spent as many or fewer ACP's by going around it (no problems
if there is no way around the river).  Perhaps the same bug?  Or at
least a related bug?


Perhaps someone who understands the recent changes to the pathfinding
code could look at bolodd2.g and roman.g and make some sense out of this
mysterious problem.

Meanwhile, I'll keep looking for more clues...


-- 
Lincoln Peters <sampln@sbcglobal.net>

Re: Cannot do anything in water

[Jim Kingdon]

> I also noticed that, in roman.g, an infantry sometimes expends an ACP
> while trying to cross a river, but doesn't actually cross the river. 
> Even stranger, if I tell it to move to a non-adjacent cell, it seems
> that the ACP readout shows "ACP 1", when it should say "ACP 1/2"!

roman.g is a bit strange with respect to ACP because it sets acp-min
to negative values.

You might want to try with an older version of xconq to compare.  Or
perhaps if you have been playing roman.g for a while, you already are
familiar with how acp-min affects things.

Re: Cannot do anything in water

[Lincoln Peters]

On Sun, 2003-12-14 at 20:38, Jim Kingdon wrote:
> > I also noticed that, in roman.g, an infantry sometimes expends an ACP
> > while trying to cross a river, but doesn't actually cross the river. 
> > Even stranger, if I tell it to move to a non-adjacent cell, it seems
> > that the ACP readout shows "ACP 1", when it should say "ACP 1/2"!
> 
> roman.g is a bit strange with respect to ACP because it sets acp-min
> to negative values.

Actually, I used acp-min in bolodd2.g.  Although I do notice one
difference between roman.g's use of acp-min and bolodd2.g's use of it:
roman.g allows ACP to spend twice as many ACP's as it gets every turn
(e.g. if infantry gets 2 ACP per turn, it may go down to -2 ACP).  This
means that if a unit performs a difficult task (e.g. crosses a river) or
is under heavy fire, it will have a total of 0 ACP at the start of the
next turn.  In bolodd2.g, the units I defined differed only in that they
would always have at least 1 ACP at the start of each turn (e.g. a tank
that gets 4 ACP per turn can only go down to -3 ACP).

It's not a very big difference in how acp-min is used; if acp-min was
the culprit, I'd expect the bug to produce the same effects in bolodd2.g
and roman.g (and it doesn't; roman.g doesn't have any problems with
naval units).

-- 
Lincoln Peters <sampln@sbcglobal.net>

More clues about that evasive pathfinding bug

[Lincoln Peters]

Yet another instance of a unit spending an ACP without doing anything:

In bellum.g, few units exert ZOC against air units, therefore an air
unit should be able to fly over hostile units without difficulty. 
However, I tried to make a spy plane fly over a Germinator, and the spy
plane spent an ACP without moving anywhere!  However, I noticed that the
spy plane did not use up any materials ("f1" and "c") in the process.

Hopefully someone who understands the new pathfinding better than I do
will see a common thread amongst these bug reports...

-- 
Lincoln Peters <sampln@sbcglobal.net>

Re: More clues about that evasive pathfinding bug

[Lincoln Peters]

Perhaps I should have waited before clicking "Send", in case the bug
manifested itself in another way.

This happened later in that same bellum.g game.  The game appears to be
set up so that paratroopers cannot fight while occupying a cargo plane. 
Previously, if paratroopers were in a cargo plane, and I instructed them
to attack, Xconq would just beep at me and say "(unit name) in unable to
act, don't know why".  This time, it burned an ACP, did nothing, and
gave no indication of an error.

The same thing (burn an ACP without doing anything) seems to happen if I
try to make a unit attack another unit that it cannot attack
(acp-to-attack = 0).

There seem to be additional random events that trigger the bug, and I'm
still trying to find a pattern.

-- 
Lincoln Peters <sampln@sbcglobal.net>

Re: More clues about that evasive pathfinding bug

[Eric McDonald]

Hi Lincoln, others,

On Wed, 17 Dec 2003, Lincoln Peters wrote:

> try to make a unit attack another unit that it cannot attack
> (acp-to-attack = 0).

I will try to track it down this weekend, unless someone else 
beats me to it.

Thanks for the reports.

Eric