Zugg Software :: View topic

Posted: Sat Aug 28, 2010 6:47 pm

I'm having an awful time trying to use my current map with the %gmcp protocol. Whenever I try to walk around CMud only concerns itself with making sure the room number from my Mud matches with the room on my map. Consequently as I try to walk around it keep popping me from one map to another as it gets the room map numbers from the mud. One moment I'm on one side of the continent then I move a room and it pops me over to the other side of the continent. Cmud isn't taking into account room names, exits or anything else except for the room number. Since I didn't have access to room numbers when I created my map, all my room numbers are incorrect. I have over 20,000 rooms collected over years and years of playing, am I now supposed to start over if I want to be able to walk around normally without the mapper going crazy on me?

Prior to GMCP I used logic to intelligently decide what should be done, for example:

Apprentice Joined: 15 Jun 2010 Posts: 121

Zugg has said he will force people to use room numbers to key it with GMCP... I have a work around but its pretty convoluted and involves disabling GMCP completely and MXP tagging of vnum... I have my own scripts for manually interfacing with my MUD to say I want to use GMCP... this way you only have to unselect roomnum in MXP preferences... if you want the script I can post some of it but... I don't know if it will help you since it may only work with Achaea

See the bottom of this for Zuggs explanation why: http://forums.zuggsoft.com/forums/viewtopic.php?t=35470&highlight=

Wanderer Joined: 19 Jul 2008 Posts: 59

but how do you set the mapper up for the GMCP
do you have to turn off all tags and remove all my tag trigger
and do I have to use the mapper reconfigure.

cus I can get it to make any new rooms or find any old room
it can still follow me around if I use my keyboard to walk

I do like what I have read about GMCP but need more info

Posted: Sat Aug 28, 2010 9:15 pm

You'll need to turn off any #TAG for the Room Num if your room numbers are not unique across your map. By default, CMUD looks for a matching room num within your current zone. If no match is found, then it looks in other zones. So it works better if the Room Num is unique across zones.

Right now there isn't any way to turn this off, sorry. I was so focused on getting it working with GMCP that I neglected those cases of people using their own RoomNum tags or MXP. You'll have to wait for an update to add an option to disable the new room number testing.

But if you are using GMCP, then it *does* use the room num exclusively of the room name. That is how GMCP is supposed to work. If you want to rely on room names like the old mapper, then you'll need to remove the "room 1" module from the GMCP module listing. That will disable the GMCP mapper support.

The other workaround is to write a script to go through all of your rooms and set the vNum to zero and the TempvNum flag to true so that CMUD will fetch new room numbers as you move around the map.

Apprentice Joined: 15 Jun 2010 Posts: 121

Posted: Sun Aug 29, 2010 3:00 am

Apprentice Joined: 15 Jun 2010 Posts: 121

ReedN do you have any idea how to set the tempvnum flag to true? I looked everywhere for other documentation for %roomload but I don't see anything mentioning the reload of the vnum..

Posted: Sun Aug 29, 2010 3:05 am

About a year or so ago I used a perl script to go into the mapper database to renumber it from zero and order it into continuous blocks for the same zone. I'll start from this perl script and modify it for this purpose. I don't expect it to be too difficult to discover how to do it.

Apprentice Joined: 15 Jun 2010 Posts: 121

no no.. I have no trouble renumbering all the vnum entries.. I just have no idea about the tempvnum flag since its the first time I have heard of it and its not in any of the documentation I can find... I don't see anything under that name in the sql database either so I figured its part of the %roomload flags ... but I don't know what to put for it

Posted: Sun Aug 29, 2010 5:04 am

I took a look at the database and I'm a little confused as to what Zugg was talking about. Vnum (RefNum in the actual Database) is by default set to the database ObjId. This is exactly the reason why I was having so many problems with the new version of Cmud, the mud sends a room name and that number *always* exists, but it isn't the room that it should be, so it's constantly throwing me around my map. I don't see how anyone with an old map is going to be able to use GMCP by default. I'd like Cmud to grab the correct number and save it but I'm a little confused about the method Zugg outlined. Prior to this thread the only time I saw RefNum (Vnum) as 0 was on Object Orphans (my terminology) when I was cleaning out my database. Typically if I found an object that had RefNum set to 0 it was garbage and I deleted it. And I don't see any way of marking the RefNum as temporary.

