bug in infantry building a base which is already started

bug in infantry building a base which is already started

[Jim Kingdon]

I don't remember whether this has been reported recently, but there's
a bug in building.

In the standard game, have an infantry start building a base.  So far
so good.  Then put a second infantry in the base, and have it build a
base in the same location.  The correct behavior is for both infantry
to work together on building the same base (well, at least this is the
traditional behavior).  The buggy behavior is that the build command
seemed to work, but nothing happens (the base doesn't get further
built, and the infantry doesn't expend an ACP).

This is xconq from CVS as of 20 May 2004.

Re: bug in infantry building a base which is already started

[Eric McDonald]

On Sun, 23 May 2004, Jim Kingdon wrote:

> I don't remember whether this has been reported recently, but there's
> a bug in building.

No, really? :-)
I am beginning to think that the only thing that code builds 
correctly is bugs.

> In the standard game, have an infantry start building a base.  So far
> so good.  Then put a second infantry in the base, and have it build a
> base in the same location.  The correct behavior is for both infantry
> to work together on building the same base (well, at least this is the
> traditional behavior).  The buggy behavior is that the build command
> seemed to work, but nothing happens (the base doesn't get further
> built, and the infantry doesn't expend an ACP).

I started looking into it yesterday. I was able to reproduce it. 

Eric

Re: bug in infantry building a base which is already started

[Eric McDonald]

On Sun, 2004-05-23 at 21:45, Jim Kingdon wrote:

> In the standard game, have an infantry start building a base.  So far
> so good.  Then put a second infantry in the base, and have it build a
> base in the same location.  The correct behavior is for both infantry
> to work together on building the same base (well, at least this is the
> traditional behavior).  The buggy behavior is that the build command
> seemed to work, but nothing happens (the base doesn't get further
> built, and the infantry doesn't expend an ACP).

Well, for once, the report didn't actually lead to a problem in the
create/build code. The 'for_all_view_stack_with_occs' macro does not
consider the incomplete base for some reason, when it is going through
the unit views in the cell. Instead it finds both the infantry, and, of
course, they are not interested in building one another. And so the task
fails silently.

This raises an issue of whether side notification messages should be
generated by tasks or not. The UI and the various impl_* functions are
not omnipotent, and it might be wiser to report failures at the points
of failure instead of trying to guess them (as the UI does).

But the notification issue and the apparent bug in the unit view macro
aside, I believe I have fixed the bug that you reported. I just swapped
the 'for_all_view_stack_with_occs' with 'for_all_view_stack'. The only
reason I used the former to begin with was to handle the case where a
builder might want to work on another unit's occs.

Eric

Re: bug in infantry building a base which is already started

[Hans Ronne]

>Well, for once, the report didn't actually lead to a problem in the
>create/build code. The 'for_all_view_stack_with_occs' macro does not
>consider the incomplete base for some reason, when it is going through
>the unit views in the cell. Instead it finds both the infantry, and, of
>course, they are not interested in building one another. And so the task
>fails silently.
>
>This raises an issue of whether side notification messages should be
>generated by tasks or not. The UI and the various impl_* functions are
>not omnipotent, and it might be wiser to report failures at the points
>of failure instead of trying to guess them (as the UI does).
>
>But the notification issue and the apparent bug in the unit view macro
>aside, I believe I have fixed the bug that you reported. I just swapped
>the 'for_all_view_stack_with_occs' with 'for_all_view_stack'. The only
>reason I used the former to begin with was to handle the case where a
>builder might want to work on another unit's occs.

Actually, what macro you use doesn't make any difference, i.e. the second
infantry still refuses to join the build, and instead goes into passive
waiting mode.

However, if you override the view code by turning on see-all things work as
expected, with either macro. So it seems that the core unit view code is
the real culprit. The unit view code is unusual in that it uses a hash
table and "nextinhash" rather than the usual "nexthere".  The effect of
see-all is to overide the use of "nextinhash".

I always had a bad feeling about the view code and its hash table, since I
am not convinced that it works as expected in all circumstances. Maybe we
should take a closer look at it.

Hans

Re: bug in infantry building a base which is already started

[Hans Ronne]

>>But the notification issue and the apparent bug in the unit view macro
>>aside, I believe I have fixed the bug that you reported. I just swapped
>>the 'for_all_view_stack_with_occs' with 'for_all_view_stack'. The only
>>reason I used the former to begin with was to handle the case where a
>>builder might want to work on another unit's occs.
>
>Actually, what macro you use doesn't make any difference, i.e. the second
>infantry still refuses to join the build, and instead goes into passive
>waiting mode.
>
>However, if you override the view code by turning on see-all things work as
>expected, with either macro. So it seems that the core unit view code is
>the real culprit. The unit view code is unusual in that it uses a hash
>table and "nextinhash" rather than the usual "nexthere".  The effect of
>see-all is to overide the use of "nextinhash".
>
>I always had a bad feeling about the view code and its hash table, since I
>am not convinced that it works as expected in all circumstances. Maybe we
>should take a closer look at it.

A followup: the easiest way to fix the build code is of course to iterate
over units instead of unit views. Since that code is checking that the
builder and the target is on the same side, the latter will always be fully
visible to the builder, so there is really no point in using unit views
here.

This doesn't change the fact that the core unit view code needs to be
fixed, however.

Hans

Re: bug in infantry building a base which is already started

[Eric McDonald]

On Tue, 25 May 2004, Hans Ronne wrote:

> Actually, what macro you use doesn't make any difference, i.e. the second
> infantry still refuses to join the build, and instead goes into passive
> waiting mode.

Really? I thought I saw it join in the building. Or, at least, it 
moved inside the base and pretended to be doing something until 
the base was done. :-) Once I saw that, I was satisfied that the 
bug was fixed, and don't think that I actually went into survey 
mode and clicked on the 2nd infantry. Sounds like maybe I should 
have....

> However, if you override the view code by turning on see-all things work as
> expected, with either macro. So it seems that the core unit view code is
> the real culprit. 

This is what I actually suspected too, but because there is all 
this extra "->transport" and "->occupant" stuff in the "with_occs" 
version of the macro, I thought there might be a problem in 
there somewhere.

>The unit view code is unusual in that it uses a hash
> table and "nextinhash" rather than the usual "nexthere".  The effect of
> see-all is to overide the use of "nextinhash".

Right. I noticed this when I was investigating the problem last 
night. But, I was too tired to finish the deeper investigation, 
and went for a shallower "fix". Probably I should have went to bed 
instead of doing a CVS commit.

> I always had a bad feeling about the view code and its hash table, since I
> am not convinced that it works as expected in all circumstances. Maybe we
> should take a closer look at it.

I intend to, but probably not until the weekend. I have to finish 
preparing a presentation for next week at work. I also have to 
re-install Windows XP in its virtual machine, since I had a bit of 
a "mishap" with it on Sunday night, which is why I didn't release 
a new installer package then.

Eric

Re: bug in infantry building a base which is already started

[Eric McDonald]

On Wed, 26 May 2004, Hans Ronne wrote:

> A followup: the easiest way to fix the build code is of course to iterate
> over units instead of unit views. Since that code is checking that the
> builder and the target is on the same side, the latter will always be fully
> visible to the builder, so there is really no point in using unit views
> here.

I had considered what you suggest. However, one cannot assume that 
all units in a cell are on the same side as the builder. And since 
this is a task, and not an action-handler, we should not be giving 
the task special knowledge about another side's units. If we ever 
get to the point where we have a true client-server architecture, 
we may regret making such assumptions. This is why I still think 
it is better to loop through the unit views, and then retrieve the 
actual unit once we know it is on our side. If we loop through 
units instead, and compare their sides, then we are, in some 
sense, cheating.

Eric

P.S. I understand that with a real client-server architecture, we 
would not have direct access to the side's actual units either, 
but instead a shadow copy of them. Nonetheless, the above point is 
still valid, IMO.

Re: bug in infantry building a base which is already started

[Hans Ronne]

>On Wed, 26 May 2004, Hans Ronne wrote:
>
>> A followup: the easiest way to fix the build code is of course to iterate
>> over units instead of unit views. Since that code is checking that the
>> builder and the target is on the same side, the latter will always be fully
>> visible to the builder, so there is really no point in using unit views
>> here.
>
>I had considered what you suggest. However, one cannot assume that
>all units in a cell are on the same side as the builder. And since
>this is a task, and not an action-handler, we should not be giving
>the task special knowledge about another side's units. If we ever
>get to the point where we have a true client-server architecture,
>we may regret making such assumptions.

Maybe, but then we would have to rewrite the entire kernel. There are many
cases like this (not only in the action code) where units are accessed
directly, if it is safe to do so. In this specific case, it doesn't matter
if we access real units since enemy units are ignored and information about
them therefore cannot leak back to the interface or the AI.

I agree that a pure view-based kernel code might have some advantages. But
we are a far way from there.

Hans

Re: bug in infantry building a base which is already started

[Eric McDonald]

On Wed, 26 May 2004, Hans Ronne wrote:

> Maybe, but then we would have to rewrite the entire kernel. 

To some extent, yes.

>There are many
> cases like this (not only in the action code) where units are accessed
> directly, if it is safe to do so.

Yes, and it would probably be better if there were fewer such 
cases.

> In this specific case, it doesn't matter
> if we access real units since enemy units are ignored and information about
> them therefore cannot leak back to the interface or the AI.

True, except that I would regard the task as belonging to the UI 
or the AI that invoked it. To use Peter Garrone's terminology: the 
task is not referree code. Therefore, it should not be privy to 
the underlying unit data structures.

> I agree that a pure view-based kernel code might have some advantages. But
> we are a far way from there.

Yes, but, a journey of a 1000 miles begins with a first step, to 
quote an old professor of mine.

If we work on weeding out the direct unit accesses as we encounter 
them in the non-action code, then we will be in better shape when 
(and I suppose, if) the time comes to make the transition to true 
client-server. This is the philosophy I have been operating 
under, anyway. Otherwise, unit views don't mean too much to me in 
some cases.

Eric

Re: bug in infantry building a base which is already started

[Hans Ronne]

>Yes, but, a journey of a 1000 miles begins with a first step, to
>quote an old professor of mine.
>
>If we work on weeding out the direct unit accesses as we encounter
>them in the non-action code, then we will be in better shape when
>(and I suppose, if) the time comes to make the transition to true
>client-server. This is the philosophy I have been operating
>under, anyway. Otherwise, unit views don't mean too much to me in
>some cases.

It would probably be a good idead in that case to make the unit views work
more like real units. I took some steps in that direction last spring when
I added occupant-transport relationships and garbage collection to the unit
view code. But there are still very significant differences not only
between the unit and unit view structures, but also in how they are
handled. Like the hash table.

Hans

Overwatch and Counterbattery?

[Elijah Meeks]

Does Xconq have any support for fire-protection? 
Specifically, I'm thinking of two forms, the one being
firing upon a unit that comes within range, which as I
understand it is called Overwatch in the various
turn-based games I've played.  The other would be
firing on a unit after that unit has fired, which is
basically Counterbattery fire.  The latter has
something to do with being made aware of a unit, but I
think for Xconq purposes, setting a table such as
uu-protection-fire-chance which would define the
percent chance that u1 will fire on u2 if u2 fires and
is in range.  This would produce the same effect, I
think, as to break down an admittedly more realistic,
but likely more complicated system of determining a
unit's threat level on-the-fly or simply having units
expend ACP/material firing on the first unit to get
close to them (An effect that could be achieved with
the proposed table by saying u1 u* 100).

Elijah


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Overwatch and Counterbattery?

[Hans Ronne]

>Does Xconq have any support for fire-protection?
>Specifically, I'm thinking of two forms, the one being
>firing upon a unit that comes within range, which as I
>understand it is called Overwatch in the various
>turn-based games I've played.

In a way, yes. The u_ai_tactical_range variable controls within what range
a given unit type will take notice of an enemy unit. If you have a unit
that can fire and set the range to 12 it will fire on any enemy unit that
it can hit which comes within 12 cells.

The other would be
>firing on a unit after that unit has fired, which is
>basically Counterbattery fire.  The latter has
>something to do with being made aware of a unit, but I
>think for Xconq purposes, setting a table such as
>uu-protection-fire-chance which would define the
>percent chance that u1 will fire on u2 if u2 fires and
>is in range.

There is automatic counterattack and countercapture after every attempt to
hit or capture, which is determined by the uu_counterattack and
uu_countercapture tables. I don't think there is anything similar for the
firing code. I'm not sure why. Perhaps it was thought that this automatic
hit back was something that should happen only at close quarters.

Hans

Re: Overwatch and Counterbattery?

[Eric McDonald]

On Wed, 2004-05-26 at 15:32, Hans Ronne wrote:
> >Does Xconq have any support for fire-protection?
> >Specifically, I'm thinking of two forms, the one being
> >firing upon a unit that comes within range, which as I
> >understand it is called Overwatch in the various
> >turn-based games I've played.
> 
> In a way, yes. The u_ai_tactical_range variable controls within what range
> a given unit type will take notice of an enemy unit. If you have a unit
> that can fire and set the range to 12 it will fire on any enemy unit that
> it can hit which comes within 12 cells.

In terms of non-AI response, it seems that something could be rigged
together in terms of ZOC checking. So if the defender extended a ZOC out
to, say, a radius of 3, and something came inside the ZOC (it would have
to be allowed inside, since ZOC's are blocking by default), then perhaps
it should be subject to an automatic ranged attack/fire response. This
would probably be best done during the movement of the intruder, because
that is where ZOC coverage is already checked, IIRC.

Could make for some interesting tactical situations, where an evasive,
hard-to-hit unit sweeps into the ZOC, and then darts back out, causing
the defender to waste ACP firing before the real attackers enter.... Of
course, the availability of such a tactic might indicate a game design
flaw.

Eric