Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Wed Sep 22, 2010 3:04 pm   

[3.28-3.29] [Fixed] Speedwalking issue in SLOW mode doing my own confirmations
 
I think I may have located one of my intermittent bugs that has been an issue since GMCP for me.

Configuration: SLOW mode, FOLLOW mode, Disable Automatic Confirmation, my confirmation (#OK) occurring in the GMCP trigger.

The issue was that around about every 1 in 10 movements the mapper would send a movement twice causing my speedwalking to come to a halt as I'd run into a wall.

To debug this I took a look at when the mapper was sending the movement commands. I found that the mapper was normally sending movements after my prompt. The issue came up when an extra movement was sent directly after the reception of the GMCP event.

Here's an example. Normally I receive the prompt then the mapper sends a direction. What causes the error is the extra movement in this statement "-gmcp A road through the hills-w" when it sends a direction directly after receiving the GMCP data. Notice all the other movements occurred after the prompt:
Code:
-gmcp A road through the hills-
A road through the hills (road).
A large pelican rests on the sand, preening its feathers.
You see exits leading northeast and west.
8943h, 8639m, 38888e, 35600w exdb--prompt-w
-gmcp A road through the hills-
A road through the hills (road).
You see exits leading east and west.
8943h, 8639m, 38886e, 35600w exdb--prompt-w
-gmcp A road through the hills-w
A road through the hills (road).
You see exits leading east and west.
8943h, 8639m, 38884e, 35600w exdb--prompt--gmcp A road through the hills-
A road through the hills (road).
You see exits leading east and west.
8943h, 8639m, 38882e, 35600w exdb--prompt-w
-gmcp A road through the hills-
A road through the hills (road).
You see exits leading east and northwest.
8943h, 8639m, 38898e, 35600w exdb--prompt-w
There is no exit in that direction.
8943h, 8639m, 38898e, 35600w exdb--prompt-Slow walking aborted


I theorized that my #OK statement in the GMCP trigger could be causing the issue, and indeed, when I remove my personal #OK the issue completely disappears. However, I was using that #OK to confirm the rooms that don't have the vNum flag checked.

So this seems to be an issue where there is a conflict between the #OK statement I have setup to handle non-vNum flag checked rooms and the normal room confirmation you have setup for vNum flag checked rooms. Since I have "Disable Automatic Confirmation" selected, I need to do my own #OK statements. However, when the room has the vNum flag checked my #OK is interfering with CMud's confirmation system. Interestingly, I would have expected a conflict like this to occur on each movement, but surprisingly it only manifests itself about once every 10 movements.

Do you see a way in which I can execute the #OK only when the vNum flag isn't set? If I test for it in the GMCP trigger I don't think the mapper has updated to the new room yet, so I can't check the vNum flag. I think I might have to pre-check the flag based on where I expect to be or somesuch or perhaps only execute my #OK in the prompt... yet that may have the same issue as before where a double #OK is being issued and that causes the mapper to fire extra commands.

There needs to be some way for me to determine when the mapper has already issued a #OK so I can suppress mine, or CMud need to do a better job at ignoring my #OK when it already has seen one. Or perhaps the issue was that it was ignoring the majority of them, but once in a while the ordering was jumbled and it appeared to be the confirmation it was waiting for.

Anyway, hopefully that described the issue sufficiently. This could easily be the reason why I'm seeing the other mapper mismatch issue with an extra OnRoomEnter event and a mismatch in the map and GMCP info when that occurs.


Last edited by ReedN on Fri Sep 24, 2010 12:33 am; edited 4 times in total
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Sep 22, 2010 4:47 pm   
 
You can check if the vNum flag is set via the %roomload function. I think bit #4 is the vNum loaded flag.

One thing I could do is to prevent CMUD from issuing it's own #OK for rooms with vNum set if you have Disable Automatic Confirmation turned on. Right now CMUD will *always* confirm a step when it receives the GMCP data for the correct room. I can see that this can get in the way when you are doing your own confirmations.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Wed Sep 22, 2010 5:01 pm   
 
I think preventing CMUD from issuing it's own #OK for rooms with vNum set if I have 'Disable Automatic Confirmation' turned on would be great and probably the simplest solution from my perspective.

The issue I wasn't sure about was whether the mapper has changed to the new room when the GMCP prompt-type trigger runs. The room change in the mapper should be caused by the reception of the GMCP data, but if my trigger is marked prompt-type does that cause it to run before the room change occurs or does it update the room on the mapper then run my code for the trigger. In one case I'd simply look up the flags of the current room, in the other case I'd need to lookup flags from the room I'm heading into. So clearly this would be a lot simpler for me if CMUD just didn't produce any #OK confirmations of its own and let me do it in all cases.

In any case I think not automatically confirming the room via the vNum is perfectly in line with the ostensible meaning of the setting, "Disable Automatic Confirmation".
Reply with quote
dbosst
Apprentice


Joined: 15 Jun 2010
Posts: 121

PostPosted: Wed Sep 22, 2010 6:24 pm   
 
Zugg wrote:
You can check if the vNum flag is set via the %roomload function. I think bit #4 is the vNum loaded flag.

One thing I could do is to prevent CMUD from issuing it's own #OK for rooms with vNum set if you have Disable Automatic Confirmation turned on. Right now CMUD will *always* confirm a step when it receives the GMCP data for the correct room. I can see that this can get in the way when you are doing your own confirmations.


Ah please do this.. this would make it a lot easier for me too...
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Wed Sep 22, 2010 8:42 pm   
 
I'm not sure why you are having so much trouble. I'm not really having any trouble at all. I think maybe you are trying to do too much manually when the mapper now handles it. I'm mapping and updating my maps on the same exact mud and have little to no issues with the GMCP. In fact I am finding it pretty darn nice. For instance if I have two different zones and I never noticed an exit when I originally mapped the area and that exit goes to a room in another zone, it has no problem at all connecting them and moving me to the other zone and room. Before it would just create a new room in the same zone or something and I always had issues. This is why I tried to make my entire map originally work off the actual room numbers. Now with GMCP the map does this automatically and there is no way you can get lost because the room number isn't ever going to change, while the names, descriptions, and exits might. I was actually following someone around and they used a portal and the map moved me to the room we ended up in. I don't even have any triggers for that sort of stuff. I was in follow mode at the time.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Wed Sep 22, 2010 8:49 pm   
 
Just walking around it seems to work fine. It was only having difficulty in about 1/10 speedwalk movements, but from my analysis of what's going on the cause is very clear. There's a double confirmation (#ok) that's at the heart of it.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Sep 22, 2010 9:50 pm   
 
Yep, it's related to the other post on the forum about this. If the GMCP data gets sent in a different network packet from the initial Room Name/Description, then CMUD is sending an extra #OK. I hopefully have this fixed for the next update, but I'll have to wait till you can test it to be sure.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Sep 23, 2010 2:28 am   
 
The changelog for 3.29 mentioned this as fixed, but I still see the confirmation being generated by Cmud in SLOW mode with 'Disable Automatic Confirmation' turned on.

I see it functioning no different than in 3.28. I even commented my #OK statement and was able to walk around in the vNum rooms. Arriving at non-vNum rooms the mapper wouldn't move because I had no #OK statements to confirm the movement. So CMud is still confirming for some reason.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Sep 23, 2010 2:36 am   
 
I think I found it.

I had to also uncheck "Use vNum to match rooms". Should I have just unchecked that in the first place to solve this? It uses the internal #OK unless that is unchecked.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Sep 23, 2010 3:25 am   
 
No, I'm confused. CMUD specifically checks the Auto confirmation before calling the ConfirmStep routine (which is what #OK calls). So ConfirmStep is *not* being called when Auto confirmation is off.

Turning off "Use vNum" just turns off most all of the vNUM/GMCP checking, so yes, that will work but that's not really what we were trying to do here. Turning that off will lose almost all of the benefits of GMCP.

I'm going to need to see the full debugger dump including the GMCP messages to help more with this. And at this point, I'm not even sure if I'm going to be able to get this working for you. The mapper is just too complicated and every change I try to make to fix this issue for you just ends up screwing up something else. So you'll need to come up with a simple procedure for me to use to test and reproduce this. I can't just keep guessing at what might be causing it.

Also, as I said in the release notes, you need to examine the rooms along your path and make absolutely sure their vNums are set properly if they have the Real vNum flag enabled.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Sep 23, 2010 4:51 am   
 
Well it works how I want it with "Use vNum" off. I'm already doing all the checking and updates myself so I'm not missing out on anything I want to happen with the vNums. So things are stable now for the release from my perspective.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Sep 23, 2010 5:33 am   
 
Well, it put a bug in my bed that this wasn't working the way you had thought, so I replicated this on a clean setup. Although I know you are tying to get the new version out, so feel free to delay looking at this until you have time.

Steps:
1) Create a new session.
2) Paste this xml directions overrides in your new session:

