[CF-Devel] [Bug 34] New - Can't stop running until obstacle hit
bugs at real-time.com
bugs at real-time.com
Wed Jul 5 10:33:27 CDT 2000
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.
More information about the crossfire
mailing list