 |
dbosst
Apprentice
Joined: 15 Jun 2010
Posts: 121
|
 Posted: Sat Sep 11, 2010 9:29 pm
3.26 room names ending with period
|
This was not a problem in 3.25, but 3.26 has fixed a ton of stuff and is working a lot better, however this issue has shown up for me again that a newer version fixed.
I'll say I notice this problem most prevalently when I am updating the vnums in my map in map mode now... All of my room names in my map end with a dot "." (since the dot is even colored in the ansi part of the room name that is shown normally), but Achaea does not include that single trailing period in the mxp RName or GMCP info so all of my old room names are losing their dot at the end.. (which is creates some nonuniformity in my map and problems for mapper scripts that I use)
In 3.25 and before I was just #tag name with the room name and added a dot like this:
| Code: |
#local $name
$name = %concat(%trim(%gmcp.Room.Info.Name),".")
$name = %subregex($name,"^Flying above\s*","")
$name = %subregex($name,"^In the trees above\s*","")
#tag name $name
|
I've tried everything I could think of short of going back to my old hacky telnet triggers, but I can't seem to get the mapper to override at all with #tag at all.
The problem occurs since the mapper updates the room name when updating the vnum as well, BEFORE it even runs the GMCP trigger code...
So it ignores the #tag data completely ... Could you please not update the room name in this manner (before even the GMCP trigger script is processed) and wait for the prompt to see if the name is something different or custom what the server sends? (It's not respecting the WAIT FOR PROMPT options in other words) |
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Sat Sep 11, 2010 11:52 pm
|
GMCP uses #TAG internally. For those pieces of data, you will instead have to incorporate the various %room*() functions instead of #TAG. A simple replace of #TAG whatever with the appropriate #CALL %room*() works, but there are probably much better ways to do it.
|
|
_________________
EDIT: I didn't like my old signature |
 |
|
|
dbosst
Apprentice
Joined: 15 Jun 2010
Posts: 121
|
Posted: Sun Sep 12, 2010 12:49 am
|
I've found that method to be always inadequate since there are still remaining bugs with the onroom events, I shouldn't be having to undo what has already been changed... I am not even sure why it is changing the room name to begin with when it is only supposed to be updating the room vnum when the room already exists
|
|
|
|
|
oldguy2
Wizard
Joined: 17 Jun 2006
Posts: 1201
|
Posted: Sun Sep 12, 2010 4:19 am
|
See Zugg's comments in this thread.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sun Sep 12, 2010 4:29 pm
|
| Quote: |
| I am not even sure why it is changing the room name to begin with when it is only supposed to be updating the room vnum when the room already exists |
Because some people have maps with messed up room names and most people want the room name on their map to match the room name actually used by the MUD. CMUD will replace both the room name and the room exits with the GMCP data sent from the MUD.
As Matt mentioned, it is easy to fix this using your own GMCP trigger and then using %roomname to change the room name. I don't know what you mean by "still remaining bugs with the onroom events". I'm not aware of any problems with onroom events, but that doesn't even matter because this method doesn't have anything to do with onroom events. Just create a GMCP trigger for the Room.Info message and then use %roomname to change the name of the room to anything you want. |
|
|
|
|
dbosst
Apprentice
Joined: 15 Jun 2010
Posts: 121
|
Posted: Tue Sep 14, 2010 3:12 pm
|
Ok I have solved the problem by changing it to a PROMPT gmcp trigger than modifying the gmcp data... that seemed better
|
|
|
|
|
|
|
|
