[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