Posted: Mon Aug 30, 2010 4:04 pm

I am working on a solution to this entire problem for an update later today.

I don't really want to add yet another "room num" field to the database. I want the MUD to use the vNum field because that is already integrated into all of the %room scripting functions and in the far future, everybody on a GMCP MUD should have a map that contains the correct vNum values from the MUD.

I'm going to add an internal flag to each room (similar to the tempvNum flag) that indicates whether the vNum was sent from the MUD or not. Then, when matching rooms via GMCP it will only match rooms that have this flag set. I'll provide a way to set/reset this flag. But this should prevent the mapping problems with existing maps that won't have this flag set. As you move around the MUD, CMUD will update the vNum of each room and set this flag. So over time it will be using more and more GMCP roomnum values for more accurate mapping.

Sorry I forgot to test *existing* maps with this new mapper code. I was so focused on getting GMCP working seamlessly for new players that I forgot about all of the existing maps out there.

Should be fixed later today.

Posted: Mon Aug 30, 2010 8:34 pm

Thanks for working on this.

With this change will Cmud update the room to the correct vnum once it receives the number from the Mud or will it be the player's job to manually update it?

I wouldn't mind Cmud automatically doing this behind the scenes as long as it did it intelligently by making sure the room name and exits match up before taking the vnum, otherwise it might be a disaster if I'm not actually in the room it thought I changed to. In that case I'd rather handle it myself than to possibly have it done incorrectly.

Apprentice Joined: 15 Jun 2010 Posts: 121

Posted: Mon Aug 30, 2010 10:12 pm

I think I mentioned above that "as you move around the MUD, CMUD will update the vNum of each room and set this flag".

CMUD doesn't need to look at the room name or exits. If you enable the new "Use VNum from MUD" option in the Mapper Config preferences and the MUD sends a vNum via GMCP, then that's the real vNum or your room. Yes, if you aren't in the correct room, this will overwrite the vNum in the room that you are in. But with this working properly, you should never be in the incorrect room.

If you want to deal with this yourself, you can always disable the new "Use VNum from MUD" config option. But you should really give it a try first before giving up on it since using the vNum from GMCP is the key to making your mapper completely foolproof with no other config or triggers needed.

Posted: Mon Aug 30, 2010 11:42 pm

I think there is a disconnect between what I was saying and what you were saying. It was never in doubt that I want to use the vNum from GMCP. The issue has always been the most optimal way to progress from not having it correct to having it perfect and never having to worry about it again.

The issue I see is that until I get the right vNums in there I'll be vulnerable to thinking I'm in one room when I'm actually in another. In that case the vNum will be applied to the wrong room. As there are numerous rooms in the mud I play that have identical names, I know that things are going to get inadvertantly scrambled. There are mazes which intentionally use the same room name and randomly place you around, so I wouldn't even have to try hard to encounter a circumstance when this would happen. For this reason I never simply look at the roomname alone to confirm I'm in a particular room. Sometimes it is necessary to look at exits to be sure, sometimes I need even more matching to make sure the room is correct. All I'm saying is that until the vNums are in there and correct, using only the roomname is very insufficient in many cases to make sure you are in the room you think you are.

Posted: Tue Aug 31, 2010 12:04 am

This probably won't help with mazes. In fact, I've heard rumors of turning off the RoomNum or other parts of GMCP when you are within a maze.

But I don't think the problem is as bad as you are expecting. Each room now has a "RealNum" flag that is set when the room number is loaded via GMCP. If the RealNum flag is not set, then CMUD uses the normal mapper methods to determine if the room is a match. Only after that happens does the vNum get set to the value sent via GMCP and then the RealNum flag is set.

If the room name/exits/etc don't match, then CMUD will create a new overlayed room, just like it already does when you get lost on your map. It won't overwrite the vNum of the room that doesn't match, nor will it jump you to any room. It's only when the RealNum flag gets set that the new vNum matching algorithm will kick in.

When moving around, CMUD looks at the vNum sent via GMCP and compares it to any rooms in your map that have a matching vNum AND have the RealNum flag set. If it finds that, then it teleports you to that matching room on the map. So it's only going to jump you to rooms that have already been verified to have the correct room num.