Code:
<class name="Directions" id="6">
  <dir name="n" reverse="s" dir="n" id="7">n|north|swim n|leap n|tumble n|burrow n|gallop n|mountjump n</dir>
  <dir name="s" reverse="n" dir="s" id="8">s|south|swim s|leap s|tumble s|burrow s|gallop s|mountjump s</dir>
  <dir name="e" reverse="w" dir="e" id="9">e|east|swim e|leap e|tumble e|burrow e|gallop e|mountjump e</dir>
  <dir name="w" reverse="e" dir="w" id="10">w|west|swim w|leap w|tumble w|burrow w|gallop w|mountjump w</dir>
  <dir name="k" reverse="j" dir="sw" id="11">sw|southwest|swim sw|leap sw|tumble sw|burrow sw|gallop sw|mountjump sw</dir>
  <dir name="j" reverse="k" dir="ne" id="12">ne|northeast|swim ne|leap ne|tumble ne|burrow ne|gallop ne|mountjump ne</dir>
  <dir name="h" reverse="l" dir="nw" id="13">nw|northwest|swim nw|leap nw|tumble nw|burrow nw|gallop nw|mountjump nw</dir>
  <dir name="l" reverse="h" dir="se" id="14">se|southeast|swim se|leap se|tumble se|burrow se|gallop se|mountjump se</dir>
  <dir name="i" reverse="o" dir="other" id="15">in|swim in|leap in|tumble in|burrow in|gallop in|mountjump in</dir>
  <dir name="o" reverse="i" dir="other" id="16">out|swim out|leap out|tumble out|burrow out|gallop out|mountjump out</dir>
  <dir name="u" reverse="d" dir="u" id="17">u|up|swim u|leap u|tumble u|burrow u|gallop u|mountjump u</dir>
  <dir name="d" reverse="u" dir="d" id="18">d|down|swim d|leap d|tumble d|burrow d|gallop d|mountjump d</dir>
