Zugg Software :: View topic - [3.27-3.29] [Fixed in 3.29a] Slow-walking/OnRoomEnter issues with GMCP

Posted: Sun Sep 19, 2010 7:31 pm

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.

Posted: 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.

Posted: 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.

Posted: Mon Sep 20, 2010 5:46 pm

Posted: 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.

Posted: 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.

Posted: 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.

Posted: 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.

Posted: 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.

Posted: 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.

Posted: 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.

Posted: 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.

Posted: 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.

Posted: Tue Sep 21, 2010 7:17 pm

Posted: 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.

Posted: Tue Sep 21, 2010 7:41 pm

Posted: Tue Sep 21, 2010 10:16 pm

Posted: 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.

Posted: 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 :)

Posted: Thu Sep 23, 2010 5:55 am

1) Create a New session, enter off-line
2) Paste in the directions overrides XML:

Posted: 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.

Posted: 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.