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: Sun Sep 19, 2010 7:31 pm   

[3.27-3.29] [Fixed in 3.29a] Slow-walking/OnRoomEnter issues with GMCP
 
The way OnRoomEnter fires at the time the GMCP info arrives is messing up slow-walking. During some movements the map hasn't yet properly updated itself to the destination room when the OnRoomEnter fires. Not having updated to the new room I see %roomname and %roomexit information from the prior room, while at the same time I see the GMCP information from the new room. This mismatch in onRoomEnter causes many issues for me with the slow walker and my OnRoomEnter code. I use OnRoomEnter to check for correct roomname, exits, etc, and if the map hasn't updated yet I sometimes update the prior room's information instead of the new room's information.

Prior to GMCP, I would execute an #ok when I confirmed I had changed rooms, then #prompt when the prompt was received. At the prompt the OnRoomEnter event would fire. This change with GMCP has been causing a lot of issues for me.


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


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

PostPosted: Mon Sep 20, 2010 5:21 pm   
 
This is the correct operation of GMCP. The purpose of GMCP is to enable mapping and scripting without any other data from the MUD. So CMUD is never going to wait for a "prompt" or perform any other tests when using GMCP. It is going to fire the OnRoomEnter as soon as it receives the GMCP data for the room.

You can either turn off GMCP or rewrite your OnRoomEnter events as GMCP triggers instead. With GMCP you shouldn't need to check for correct roomnames or exits since that data is provided directly via GMCP.

Basically, if you are going to try and override the mapper and do your own triggers, then you should turn off GMCP. GMCP is intended for the majority of players who don't want to rescript the mapper themselves and just want it to work based upon the data sent by the MUD.
Reply with quote
ReedN
Wizard


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

PostPosted: Mon Sep 20, 2010 5:38 pm   
 
Zugg, you've misunderstood what I was trying to use this for.

If I had a perfect map with all the correct vnums and all the names were correct then I wouldn't bother with any of this. What I do have is a map that I've spend over 5 years creating. In that time they've changed zone names, changed room names, changed environment types, changed room types and moved things around. On top of that they are now providing vnums, which they didn't have in the past.

What I'm trying to do is to utilize the GMCP information to update my map. The alternative is to start from scratch, and that still wouldn't help me in the case where I re-map everything from scratch and then they change things after I map it.

I need the ability to compare the GMCP information sent with the information stored in my personal map. When that information differs it means that the Mud has altered their map and that I now need to update the correct information into my map. Are you saying I should start from scratch everytime they alter their map? All I'm trying to do is provide a mechanism to update my map with the information they send.

What is happening is that when the OnRoomEnter event is raised the mapper sometimes still thinks I'm in the old room. However the GMCP information is from the new room. It is a bug to call raise the OnRoomEnter event if the mapper hasn't finished placing itself into the new room. If the mapper still has the old room's information and calls OnRoomEnter it is in error. That is the issue that should be fixed.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 5:46 pm   
 
Quote:
I need the ability to compare the GMCP information sent with the information stored in my personal map.

I understand that. As I said, you need to create a GMCP trigger on Room.Info to do this. CMUD runs your GMCP trigger after the mapper has moved to the correct room (or created the new room) using the GMCP data. Then you can simply use the various %roomXXX functions to update your room based upon the data given in the %gmcp variable.

Let CMUD handle the setting of the proper vNum values. It will already do that internally. Then you can just do stuff like:
Code:
#CALL %roomname(, %gmcp.room.info.name)

to set the name of the room to the data sent from the MUD via GMCP.

The OnRoomEnter event in CMUD is raised in the "MoveToRoom" method, so I don't really understand what you are saying about this. Are you saying that the GMCP data is not available for the correct room in the OnRoomEnter event? Since the MoveToRoom is called from the routine that just processed the GMCP data, I'm not sure how that is possible. But I guess I'd need a more concrete example of what you are doing in your OnRoomEnter event.
Reply with quote
ReedN
Wizard


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

PostPosted: Mon Sep 20, 2010 6:38 pm   
 
Here's an example:

Settings: Slow walk mode, Disable automatic confirmation, Delay between sending lines 320, GMCP enabled (Achaea), Vnum correct flag set in all rooms used.

Code:
<event event="onRoomEnter" priority="60670" id="6163">
  <value>#say
