You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When thinking about MXP issues lately (like how Mudlet is evaporating unrecognized tags instead of printing them verbatim), it occurs to me that perhaps as soon as we negotiate MXP on, we should be locking into locked mode (<ESC>[7z), meaning only single lines which we explicitly turn into OPEN or SECURE mode will honor those tags. This way all lines like more prompts, who output links, or other similar official game-generated output with no user-generated content can place into the right mode.
From there we may want to consider new tickets for further itration: Perhaps we can rely on normal color codes being given conditional permission to be converted (by the command processor?) into escape color codes. E.G. if the player has permission to use colors in say commands then when they type the color code placeholder (whatever that is, per #83 we probably want to change it) then their say output can include the escaped color codes. Consider adding a ticket from there to give easy admin control (app.config?) decision over how "permissive" they want to be with users colorizing things. (E.G. a "free for all, go nuts" category letting all players color everything, a moderate category for players to be able to use them in in-game bulletin board notes and maybe their player description and similar format contents, admin only mode where only admins can color at all, or a fully restricted mode where not even admin command processing looks for color codes.
The text was updated successfully, but these errors were encountered:
When thinking about MXP issues lately (like how Mudlet is evaporating unrecognized tags instead of printing them verbatim), it occurs to me that perhaps as soon as we negotiate MXP on, we should be locking into locked mode (
<ESC>[7z
), meaning only single lines which we explicitly turn into OPEN or SECURE mode will honor those tags. This way all lines like more prompts, who output links, or other similar official game-generated output with no user-generated content can place into the right mode.From there we may want to consider new tickets for further itration: Perhaps we can rely on normal color codes being given conditional permission to be converted (by the command processor?) into escape color codes. E.G. if the player has permission to use colors in
say
commands then when they type the color code placeholder (whatever that is, per #83 we probably want to change it) then their say output can include the escaped color codes. Consider adding a ticket from there to give easy admin control (app.config?) decision over how "permissive" they want to be with users colorizing things. (E.G. a "free for all, go nuts" category letting all players color everything, a moderate category for players to be able to use them in in-game bulletin board notes and maybe their player description and similar format contents, admin only mode where only admins can color at all, or a fully restricted mode where not even admin command processing looks for color codes.The text was updated successfully, but these errors were encountered: