 |
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
 Posted: Fri Jan 16, 2009 7:27 am
[3.03a] #NODIR incorrectly clearing more than current dir in the walk queue
|
Short Description:
In slow walk mode, under certain situations using #NODIR will clear more than the current direction when there are more than one pending movements in the walk queue.
Instructions to Reproduce the Bug:
| Code: |
1) I created a new session named Test.
2) Opened the map in the session and docked it to the right of the main window.
2a) Changed to Slow walk Mode
2b) Under Automatic Step Confirmation -> Disable automatic confirmation.
3) Created three rooms manually in the mapper, two rooms connected north/south to each other, and a room going to the east off the south room.
4) Created triggers for which I'll provide code for. Description below:
I created a command input triggers for n and s so that they would create an alarm that would send #ok 1 second after the movement was entered.
I also created a trigger for e that would create an alarm that would send #nodir 0.5 seconds after the movement was entered.
5) While in the south room I entered "e;n" into the command line.
6) east and north were entered into the walk queue and in 0.5 seconds, a #nodir was executed by the alarm. This execution of #nodir erroneously erased not only the current direction, but it also erased the next direction in the queue. Half a second after the #nodir executed, an #ok executed for the north direction. However, since the previous #nodir cleared out both directions, it had nothing to confirm and the map didn't update position to the north room.
|
Settings Code:
Import when needed for the instructions above.
| Code: |
<window name="Test">
<uid>{F90A7075-918F-4606-94D5-08C39585F136}</uid>
<packages>English Keypad|English Directions|Clickable URLs|Test</packages>
<loc name="Test" color="blue" id="2">
<value>1</value>
</loc>
<class name="Tester" id="3">
<trigger type="Command Input" priority="60" id="6">
<pattern>n</pattern>
<value>#alarm north +1 {#ok;#say OK north}</value>
</trigger>
<trigger type="Command Input" priority="70" id="7">
<pattern>e</pattern>
<value>#alarm east +0.5 {#nodir;#say NODIR east}</value>
</trigger>
<trigger type="Command Input" priority="80" id="8">
<pattern>s</pattern>
<value>#alarm south +1 {#ok;#say OK south}</value>
</trigger>
</class>
</window>
|
Other Observations:
If I were to guess, I'd say that when there are only two items in the walk queue and a #nodir is executed, it causes both remaining directions to be erased. I was able to do a bunch of north and south movements to build up a lot of items in the queue and when I had more than three or so in there I could do a #nodir and I'd see them be removed one by one just like #nodir is supposed to do. So I can only imagine it has something to do with how many things are in the queue.
Also, I noticed that when I entered 's' while in the north room, the #ok from the alarm would execute which caused my room to change, but it wouldn't take the direction out of the queue. I'd still see it in the bottom right hand corner of the mapper window. Additional #ok at the command line wouldn't remove it either. Only executing a #nodir seemed to clear it. While it was stuck in there, querying the autowalker system confirmed that it still thought it was in the middle of a speedwalk. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Wed Jan 21, 2009 8:12 pm
|
Has anyone been able to confirm this? This may fall under work for one of the mapper re-write phases, but I want to make sure that it is indeed addressed when this is eventually worked on.
This is a particularly bothersome bug for me. Whenever I accidentally hit the wrong direction then correct myself I have to resync the map because of it clearing both directions. I'd like to make sure it gets recorded and eventually fixed when the appropriate portion of the mapper is worked on. |
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Fri Jan 23, 2009 9:20 pm
|
Confirmed Odd Behavior
There's definitely some odd behavior going on here. I'm not so sure if it's a problem with the #NODIR as it is a problem with responding the #OK. As I understand it by typing 'e;n' you start off with two rooms in the queue and when the NODIR stops the east movement only one room is left. When 'n' get set the queue is now empty as it should be. I did notice that the #OK doesn't move the location to the north though.
Bottom line is that there is definitely something here for Zugg to look at. |
|
_________________
Asati di tempari! |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Jan 26, 2009 5:51 pm
|
Yeah, I'm not sure what is happening here either, but I've added this to the bug list. The next phase of the mapper rewrite is to deal with the mapper configuration and scripting, so this falls directly into that work. Hopefully I'll be able to track this down.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Mon Jan 26, 2009 6:04 pm
|
Great, I'm glad you were able to reproduce it. Thanks for taking the time to look at this.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Oct 23, 2009 10:24 pm
|
Btw, to test this offline using the above instructions, you also need to open the Map Properties, go to the Configuration page, click the MUD Prompt tab and turn OFF the "Wait for prompt in SLOW speedwalking" option. Otherwise #OK doesn't finish confirming the step until the prompt is received.
The Help files says that doing "#OK 1" is supposed to do this, but that isn't working in CMUD (fixed in 3.11)
Still working on the #NODIR bug mentioned above though. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Oct 23, 2009 10:48 pm
|
OK, this issue turns out to be waaay to complicated to deal with for v3.11. I can see what is causing the problem: CMUD computes the "path" based upon the "e;n" directions and stores the *links* along that path in the queue. The #NODIR is properly removing the first link in the queue, but the rest of the links are not "recomputed" based upon the current map location.
For example, add another room to the North of the "East room". You'll see that your "e;n" command causes the map to end up in that room. That's because it was the link from the East room to the room to it's north that was still stored in the queue. CMUD needs to somehow recompute the entire map path in the queue based upon the current location after the #NODIR was issued.
However, doing this is very nontrivial. So I'm afraid it's not going to get changed in 3.11, and probably not in the first 3.x Public version. There is just too many side effects to consider that could break the mapper more than fixing it. |
|
|
|
|
rozdwojeniejazni
Wanderer
Joined: 13 Aug 2011
Posts: 74
|
Posted: Tue Jan 08, 2013 7:23 pm
|
The fact this bug will never be fixed makes me so sad. 
|
|
|
|
|
|
|
|