#say "GMCP    :" %gmcp.Room.Info.name
#say "roomname:" %roomname</value>
</event>


So, according to what you said, there is no possible way I can get the GMCP and %roomname to mismatch in my onRoomEnter code, right?

I entered on the command line: n;n
Code:
Outside the Delosian Guard Quarters.
Some graffiti has been scrawled here. It reads, "Guard Quarters [N], Property Office [S]."
You see exits leading north, east, south (open door), and west.
8943h, 8639m, 40546e, 35600w exdb-n
n

GMCP    : Entryway to the Delosian guard quarters
roomname: Southwestern courtyard
Entryway to the Delosian guard quarters.

GMCP    : Entryway to the Delosian guard quarters
roomname: Entryway to the Delosian guard quarters
You see exits leading north and south.
8943h, 8639m, 40544e, 35600w exdb-
GMCP    : Southwestern courtyard
roomname: Southwestern courtyard
Southwestern courtyard.
You see exits leading north, northeast, east, and south.
8943h, 8639m, 40542e, 35600w exdb-


I've only moved twice, yet CMud has raised the OnRoomEnter event 3 times. The first call it is clearly mismatched, the second two times it is matched. So my guess is that there is a bug in the code that handles the case where there is multiple movement commands executed at the same time.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 6:47 pm   
 
OK, thanks for the good example. Definitely looks like OnRoomEnter is being called from somewhere else that it shouldn't be.

