 |
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
 Posted: Mon Sep 06, 2010 2:17 am
[3.25]room.info.brief isn't always description...
|
In the case of Aardwolf, it's the room name, so I'm wondering if there's a way to force CMUD to recognize that it's the room name and not the description... Or if this can be added as an option. I'd like to be able to map using proper room names instead of whatever the last line that fired happened to be (such as WARFARE:, etc).
Charneus |
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Mon Sep 06, 2010 2:46 am
|
Right now, .brief is fixed as the room description per the IRE implementation of GMCP. Apparently, they made it a point to send .name whereas Lasher decided he didn't need .name and so Zugg didn't realize the "nonstandard" use of .brief was going on. In 3.26, he's going to make GMCP name detection use .brief if .name is not found.
|
|
_________________
EDIT: I didn't like my old signature |
 |
|
|
oldguy2
Wizard
Joined: 17 Jun 2006
Posts: 1201
|
Posted: Mon Sep 06, 2010 3:39 am
|
We already went over this in the other thread. Also IRE never used Brief for room description. It was always the room name even in ATCP.
See this thread. |
|
|
|
|
Aylorian
Beginner
Joined: 07 Jul 2008
Posts: 14
Location: Orlando
|
Posted: Thu Sep 09, 2010 7:08 pm Re: [3.25]room.info.brief isn't always description...
|
| charneus wrote: |
In the case of Aardwolf, it's the room name, so I'm wondering if there's a way to force CMUD to recognize that it's the room name and not the description... Or if this can be added as an option. I'd like to be able to map using proper room names instead of whatever the last line that fired happened to be (such as WARFARE:, etc).
Charneus |
This is why the data formats have been posted to the Aardwolf wiki page for over a month now and never officially released ... because they are in "RFC" mode. After reading this and the linked thread, I concur that room.name does make much more sense. I can't even remember why I made it "brief" in the first place as it really doesn't fit. I'll make the change to room.name but can only work on things that are brought to my attention. I just stumbled across this thread looking for something else.
I really need to tell the Aardwolf users it's safe to build plugins based on what we already have so far soon, we can only hide behind "RFC" for so long.
Can anyone think of other scenarios where the function of a specific GMCP tag is considered "special" in CMUD and does something other than just populate the gmcp data table? The room.name value already discussed is a perfect example of this. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Sep 09, 2010 7:44 pm
|
Right now the only (non-core) GMCP messages that CMUD performs additional processing on are: room.info and ire.composer.edit (for editing within the local CMUD editor). Eventually I hope GMCP will have a standard message for doing local text editing, and then CMUD will support that too.
In the room.info, CMUD is currently grabbing the following fields for the mapper:
name (brief used if name is empty in v3.26)
desc
exits
num
details (sets the User-defined Flags text field for the room for user scripting of room type)
Right now CMUD ignores the numeric values in the exits and just uses the exit names. That might get enhanced in the future. CMUD will probably also use the coordinates in room.info in the future. |
|
|
|
|
Aylorian
Beginner
Joined: 07 Jul 2008
Posts: 14
Location: Orlando
|
Posted: Thu Sep 09, 2010 9:30 pm
|
| Zugg wrote: |
name (brief used if name is empty in v3.26)
desc
exits
num
details (sets the User-defined Flags text field for the room for user scripting of room type)
Right now CMUD ignores the numeric values in the exits and just uses the exit names. That might get enhanced in the future. CMUD will probably also use the coordinates in room.info in the future. |
Thanks for this info. If the 'brief' was added just because of this post, might as well remove it, I'm going to change it to room.name.
It will never be easier for me to change these tags than it is right now, so a few questions to be as inline with CMUD as possible:
I don't send Room.desc at all, is that going to cause you a problem?
What exactly are you expecting in details? A JSON array or a text delimited list such as "shop, temple, morgue" etc. We currently call this "flags" but I will change it to room.details
Are there any specific "flag" names you are looking for and handling as a special case, such as "shop"? If any of these actual values need to be standard, now would be the time to get this out there.
Anything else you can think of? Perhaps it is worth taking this to mudstandards.org?
Also, a warning on coordinates - they mean something very different on Aardwolf than they do on IRE MUDs. I believe on IRE MUDs they assigned coordinates to each room so that a mapper can be drawn with variable sizing on the rooms, which is a nice workaround for non-euclidean areas. On Aardwolf, they mean your location on a continent. If you are inside an area, in most cases the coordinates will be the location of that area on a continent and have no bearing on where you actually are *inside* that area. Perhaps I should call them something other than "coords".
IRE uses "environment" for a particular type of terrain. We use "sector". Do you plan to use this value at all, perhaps to color rooms based on their sector type (which is how our in-game mapper works)?. I didn't use 'environment' because it seemed a little long when a shorter value would do, but realistically it is probably safe to assume that anyone with a client capable of doing GMCP is also capable of MCCP so I can change this if you think it might cause issues later.
To change these now is trivial. To change these in a month is going to require a re-release of any plugins released that use it and rework on the part of Aardwolf players that have built scripts around them. Some of them might have already done so, but that is with the disclaimer that they are in test and very subject to change. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Sep 09, 2010 9:45 pm
|
| Quote: |
| If the 'brief' was added just because of this post, might as well remove it |
Yes it was, so will do, I'll remove that in v3.26. Thanks for correcting it on the MUD end.
| Quote: |
| I don't send Room.desc at all, is that going to cause you a problem? |
Shouldn't cause any problem except that the mapper won't get any description info. However, CMUD will not overwrite any existing description if the room.desc data is not sent, so the player is free to write scripts to try and capture this text themselves. With GMCP, the mapper doesn't use the description when speedwalking, so not sending it shouldn't break anything.
| Quote: |
| What exactly are you expecting in details |
Just a plain text string. CMUD just takes that string (if sent) and stores it in the user-defined string for the room to allow players to perform additional mud-specific scripting. CMUD does not parse this string at all. But players might use it to set the color of the room, for example. Trying to standardize this text will probably be very difficult. I just implemented it as a way to send mud-specific data to the CMUD room object.
| Quote: |
| Perhaps I should call them something other than "coords". |
If you are sending data different than what IRE is sending, then you should probably use a different variable name. I would expect "coords" to be some sort of actual X,Y,Z coordinates. In the future, CMUD will probably use this to determine where to place a new room relative to the previous room. So if you are inside and send the same coordinates, CMUD might end up creating the new room on top of the previous room.
| Quote: |
| IRE uses "environment" for a particular type of terrain |
CMUD doesn't use that, but players are free to write a GMCP trigger to color their rooms based on this data. Since "terrain" is going to be MUD specific, I don't see any problem using your own name for this variable. Although maybe "terrain" might be better than "sector" since "sector" makes me think of zone/areas. I agree that "environment" does seem a bit long. That's why CMUD uses "desc" instead of "description" for example. I know some people really like long descriptive names, but I've always thought short cuts were fine. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Sep 09, 2010 10:14 pm
|
Oh, I thought of one more thing that CMUD will handle. This is something new I was working on with IRE. It is the Room.WrongDir message. When a player moves in an invalid direction in a room, IRE is sending Room.WrongDir with the name of the direction as the string value. For example:
Room.WrongDir "se"
CMUD will detect this in v3.26 and automatically issue a #NODIR command so players do not need to script the CMUD mapper to handle invalid directions. It prevents bogus rooms from being created in the wrong direction.
I think IRE is only sending this when the player moves in a direction that doesn't exist rather then in all of the other cases movement might be blocked (closed doors, etc). So it doesn't fix the mapper completely, but it helps.
If you feel this is useful and easy to add to Aardwolf, that would be great. |
|
|
|
|
Aylorian
Beginner
Joined: 07 Jul 2008
Posts: 14
Location: Orlando
|
Posted: Thu Sep 09, 2010 10:38 pm
|
| Zugg wrote: |
Oh, I thought of one more thing that CMUD will handle. This is something new I was working on with IRE. It is the Room.WrongDir message. When a player moves in an invalid direction in a room, IRE is sending Room.WrongDir with the name of the direction as the string value. For example:
Room.WrongDir "se"
CMUD will detect this in v3.26 and automatically issue a #NODIR command so players do not need to script the CMUD mapper to handle invalid directions. It prevents bogus rooms from being created in the wrong direction.
I think IRE is only sending this when the player moves in a direction that doesn't exist rather then in all of the other cases movement might be blocked (closed doors, etc). So it doesn't fix the mapper completely, but it helps.
If you feel this is useful and easy to add to Aardwolf, that would be great. |
I can add this for N,E,S,W,U,D ... we don't use ne,se,nw,sw as standard directions. However, literally any string can be an exit, things such as 'climb ladder' 'push button', etc. An exit can be defined as a command that exists in that room only. This isn't widespread ( < 1% of rooms ) so I'm not covering this at all in GMCP, particularly as these exits tend to be 'hidden' (not shown in any exit type commands). |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Sep 09, 2010 10:56 pm
|
That would be great. And yeah, don't worry about non-standard directions like portals.
|
|
|
|
|
Aylorian
Beginner
Joined: 07 Jul 2008
Posts: 14
Location: Orlando
|
Posted: Fri Sep 10, 2010 6:17 pm
|
This is now available on our test port at aardmud.net 6555 - will be in the live MUD sometime next week when we reboot. Thanks for the info!
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Sep 11, 2010 5:21 pm
|
Found another issue with GMCP on Aardwolf:
The room name (still room.info.brief, but soon to be room.info.name) sometimes has ANSI color codes in it. I'd recommend against this. GMCP should be sending the plain data and not any "presentation" (such as color). CMUD v3.26 will strip the ANSI codes in the GMCP data before storing it in the mapper, but you might want to remove this on the MUD side to prevent problems in other clients.
It might also cause problems in some JSON parsers that do not handle control codes properly if they are not escaped. The strict JSON protocol would require the ESC to be encoded as \u001b and I'm guessing that you probably don't want to mess with that. The CMUD JSON parser properly handles binary data and control codes, but other clients might not. |
|
|
|
|
Aylorian
Beginner
Joined: 07 Jul 2008
Posts: 14
Location: Orlando
|
Posted: Sat Sep 11, 2010 11:41 pm
|
| Zugg wrote: |
Found another issue with GMCP on Aardwolf:
The room name (still room.info.brief, but soon to be room.info.name) sometimes has ANSI color codes in it. I'd recommend against this. GMCP should be sending the plain data and not any "presentation" (such as color). CMUD v3.26 will strip the ANSI codes in the GMCP data before storing it in the mapper, but you might want to remove this on the MUD side to prevent problems in other clients.
It might also cause problems in some JSON parsers that do not handle control codes properly if they are not escaped. The strict JSON protocol would require the ESC to be encoded as \u001b and I'm guessing that you probably don't want to mess with that. The CMUD JSON parser properly handles binary data and control codes, but other clients might not. |
There is a GMCP command that can be set so that any color in GMCP data is sent as Aardwolf color codes (@R=red, @Y=yellow, etc) rather than ANSI codes. CMUD stripping the ANSI codes for its own purposes is no problem, but leaving out the information globally isn't something I want to do.
The GMCP room info is also being used for the regular "ascii" mapper and who knows what else people will use it for -- it goes beyond any single mapper/plugin in any single client. We can't predict every use someone might have for room name and whether or not they will want color with it, so the default is "send the information and if they want to strip it they can".
With all that being said, I'd have no problem with giving people another option to remove color from all GMCP messages period (rather than ANSI or Aard color codes), but as I said, in most cases people are going to want this information. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
