http://sourceforge.net/tracker/index.ph ... tid=106185
I had to ignore it until now because it is one of those anonymous reports without enough information. From nemo's comment I conclude that it appears the brake is permanently on on the server and only a reset of the brake cures it.
Anyway, some new bugfixes on CVS server 2 that actually may be related:
- Client commands are now sorted based on their network message id, which makes them always appear in order. This should fix everything where two commands are passed virtually at the same time: hitting brake and turn simultaneously, tight 180s, small adjustments to a wall.
- Fixed a bug in the cycle_delay code: all values below .001 were in fact treated as exactly 0.
I guess with these fixes, all positive values of cycle_delay can now be considered supported. cycle_delay=0 works, too, but when you do a real 180 on the spot, you're as good as dead, the topology police will kill you shortly after your next turn. cycle_delay values below a certain threshold ( about 10^-5 ) will do that to you occasionally, too.
The bug Iceman reported should be fixed now, too: by using the brake to adjust to the wall and then turning, he issued two commands on the same spot ( time was irrelevant here ).
I'll commit the changes to CVS and update CVS test server 1 at about 21h GMT ( 4 hours from now ). Client changes are not required
Edit: the fixes are in gCycle.h 1.5 and gCycle.cpp 1.13.