Not to hard to imagine given the complexity of the mapper. People need to remember that the mapper has three speedwalk modes (Fast,Safe,Slow) and two mapper modes (Map,Follow) and four different ways of speedwalking (double-click map, .nws path, #SLOW command, keypad directions). That is 3*2*4=24 different combinations. Each combination is a bit different in how it gets handled and it's hard to test every possible combination sometimes (as much as I try).

That is why it is so important to get specific step-by-step instructions like ReedN gave above and to say exactly what speedwalk mode you are using and how you are walking around.
Reply with quote
ReedN
Wizard


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

PostPosted: Mon Sep 20, 2010 6:59 pm   
 
You gave me an idea. It would be a nice to have feature to be able to dump out to a compact text list all the settings the user has. That way when people post they can run the command to spit out all their settings and include that with their post. It seems like 90% of the posts get followed up with "I need more information on your settings". If they included this output it would be able to contain all the items that are important but might have been overlooked by the person posting and attempting to give all the relevant information. Anyway, something to think about for later.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 7:01 pm   
 
XML output of the settings is something I've already got on my to-do list for the future. Wasn't high enough priority to get it into this public version.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 8:08 pm   
 
I should also warn people who are thinking of doing something like ReedN is doing that it will only potentially work if you are NOT in Fast speedwalk mode.

Always keep in mind that when sending multiple directions or speedwalking in Fast mode, the CMUD mapper location is immediately set to the END of the speedwalk path. If you try to use a GMCP trigger in Fast mode, it will fail in this case because you'll be setting the properties of the ending room of the speedwalk rather than the rooms along the way.

So only manually update room data via GMCP when in Safe or Slow mode.
Reply with quote
ReedN
Wizard


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

PostPosted: Tue Sep 21, 2010 5:43 am   
 
I wasn't sure if the below item in the change log refers to this bug:

- Fixed problem not setting correct current room when fast walking

But I confirmed I can still cause this mismatch in 3.28 with the above procedure.
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Sep 21, 2010 5:10 pm   
 
I cannot reproduce this. I created your onRoomEnter event and turned on the various settings that you mentioned and went into SlowWalk mode. In both Follow mode and in Map mode I get properly matching room names and GMCP data using v3.28. Tried this on both Achaea and Aardwolf and didn't get any problems with mismatching.

Make sure you are really in Slow mode and not Fast mode. Fast mode is the only mode that has this mismatching.
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Sep 21, 2010 5:14 pm   
 
Actually, in Map mode I do see a problem. You cannot use n;n when in Slow mode and in Map mode. Using n;n is essentially doing a Fast Walk when in Slow mode. When in Slow mode you need to use the #SLOW command, like "#SLOW .2n" for Map mode to work properly.

You can use n;n in Safe mode and then it works in Map mode. That is why I normally recommend Safe mode as the default setting for people. Slow mode was really designed to with with the #SLOW command. The problem with using n;n is that you are bypassing the ability for CMUD to create a speedwalk path, whereas #SLOW .2n allows CMUD to place the path in the queue and manage each step one by one.
Reply with quote
ReedN
Wizard


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

PostPosted: Tue Sep 21, 2010 5:59 pm   
 
Now I'm a little confused. The reason why I use SLOW walk mode is that there are tons of things that can prevent a movement from being successful on Achaea. I assumed that since there was great potential for a movement to not succeed I'd need to use SLOW mode to confirm that each step was taken. Would SAFE mode provide the same protection that SLOW was offering? In what ways do you consider it a more appropriate mode for the majority of users to use? Will I still be able to update my own map with GMCP information myself?

The reason why I was testing n;n was because I had noticed this effect happening when I entered movement commands too rapidly at the keypad. In order to replicate this issue in a repeatable manner I had to use something that would approximate entering directions quickly at the keypad. Telling people to punch in directions quickly at the keypad seemed a poor way of getting repeatability.

So are you in effect saying that you can't move around too quickly using the keypad when you are in slow mode? I've never had an issue with this in the past. I guess I still don't understand the underlying mechanics that are causing this issue.
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Sep 21, 2010 7:17 pm   
 
Quote:
So are you in effect saying that you can't move around too quickly using the keypad when you are in slow mode?

No, only in Map mode. In Follow mode it is fine. As I said above, I could not reproduce any problem with Slow walk in Follow mode in v3.28. It's only in Map mode that you need to take it slow and one step at a time.
Quote:
The reason why I use SLOW walk mode is that there are tons of things that can prevent a movement from being successful on Achaea.

That is true. But that is also the beauty of GMCP. In Safe mode the mapper stays in synch with the data sent by the MUD. For example, I can send a huge speedwalk command with no send delay. Obviously Achaea will stop in the middle of this and complain that I'm walking too fast. All I need to do is "look" and the mapper automatically syncs my proper map location. This is great on muds where you need to "flee" and the mud randomly chooses an exit. Just do a "look" and the mapper will sync with the vNum sent via GMCP.

Safe mode still confirms each step along a path. Without GMCP it would confirm using a trigger to match the room name. With GMCP Safe mode uses the vNum sent by the MUD to confirm with the mapper. The difference between Safe and Slow mode is that Safe mode still sends all of the directions to the MUD at the beginning, whereas Slow mode sends each direction in the path only after the previous step was confirmed.

By using n;n or by sending direction commands really quickly, you are essentially treating Slow walking as Safe mode...you are sending all of the movement commands "up front" instead of waiting for each step to be confirmed.

You can definitely still update your own map with GMCP information yourself in Safe mode. You set up a GMCP Room.Info trigger and use the %room functions to set the information.
Reply with quote
ReedN
Wizard


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

PostPosted: Tue Sep 21, 2010 7:38 pm   
 
From your description, it still seems like SLOW mode is the most appropriate for Achaea. Achaea only allows 2-3 movement commands per second so it's going to end up taking you more time if you give it 20 all at once and then have to keep re-syncing and starting over. You may take your first couple of steps faster in SAFE mode, but overall it will take you more time as you have to continually restart. If I send 20 movement commands all at once the first 2 or 3 would succeed then I'd see a bunch of failures with the added negative effect that it would take up bandwidth and compute time to handle all the failures and text flying back from the server. However this isn't the most dangerous part about sending too many commands at once as it will most likely take incorrect movements.

Take this example: n e n s w e w

Say the first 3 commands go through: n e n

The next 2 fail, not because they are incorrect directions, but because you exceed the movement allotment: s w

What is going to happen when the final two arrive and are accepted?: e w

The best case scenario is that e and w are *not* valid directions where you got stopped. If they are invalid directions it simply gives you an error message. But what happens if e and then w are valid directions. It stopped accepting movement commands and blocked out the right directions, now it starts accepting directions and suddenly starts moving you in a completely wrong direction. This isn't theoretical, I've seen this happen when commands arrive at the server in varying amounts of time. Suddenly a bunch of movements all sent at once can have a movement in the middle rejected as the limit is hit and then subsequent are accepted because enough time has passed.

Although perhaps I'm missing a central point you were trying to make. Perhaps SAFE could be useful for a very short path, but it's worthless if I need to travel a moderate to long path.
Reply with quote
ReedN
Wizard


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

PostPosted: Tue Sep 21, 2010 7:41 pm   
 
Zugg wrote:
I cannot reproduce this.


I'll try to reproduce this in a clean session.
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Sep 21, 2010 10:16 pm   
 
Quote:
From your description, it still seems like SLOW mode is the most appropriate for Achaea

Yes, that might be true. Their limit on speedwalking is actually the reason I don't actually play IRE MUDs myself. All I do is some basic testing in an isolated test area on Achaea. I do my *play* testing on Aardwolf where I can speedwalk properly.

But let me know if you can reproduce this in a clean session since your test is certainly something I can do in my Achaea test area and it shouldn't be any different.
Reply with quote
ReedN
Wizard


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

PostPosted: Tue Sep 21, 2010 11:49 pm   
 
I too find the movement limit annoying, but manageable.

I find it interesting that this one item is a deal breaker for you.
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Sep 22, 2010 1:05 am   
 
Well, it's not like I have much time for MUDding these days anyway. But when I do, I just want to play and not be bothered by a lot of "rules" and restrictions. I know that other people prefer the depth and combat details. I just want to kill stuff sometimes :)
Reply with quote
ReedN
Wizard


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

PostPosted: Thu Sep 23, 2010 5:55 am   Procedure for Reproducing in Clean Session
 
1) Create a New session, enter off-line
2) Paste in the directions overrides XML:
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 in the xml for the onRoomEnter Event:
Code:
<class name="event" id="24">
  <event event="onRoomEnter" priority="250" id="25">
    <value>#say
