Re: bug: unit->busy flag doesn't get cleared

[Hans Ronne <hronne at pp dot sbbs dot se>]

>The symptom: when you try to move a unit (including actions such as
>"enter" but not things like Reserve which is not considered an
>action), it will refuse to do anything.  Examining the state in a
>debugger reveals that the unit->busy flag got stuck on (it is supposed
>to be set when an action is queue and cleared when that action is
>executed).  At the end of the turn, everything gets reset (per
>explicit code which clears unit->busy then).
>
>What makes this happen?  I saw it in the standard game.  The stuck
>unit was always an infantry unit and there were always various bombers
>about.  I think there was an "enter" action around the time it got
>stuck, although I couldn't say for sure.

So had the bomber(s)moved away when the unit got stuck? That might explain
things. The unit got an embark command but can no longer execute the
action. Still, the flag is cleared even if execute_action fails. So this
must mean that the unit either is out of acps or failed to prep the action.
But in the former case, it should never become the current unit, and in the
latter case, the flag should not be set. Weird. If you can catch the bug in
a  debugging session, we might be able to figure out what is going on.

>Possible way to workaround/ameliorate the situation: Make unit->busy
>user-visible (like Reserve and flags like that).  This won't prevent
>this bug from arising, but it will make it easier for the user to
>figure out why the unit won't move.  Right now, it is totally
>mysterious unless you happen to know about the bug.

Making the busy flag visible would certainly help debugging, but not solve
the problem.

A possible fix would be to make sure the busy unit cannot become the
current unit (it shouldn't, but apparently it does). Try this patch:

int
could_be_next_unit(Unit *unit)
{
    return (unit != NULL
	    && alive(unit)
	    && inside_area(unit->x, unit->y)
	    && has_acp_left(unit)
	    && (unit->plan
+	    	&& !unit->busy
		&& !unit->plan->asleep
		&& !unit->plan->reserve
		&& !unit->plan->delayed
		&& unit->plan->waitingfortasks));
}

I have tested it, and it does not seem to do any harm. Can't tell if it
fixes the bug, since I have not yet been able to reproduce it.

Hans


Hans Ronne

hronne@pp.sbbs.se