http://bugzilla.real-time.com/show_bug.cgi?id=34 *** shadow/34 Wed Jul 5 10:33:27 2000 --- shadow/34.tmp.29013 Wed Jul 5 10:33:27 2000 *************** *** 0 **** --- 1,85 ---- + Bug#: 34 + Product: Crossfire + Version: 0.95.6 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: normal + Priority: P3 + Component: X11 Client + AssignedTo: crossfire-devel at lists.real-time.com + ReportedBy: frank_mckenney at mindspring.com + URL: + Cc: + Summary: Can't stop running until obstacle hit + + Server: 0.95.6 public release + Intel x86 PC, 486DX4-100, 32 Mb RAM, SuSE Linux 6.4 + Client: 0.95.6 public release (X11 client) + (same machine) + + Also occurs on CVS 2000/07/04 + + The "Run" key (Ctl on Linux X11 client) is an extremely useful feature. + It provides much more responsive control over movement than (e.g.) + building up a huge "stack" of comands by holding down the "east" key + "for a while" (;-). + + Normally, movement controled by the Run key will halt as soon as the Run + key is released. However, in CF 0.95.6 under certain circumstances it + may be difficult or impossible to stop until an obstacle is hit. + + An example: after starting the Linux X11 client and logging my + character in to the server, I left the Permanent Apartments in Scorn and + single-stepped at a leisurely pace over to westernmost signpost + ("Welcome to Crossfire"). I then held down Ctl key and pressed + right-arrow key ("east") briefly. + + "Run On" appeared in status window, and did not disappear until I had + run over to eastern gatehouse, the inner gate had opened, and I had run + all the way to the outer gate. Pressing and releasing the Ctl key had + no effect - my character just kept running. + + Frequently, on leaving Scorn by the East Gate, if I do a _brief_ + Ctl-"east" as soon as I am past the outer gate, I will start running and + not stop until I hit some spot in the mountains (map boundary?). + + In all cases, once movement has started, nothing seems to stop it until + some obstacle is encountered. + + This seems to happen more frequently just after entering a map, but (as + in my example) some "normal" single-step movement may take place in that + map first. It can also occur some time after a map has been entered. + + Speculation: The "run_stop" command does not seem to have gotten + _lost_, merely delayed, since I don't wind up with my poor character + permanently beating his head against a wall (although it is a good thing + that the guard in the inner gate has a very forgiving nature). + + Also, I usually notice this problem when my character is moving into a + part of a map where it has never been, or has not yet traversed or + seen on the current visit to the current map. + + I'm not familiar with the way the server updates the client's map, but + if it is done as-needed rather than on an everything-at-entry-to-map + basis, and if a "run_stop" is _not_ given precedence over either of + + a) Movement, or + b) The transfer of map information, + + then we have a nasty situation. The character "runs" into unvisited + territory, and continues to move as the server refreshes that portion of + the map. But the character continues moving into yet-newer territory, + requiring further map refresh... until the character finally runs into + something that stops it long enough for everything to catch up. + + Whatever the actual cause, the root problem is the same: the + character's movement cycle is never interrupted by the "run_stop" + command the client is (presumably) sending. + + Severity: If you're not aware of it, this one can drastically shorten + one's current incarnation; Crossfire is not a game that takes kindly to + repeated assaults on random characters (the gate guard is a notable + exception (;-)). However, with some caution, this one can be lived + with/mostly avoided.