</class>


3) Paste this GMCP trigger in your session:

Code:
<class name="gmcp" id="4">
  <trigger type="GMCP" priority="60760" newline="false" prompt="true" id="5">
    <pattern>Room.Info</pattern>
    <value>#call %regex( %gmcp.Room.Info.name, "(?:Flying above |In the trees above )?(.+?)(?: \(road\))?$", $RoomName)
%gmcp.Room.Info.name = $RoomName
#if (%iskey( %gmcp.Room.Info.exits, "i")) {
  #addkey %gmcp.Room.Info.exits "in" %db( %gmcp.Room.Info.exits, "i")
  #delkey %gmcp.Room.Info.exits "i"
  }
#if (%iskey( %gmcp.Room.Info.exits, "o")) {
  #addkey %gmcp.Room.Info.exits "out" %db( %gmcp.Room.Info.exits, "o")
  #delkey %gmcp.Room.Info.exits "o"
  }

#if (%if( %walkactive, 1, 0)) {
  //
  //#ok
  } </value>
  </trigger>
</class>


4) Mapper configuration:
Slow Mode
Disable automatic confirmation
Use vNum
5) Connect to Achaea.
6) Open the mapper and put it in map mode.
7) Map out about 5 or so rooms (enough for this test), this should work flawlessly.
8) Change to follow mode.
9) Walk around in follow mode. Note that since you disabled 'automatic confirmation' it shouldn't be able to be following you around. The #ok in the gmcp code should be commented out at this point, so Cmud is clearly generating its own #ok.
10) Unselect "Use vNum". Notice now that the map doesn't follow you anywhere, you are dead in the water. No #ok being generated.
11) Open the GMCP trigger and uncomment the #ok statement.
12) Make sure you are on the correct square on the map and start walking around. Notice the #ok statement is now allowing the map to follow you.

