Subject: bin/8304: atc(6) command processing problem
To: None <>
From: None <>
List: netbsd-bugs
Date: 08/31/1999 16:35:42
>Number:         8304
>Category:       bin
>Synopsis:       delayed commands in atc(6) sometimes get executed too early
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 31 16:35:00 1999
>Originator:     David A. Holland <>
   - David A. Holland             |    VINO project home page:    |
>Release:        NetBSD-current 19990831
System: NetBSD syrah 1.3.2 NetBSD 1.3.2 (GENERIC) #0: Sun May 24 19:45:48 EDT 1998 i386

	(Ignore that, it's the only netbsd machine I could find to run
	send-pr on.)

	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.

	See description.

	Don't have one yet; see description.