This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: find_next_occupant vs. autonext_unit
- To: Jim Kingdon <kingdon at panix dot com>
- Subject: Re: find_next_occupant vs. autonext_unit
- From: Hans Ronne <hronne at pp dot sbbs dot se>
- Date: Mon, 16 Oct 2000 20:23:53 +0100
- Cc: xconq7 at sources dot redhat dot com
>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