Full Debugger Dump (including the GMCP messages)
Code:
0.0243 | a      test |1808h, 1414m, 7066e, 4895w ex-se
0.0040 | i      test >se<CR><LF>
0.0889 | i      test *<ESC>[1;33mPine street approaching the docklands<ESC>[0;37m<ESC>[1;33m.<CR><LF>
0.0001 | <ESC>[0;37m<ESC>[1;35mA runic totem is planted solidly in the ground.<ESC>[0;37m<ESC>[36m<CR><LF>
0.0001 | <ESC>[37m<ESC>[1;31mYou see exits leading<ESC>[0;37m<ESC>[1;31m south and northwest.<ESC>[0;37m<CR><LF>
0.0001 | <IAC><SB><201>Room.Info { "num": 525, "name": "Pine street approaching the docklands", "area": "Ashtan", "environment": "Urban", "coords": "49,-12,17,0", "map": "www.achaea.com/irex/maps/clientmap.php?map=49&building=0&level=0 3 13", "details": [ "" ], "exits": { "s": 524, "nw": 526 } }<IAC><SE><IAC><SB><201>Char.Vitals { "hp": "1808", "maxhp": "1634", "mp": "1414", "maxmp": "1318", "ep": "7068", "maxep": "7070", "wp": "4895", "maxwp": "4895", "nl": "85", "string": "H:1808/1634 M:1414/1318 E:7068/7070 W:4895/4895 NL:85/100 " }<IAC><SE><ESC>[32m1808h, <ESC>[37m<ESC>[32m1414m, <ESC>[37m<ESC>[32m7068e, <ESC>[37m<ESC>[32m4895w <ESC>[37mex-<IAC><EOR>
0.0021 | a      test #Telnet 201: Room.Info { "num": 525, "name": "Pine street approaching the docklands", "area": "Ashtan", "environment": "Urban", "coords": "49,-12,17,0", "map": "www.achaea.com/irex/maps/clientmap.php?map=49&building=0&level=0 3 13", "details": [ "" ], "exits": { "s": 524, "nw": 526 } }
0.0568 | a      test #Telnet 201: Char.Vitals { "hp": "1808", "maxhp": "1634", "mp": "1414", "maxmp": "1318", "ep": "7068", "maxep": "7070", "wp": "4895", "maxwp": "4895", "nl": "85", "string": "H:1808/1634 M:1414/1318 E:7068/7070 W:4895/4895 NL:85/100 " }
0.0008 | a      test |Pine street approaching the docklands.
0.0004 | a      test |A runic totem is planted solidly in the ground.
0.0004 | a      test |You see exits leading south and northwest.
0.0003 | a      test ]1808h, 1414m, 7068e, 4895w ex-
0.0000 |


I think that's it. It's as simple and repeatable as I can get it.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Sep 23, 2010 4:27 pm   
 
Yes, that confirmed it, thanks. CMUD isn't actually issuing an #OK to confirm the walk, but it *is* forcing the mapper to sync with the vNum being sent via GMCP still. I'll see if I can fix this.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Fri Sep 24, 2010 12:32 am   
 
Confirmed fixed in 3.29a.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
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

© 2009 Zugg Software. Hosted by Wolfpaw.net