Zugg Software :: View topic - [3.13+]Mapper room creation with duplicate RoomNum

Beginner Joined: 17 Jan 2008 Posts: 10

I am not sure if this is a bug, user error, or a result of wrong expectations on my part.

From the 3.13 release notes:
"Mapper will now use the vNum (RoomNum) when trying to match rooms during map creation"

When I read this I think the following should happen:

Starting from a blank map
1. Create new room #1
2. Exit room via non-standard exit using >in
3. Mud sends RNum #2
4. Mapper searches database and does not find a match for RNum #2
5. New room #2 is created with a link back to room #1
6. Exit room #2 via non-standard exit using >out
7. Mud sends RNum #1
8. Mapper searches database and finds an entry for RNum #1
9. Mapper does not create a new room
10. Mapper creates a link from #2 to #1

Instead in this situation, after step 7 I get a third room created that is also marked with its RNum being 1. There is a link created between this new third room and room #2. I now have two rooms in the database marked as having the RoomNum 1.

I have been trying to play around with the #NOMAP command to see if I can stop the mapper from creating the bogus room after I do my own database search but so far I have not gotten it to work. I suspect that the new room is created before my trigger on the roomname fires thus my #NOMAP is being ignored.

So my general question is how can I get the mapper to never create a second room with the same RNum as an existing room in the database, instead it should just correctly set up a link to it or update its position as appropriate.

Posted: Fri Feb 12, 2010 5:06 am

Your understanding is correct in how it *should* be working. The MUD needs to either support the MXP RoomNum tag, or you need to #TAG the room number yourself somehow. So the problem could be with a number of different areas. We would need to see the exact raw data dump from the MUD, so try turning on the Script Debugger and enable the Raw Input/Output message and post the data sent by the MUD. You shouldn't need to use any #NOMAP command, and that might also be messing things up.

Beginner Joined: 17 Jan 2008 Posts: 10

I submitted a support ticket with the detailed output from the debugger. The RoomNum is clearly being sent and seen by CMUD. I have attached a screen shot that shows the state of the mapper and the spreadsheet view showing the duplicate entries.

Only the default packages were enabled for this. The obj ids do not start at 0 because I deleted a few extra rooms to avoid clutter. The map was setup via the default reconfigure settings. No other options were changed. MXP is enabled as is ATCP.

I think the issue is with the non-standard exits, but I have not tested the regular exit handling extensively.

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

In your mapper window, at the bottom right there is an area that says Dir: <none>

What does it say after you create a room using the >in>n syntax?

Posted: Fri Feb 12, 2010 4:56 pm

In your debugger output, you forgot to turn on the Raw Input/Output message (it's the (i) entry in the Messages menu of the script debugger window).

I think you are right about this being an issue with the non-standard exits. The code for non-standard exits is a bit different than normal exits. I won't be able to look at this until after the public release next month unless it also effects normal exits, so let me know.

Posted: Sat Feb 13, 2010 5:00 am

It's lower priority because it just deals with non-standard exits? Lots of people would be affected by that, no?

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

I don't see it as a priority issue, but as Zugg has stated that the mapper isn't the focus for the next public release, it technically isn't a priority.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Not quite, ReedN. The old way probably still works:

1)>in>n leading to >out>s

The new way would allow you to do odder pairs without hand-editing, or perhaps even forego the explicit direction entirely:

1)>in>n> leading >out>e
2)>in leading to >out
3)>in>n leading to >out (the south would be assumed here)

If you don't specify a direction at all (#2), I'm not sure what logic the mapper is using for room placement. However, it seems to me that lack of an explicit return direction (#3) seems to travel the same direction of the original room placement. If my understanding of the new code is correct, then obviously that's a bug but that still doesn't rule out #1 or even the hand-editing made available by the Room Properties window (however inconvenient that would be.)