Re: find_next_occupant vs. autonext_unit

[Jim Kingdon <kingdon at panix dot com>]

The enclosed fix solves the immediate problem but it can cause an
infinite loop:

+--bomber ACP 1/6--+ +--bomber ACP 0/6--+
| inf ACP 0/1      | | inf ACP 0/1      |
+------------------+ +------------------+

One way to fix it (robust against find_next_occupant bugs) is to keep
a list of everything that find_next_occupant has returned, but I can't
help but think there is something simpler.  Maybe find_next_occupant
has a bug in that it isn't making it back to the original unit passed
in?

> Never seen this happen in the mac interface, but it uses
> find_next_awake_mover instead of autonext_unit.

Am I misreading the mac code?  Seems like maybe_select_next_unit in
macconq.c will call autonext_unit first and only then
find_next_awake_mover.

Index: kernel/ui.c
===================================================================
RCS file: /cvs/xconq/xconq/kernel/ui.c,v
retrieving revision 1.53
diff -u -r1.53 ui.c
--- ui.c	2000/09/16 12:54:29	1.53
+++ ui.c	2000/10/18 18:06:46
@@ -2355,6 +2355,22 @@
     if (could_be_next_unit(unit) && side_controls_unit(side, unit))
 	return unit;
 
+    /* First look for a unit within the same hex.  Otherwise we might
+       cause a strange situation where do_occupant selects a unit which
+       isn't ready to move and the event loop goes back to the original
+       unit, skipping some of the occupants.  */
+    if (unit != NULL) {
+	Unit *nextocc = unit;
+
+	for (;;) {
+	    nextocc = find_next_occupant(nextocc);
+	    if (nextocc == NULL || nextocc == unit)
+		break;
+	    if (could_be_next_unit(nextocc))
+		return nextocc;
+	}
+    }
+
     if (unit == NULL) {
 	u = 0;
 	if (!nearest_cell(vp, vp->sx + vp->pxw / 2, vp->sy + vp->pxh / 2, &mx, &my, NULL, NULL)) {