Zugg Software :: View topic - [3.28-3.29] [Fixed] Speedwalking issue in SLOW mode doing my own confirmations

Posted: Wed Sep 22, 2010 3:04 pm

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:

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

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

Apprentice Joined: 15 Jun 2010 Posts: 121

Wizard Joined: 17 Jun 2006 Posts: 1201

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.

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

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

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

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

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

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

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

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

Posted: Fri Sep 24, 2010 12:32 am

Confirmed fixed in 3.29a.