find_next_occupant vs. autonext_unit

[Hans Ronne]

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

Never seen this happen in the mac interface, but it uses
find_next_awake_mover instead of autonext_unit. Perhpas that would work in
the tcltk case as well.

Hans

Hans Ronne

hronne@pp.sbbs.se