#say "GMCP:" %gmcp.Room.Info.name
#say "Map :" %roomname</value>
  </event>
</class>

4) Paste in the xml for the gmcp trigger:
Code:
<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)) {
  #say issuing OK
  #ok
  } </value>
</trigger>

5) Configure the mapper:
Slow Mode
Disable automatic confirmation
*Disable* Use vNum (Uncheck this item, Important!!!)
6) Map several rooms including a portion that has a stretch of several rooms.
7) Change to follow mode.
8) Type: n;n or an equivalent direction:
Results:

Code:
1808h, 1414m, 7066e, 4895w ex-n
n
issuing OK

GMCP: Nearing the Seaside Markets
Map : Fresh fish Market
Nearing the Seaside Markets.
A runic totem is planted solidly in the ground. A sigil in the shape of a small, rectangular monolith is on the ground.
You see exits leading north, northeast, and south.
1808h, 1414m, 7068e, 4895w ex-
Fresh fish Market.
A runic totem is planted solidly in the ground. An iron-tipped whip has been carelessly tossed away here. A sigil in the shape of a small, rectangular monolith is on the ground.
You see exits leading north, northeast, east, and south.
1808h, 1414m, 7066e, 4895w ex-
The radiant sun shines all about you.
1808h, 1414m, 7070e, 4895w ex-


Instead of having the gmcp trigger fire twice it only fires once. The one time it fires the GMCP information is for the first room, but the mapper is already reporting information from the second room. That one #ok was somehow used by Cmud to get it across two rooms.

Script Debugger:
Code:

