Re: find_next_occupant vs. autonext_unit

[Stan Shebs <shebs at shebs dot cnchost dot com>]

Jim Kingdon wrote:
> 
> 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.

Ah yes, the infamous "next unit to move" problem.  This is a longstanding
issue, no solution is completely superior.  In fact, I asked about how
to optimize it (to minimize screen redraws) on comp.theory years ago,
and it's still on a list of open geometry problems on the net...

Networking introduces an additional wrinkle in that units moving under
automation must all be done in the same order, independently of
screen size, move/survey mode, etc.  Thus the "actionvector" which
introduces a fixed order of action execution.  It's not sorted
except by unit move priority (which isn't actually used in any game
right now), so one option would be to use the find_next_occupant
algorithm when sorting it.

The other option would be to introduce a little more heuristic into
autonext_unit, since it's for the use of interfaces and can be as
helpful as we want.  So we can iterate on find_next_occupant until
we find a could_be_next_unit or end up back where we started, in
which case we continue with the original scan of the actionvector.
This is a better option I think, because it will reflect the units'
movement during a turn.

Stan