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: bug in infantry building a base which is already started


>>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



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