0.0225 | a      test |1808h, 1414m, 7066e, 4895w ex-n
0.0034 | i      test >n<CR><LF>
0.0138 | a      test |n
0.0032 | i      test >n<CR><LF>
0.0761 | i      test *<ESC>[1;33mNearing the Seaside Markets<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>[1;35m A sigil in the shape of a small, rectangular monolith is on 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 north, northeast, and south.<ESC>[0;37m<CR><LF>
0.0001 | <IAC><SB><201>Room.Info { "num": 527, "name": "Nearing the Seaside Markets", "area": "Ashtan", "environment": "Urban", "coords": "49,-13,19,0", "map": "www.achaea.com/irex/maps/clientmap.php?map=49&building=0&level=0 2 11", "details": [ "" ], "exits": { "n": 528, "ne": 531, "s": 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.0023 | a      test #Telnet 201: Room.Info { "num": 527, "name": "Nearing the Seaside Markets", "area": "Ashtan", "environment": "Urban", "coords": "49,-13,19,0", "map": "www.achaea.com/irex/maps/clientmap.php?map=49&building=0&level=0 2 11", "details": [ "" ], "exits": { "n": 528, "ne": 531, "s": 526 } }
0.0024 | a      test |issuing OK
0.0803 | 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.0006 | a      test |
0.0004 | a      test |GMCP: Nearing the Seaside Markets
0.0029 | a      test |Map : Fresh fish Market
0.0030 | i      test *<ESC>[1;33mFresh fish Market<ESC>[0;37m<ESC>[1;33m.<CR><LF>
0.0000 | <ESC>[0;37m<ESC>[1;35mA runic totem is planted solidly in the ground.<ESC>[0;37m<ESC>[1;35m An iron-tipped whip has been carelessly tossed away here.<ESC>[0;37m<ESC>[1;35m A sigil in the shape of a small, rectangular monolith is on the ground.<ESC>[0;37m<ESC>[36m<CR><LF>
0.0000 | <ESC>[37m<ESC>[1;31mYou see exits leading<ESC>[0;37m<ESC>[1;31m north, northeast, east, and south.<ESC>[0;37m<CR><LF>
0.0000 | <IAC><SB><201>Room.Info { "num": 528, "name": "Fresh fish Market", "area": "Ashtan", "environment": "Urban", "coords": "49,-13,20,0", "map": "www.achaea.com/irex/maps/clientmap.php?map=49&building=0&level=0 2 10", "details": [ "" ], "exits": { "n": 529, "ne": 530, "e": 531, "s": 527 } }<IAC><SE><IAC><SB><201>Char.Vitals { "hp": "1808", "maxhp": "1634", "mp": "1414", "maxmp": "1318", "ep": "7066", "maxep": "7070", "wp": "4895", "maxwp": "4895", "nl": "85", "string": "H:1808/1634 M:1414/1318 E:7066/7070 W:4895/4895 NL:85/100 " }<IAC><SE><ESC>[32m1808h, <ESC>[37m<ESC>[32m1414m, <ESC>[37m<ESC>[32m7066e, <ESC>[37m<ESC>[32m4895w <ESC>[37mex-<IAC><EOR>
0.0010 | a      test #Telnet 201: Room.Info { "num": 528, "name": "Fresh fish Market", "area": "Ashtan", "environment": "Urban", "coords": "49,-13,20,0", "map": "www.achaea.com/irex/maps/clientmap.php?map=49&building=0&level=0 2 10", "details": [ "" ], "exits": { "n": 529, "ne": 530, "e": 531, "s": 527 } }
0.0009 | a      test #Telnet 201: Char.Vitals { "hp": "1808", "maxhp": "1634", "mp": "1414", "maxmp": "1318", "ep": "7066", "maxep": "7070", "wp": "4895", "maxwp": "4895", "nl": "85", "string": "H:1808/1634 M:1414/1318 E:7066/7070 W:4895/4895 NL:85/100 " }
0.0006 | a      test |Nearing the Seaside Markets.
0.0038 | a      test |A runic totem is planted solidly in the ground. A sigil in the shape of a small, rectangular monolith is on the ground.
0.0005 | a      test |You see exits leading north, northeast, and south.
0.0004 | a      test ]1808h, 1414m, 7068e, 4895w ex-
0.0032 | a      test |1808h, 1414m, 7068e, 4895w ex-
0.0004 | a      test |Fresh fish Market.
0.0005 | a      test |A runic totem is planted solidly in the ground. An iron-tipped whip has been carelessly tossed away here. A sigil in the shape of a small, rectangular monolith is on the ground.
0.0040 | a      test |You see exits leading north, northeast, east, and south.
0.0004 | a      test ]1808h, 1414m, 7066e, 4895w ex-
0.0000 |
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Sep 23, 2010 4:35 pm   
 
Hmm. Your GMCP trigger actually *is* being called twice. But it doesn't display the "issuing OK" for the second trigger because your test for %walkactive is returning false. So I think the bug is actually in %walkactive, but you are correct that I don't know why it is moving 2 rooms instead of just one.

But I confirmed the problem and have added it to the bug list. Thanks for the clear procedure.
Reply with quote
ReedN
Wizard


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

PostPosted: Fri Sep 24, 2010 12:34 am   
 
This is fixed in 3.29a.

However, onRoomEnter is now not firing, but I'll post separately about that since this issue is fixed.
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