 |
robert
Wanderer
Joined: 25 Feb 2004
Posts: 98
|
 Posted: Thu Oct 28, 2010 1:01 am
CMUD Pro [3.31] Slow Walk Speed sometimes sends e | east
|
Hey,
I have seen this issue in the beta for a while, and now it is also in the release version. When I am walking around with the slow walk, sometimes it will send a direction like e | east, or s | south. It isn't the same room, and it can do the same exit fine just sending e, or s. I don't seem to have the same issue on fast walk. I am using CMUD Pro 3.31 as stated in the title.
Thanks!
Robert |
|
|
|
|
robert
Wanderer
Joined: 25 Feb 2004
Posts: 98
|
Posted: Sat Nov 13, 2010 4:17 pm
|
In addition, I went down a hall with 3 easts, #OKing each one. When I got to the end of it and #OK to go back west, it did "e |east |east". The next #OK did west though as needed. This is still occurring on 3.32.
|
|
|
|
|
robert
Wanderer
Joined: 25 Feb 2004
Posts: 98
|
Posted: Sat Dec 04, 2010 9:31 pm
|
I am still working on debugging this issue. One thing of note is at the end of a #WALK if I do %nextdir it still says there is another direction, usually garbage. If I #OK then nothing normally happens, but one of the times I got a s |south was when it sent the bogus %nextdir. I also notice if I print out the %nextdir right before I #OK it is not always the same direction as is sent. Normally the %nextdir is not the correct one. Anyone seeing anything like this?
|
|
|
|
|
robert
Wanderer
Joined: 25 Feb 2004
Posts: 98
|
Posted: Sun Dec 05, 2010 7:58 pm
|
I added the following to debug before and after the #OK:
| Code: |
#SA Before OK, nextdir %nextdir, destroom %destroom, inwalk %inwalk, walkconfirm %walkconfirm, walkroom %walkroom, roomnum %roomnum
#OK
#WAIT 10
#SA After OK, nextdir %nextdir, destroom %destroom, inwalk %inwalk, walkconfirm %walkconfirm, walkroom %walkroom, roomnum %roomnum
|
I didn't have the #WAIT at first, but then the #SA After had the same results as before. and would print before the direction was actual sent. This leads me to believe that the #OK is actually not inline which maybe the cause of some of my issues. I did some other map commands right after that #OK and I think sometimes that would corrupt the map walking state. It seems internally some of the mapper functions are inline while others are not and mixing them together can cause trouble. It would be nice to know which ones are not inline so I can put #WAITs or something after them.
After the #WAIT was added see results like this:
Before OK, nextdir w, destroom 13411, inwalk 1, walkconfirm 0, walkroom 13410, roomnum 13558
s
After OK, nextdir s, destroom 13411, inwalk 1, walkconfirm 0, walkroom 13410, roomnum 13410
The nextdir after the #OK equals what was sent only after the #OK which is strange to me, but the roomnum updating makes sense. walkroom seems to only get updated after the next #TAGs.
If the #OK is at the end of a #WALK I get the following:
Before OK, nextdir s, destroom 13411, inwalk 1, walkconfirm 0, walkroom , roomnum 13410
After OK, nextdir , destroom 13411, inwalk 0, walkconfirm 0, walkroom , roomnum 13411
Nextdir is cleared out after the #OK, but why did it have a value before the #OK if nothing was going to be sent. walkroom is properly blank imho. It seems the way to properly detect that a walk is ended is to check inwalk after a #OK was done and if the value is 0 then it didn't actually send anything with the last #OK and a new #WALK is required. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
