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]

find_next_occupant vs. autonext_unit


OK, here's a scenario from the standard game (maybe I should be
sending a saved game instead of ASCII art, but here you go):

+---- town ---------------+
|                         |
| +-bomber-+  infantry#14 |
| |        |  1/4th built |
| | inf#8  |              |
| +--------+              |
+-------------------------+

In case that's not self-explanatory, it is a town with two occupants
(infantry#14 and a bomber), where the bomber has one occupant
(infantry#8).

Suppose infantry #8 is selected and then you type the "i" key
(do_occupant in tkcmd.c).  In survey mode everything is wonderful.
The lovely code in find_next_occupant cycles through the units in
delightful fashion (#8->#14->town->bomber->#8).

For a bad time go to move mode, though.  find_next_occupant selects
#14.  Then you get to tk_run_game_idle.  It correctly notices that #14
can't do anything, and then puts you back to.....#8.....via
autonext_unit which has a rather different algorithm than
find_next_occupant.  So instead of the desired cycle (#8->bomber->#8)
you get an abbreviated cycle (#8->#8).

So, should autonext_unit be calling find_next_occupant before it
starts using its existing algorithm (which can also find units on
different hexes)?  Don't think I can quickly come up with a good fix
for this one given my current level of knowledge of the architecture.

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