Subject: bin/8304: atc(6) command processing problem
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 08/31/1999 16:35:42
>Synopsis: delayed commands in atc(6) sometimes get executed too early
>Responsible: bin-bug-people (Utility Bug People)
>Arrival-Date: Tue Aug 31 16:35:00 1999
>Originator: David A. Holland <firstname.lastname@example.org>
- David A. Holland | VINO project home page:
email@example.com | http://www.eecs.harvard.edu/vino
>Release: NetBSD-current 19990831
System: NetBSD syrah 1.3.2 NetBSD 1.3.2 (GENERIC) #0: Sun May 24 19:45:48 EDT 1998 firstname.lastname@example.org:/usr/src/sys/arch/i386/compile/GENERIC i386
(Ignore that, it's the only netbsd machine I could find to run
I'm actually working with a copy of atc from -current of a couple
months ago (rev 1.11 of input.c) but I checked cvsweb to make sure
nobody's already fixed the problem, and they don't seem to have.
If you enter a delayed turn command, such as
(plane a turn to 090 at beacon #1), the plane isn't supposed to
actually execute the turn until it reaches beacon #1. It seems
that under some circumstances the input processor causes the
delay flag to get dropped, so the plane turns at the wrong point
(thus leading to massive chaos in-game...)
The following sequence of operations will trigger the bug:
- order a plane to a different altitude.
- wait a tick or two.
- before it reaches this altitude, give it a delayed turn
- then (on the same clock tick) order the plane again to
the same altitude as before.
This is seen, for instance, on the Atlantis board when planes
leave airport 0 for exit 2. Repeatedly ordering the plane to the
same altitude is not entirely uncommon...
The input module copies the plane structure into a temporary,
frobs it, and copies it back. This is how it handles issuing
orders. The trouble is, when it copies it back, it chooses
what to copy back based on what's changed. So if you order a
plane to the same altitude it was already ordered to (but not
the altitude it's already at, because that gives an error) it
doesn't think it's an altitude order; it thinks it's a turn
order, and copies the turn information back from the temporary.
This would be ok also if it weren't for the fact that when it
copies into the temporary, it clears the delayed-turn flag.
So when it copies back, the delayed-turn flag disappears, and
see the incorrect behavior described above.
The trouble is, the input processor relies on that flag being
cleared to handle turn commands correctly; there's no place
better for the code to clear it, and the state stuff only sets
One could conceivably kludge around the problem, but I think
the real answer is to rewrite the input code. I have not done
this yet; I'm posting this PR in the hope that somebody else
will see a clean and simple way to fix it that I've overlooked.
Don't have one yet; see description.