Zugg Software :: View topic

Beginner Joined: 22 Nov 2025 Posts: 14

As aardwolf sends out roomnumbers (gmcp.room.num) can anyone think of an elegant way to fix mud travel to the number?

I tried slow walking but, on some occasions, the walk is ending a room or two short. Safe walking has the opposite effect in that I will have sent the location forward a room or two and find that a cursor move in a direction is not possible as the path doesn't leads that way. A look will return the location to the correct room.

In reality, when an area has many rooms with the same name (and descriptions), verifying a walk with fixed room numbers seems the best choice.

Beginner Joined: 22 Nov 2025 Posts: 14

Also, my onZoneEntry event was not firing on every new zone. I had to make a GMCP trigger to fix it, making the onZoneEntry event redundant. If the onRooMEntry event misfires also, I shall have to make that a deader.

Posted: Mon Dec 22, 2025 12:06 pm

i believe the prebuilt events used enter, not entry, so that could just be a typo issue

Beginner Joined: 22 Nov 2025 Posts: 14

They do, my spelling of the actual event was not (is not) the problem.

Posted: Tue Dec 23, 2025 12:11 pm

I usually verify my room entry with the exits line:

#TR {Obvious exit{s|}:} {#OK}

#OK tells the mapper I have arrived. and it updates the dot if there are any movements queued.
(dont forget to include the outputs for when you are blinded or its too dark)
If its not recognizing your movement command, and you are being supplied the number anyway, you could just:

#TELEPORT number

Beginner Joined: 22 Nov 2025 Posts: 14

I am not sure half of the stuff works.

Most obvious is that if I am doing a speedwalk and get attacked on the way, the text "Not while you are fighting" shows for a failed movement. Multiply this by the remaining number of steps for the walk. So I made a trigger to #NODIR 1, expecting this to abort the walk and remove all steps but it does not and I still see a slew of "Not while you..." messages. Or, am I also missing something with this? Priorities maybe?

As for room thingy, I made a trigger for gmcp.room.info.num and compare that to current room var, if same ignore, if diff then #OK and current room = new room kind of thing.

Posted: Fri Jan 02, 2026 3:23 am

If that is a common issue, you should stick the mapper into slow mode, then it only tries to move one step at a time, and you will only get a single failure.
If you set up an #OKAY trigger as well, that also prompts for the next step in your path.
Oh, make sure to reconfigure the mapper, so it takes the new triggers into account for room recognition

Beginner Joined: 22 Nov 2025 Posts: 14

"make sure to reconfigure the mapper, so it takes the new triggers into account for room recognition" doesn't that come back to my original question?

To configure the mapper to actually use gmcp-provided room numbers and not its own (which does confuse the crap out me) is still a mystery.

It is a pain to try and remember which is which between vnum roomnum and roomkey. Especially when I am not actually certain that vnum in cmud is the same as vnum via gmcp.

Posted: Fri Jan 02, 2026 2:19 pm

You need to make #TAG triggers for those

those help to tell the mapper which bit is what. (including vnums)

You said you already had to make some GMCP triggers, those would hold the appropriate #TAG command as well

to reconfigure the mapper, there is an option under config on the map window, just follow the instructions on screen.

Beginner Joined: 22 Nov 2025 Posts: 14

I don't see any number tag option (like desc, exits, etc)

The vnum thing in configonly seems to specify using that instead of roomid when scripting not in the mapper.

Posted: Sun Jan 11, 2026 12:27 pm

vnum is one of the options there in #HELP #TAG
Rooms are typically numbered in creation order.
Both client side and server side.
Odds are you didnt map in the same order as the game admin created the areas.
This is where vnums come into play, so you can make your roomnumber match the games roomnumbers.
This is just so the game and the client are talking about the same spot.
The mapper is a major scripting tool in itself.

Beginner Joined: 22 Nov 2025 Posts: 14

I see (I assume) #TAG vnum but the documentation for %roomvnum states "Same as mapvnum. Convert current filter room number to a virtual room number. The absolute number for rooms ranges from 1 to %numrooms. All of the other room functions require a virtual room number or id, rather than the filter number. " which is for map queries, isn't it?

...and also states that %roomvnum is the same as %mapvnum. How is this not ambiguous and confusing?

The entire issue of room numbers is a bit of a mess with mapper numbers, roomkey, vnumber, roomid (as a number) and whatever is actually a mapfilename.db index number.

If I trigger for room.info.num (GMCP) and I suggest that this is assigned to #TAG vnum, is it actually applying this to ... %roomnum, %roomvnum, %roomid, %mapvnum?

Posted: Thu Jan 15, 2026 1:40 pm

I never got that deep in the mapper, but according to the help file the two vnum functions return the same result. likely retained for backwards compatability
they are the respective listorder of the room after %mapfilter, %mapquery, etc

%roomnum is creation order
%roomid is the string/list of short names you have to manually provide