This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
find_next_occupant vs. autonext_unit
- To: xconq7 at sources dot redhat dot com
- Subject: find_next_occupant vs. autonext_unit
- From: Jim Kingdon <kingdon at panix dot com>
- Date: Mon, 16 Oct 2000 01:54:05 -0400 (EDT)
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.