Question 3.63 Colour Code FAQ and Information

Vatiken
Topic Author
Offline
Administrator
tbaMUD Programmer

22 Jun 2012 03:21 - 22 Jun 2012 04:31 #167 by Vatiken

3.63 Colour Code FAQ and Information was created by Vatiken

"Characters" in code:
Each visible and non-visible character in the code can be referenced by a digit. The capital letter 'A' is equal to a 65, while a small letter 'a' is 97. Some character's in C code can't be displayed because they are either not visible, such as a carriage return, or a null, or because they are used within the code itself, such as quotation marks. These non-visible or otherwise used characters can be accessed thru escape codes such as '\r' for a carriage return, '\0' for null, or '\"' for quotations.

tbaMUD 3.62 vs 3.63:
The colour parsing system in 3.62 used character 64 or '@' as a special marking character, this indicated that the next character would used to determine a colour code. Because this system handled ONLY colour, this wasn't an issue.

3.63 uses character 9, or TAB (escape code = '\t') as the indicator character because the interpretation system (protocol_output) handles more then just colour, and addition security was required.

Security:
MXP and other protocols offer up significant possibilities, both for developer potential and player mischief. MXP for example, allows for pop-up menus, tool-tips, clickable links, 16 bit colour, and MSP(Mud Sound Protocol). A developer with access to this can greatly reduce the entry-barrier for new players, and create a more robust tool-set for builders and other staff members. A player could use this to spam audio clips on chat channels, or create false links which cause victims to remove/drop all equipment and self-delete.

Because clients(all that I can think of) are unable to send character 9(TAB), this significantly lowers the risk of potential abuse when used in conjunction with MXP.

Back Port:
So for 3.63, we moved over to character 9(TAB) but we implemented a system to allow for back-portability with MUDs who would still be using character 64(@) in their world and text files. How it works is any "@" within a file* will be turned into character 9(TAB) as it is loaded. When it is saved, it is turned back into "@" and written to file.
*Files that have been adapted for back-portability.

Usage (Oasis OLC):
All single line strings (Room Names, Short Descriptions, Aliases, etc..) will have any user entered "@" turned into character 9((TAB) prior to be saved to the object/room/mobile etc...

Usage (Improved Editor):
Strings entered through the improved editor(tedit, mobile/room descriptions, help files, etc...) have to be manually toggled from character 64(@) to 9(TAB). This is done through the editor option "/t" (similar to /f for format, or /s for save). This also allows the user to transfer backwards to use of "@", which makes it easier to copy/paste a file w/codes to an external editor.

Usage (Other):
Other uses, such as in comm channels, or any other area where you may wish to permit a player access to character 9(TAB), will have to be manually added in. (cedit option in upcoming release). This can easily be done using the "parse_at(char * string)"* function, which will simply replace all instances of character 64(@) with character 9(TAB). Please note, tbaMUD 3.63 released with a bug that caused "skip_spaces()" to ignore character 9(TAB) when used first in an argument. This was fixed and is available is the tbamud.com SVN. Examples of using "parse_at()" within functions such as "do_say()" can be found in the old forum, or in the lastest "act.comm.c" in the SVN.
*"parse_tab(char * string)" also exists, for the reverse functionality.

===============================================================
Frequently Asked Questions:::
===============================================================

I typed "say @RRed@n" into my MUD client, and it came up as "You say, '@RRed@n'"! Why is my colour not working?!?
Make sure your version of tbaMUD 3.63 is up-to-date with the post-release bug fixes (available in the SVN), and simply place a "parse_at(argument)" in "do_say()" after "struct char_data *vict;", or more importantly, before the argument is sent out to the players in-room.

I typed "\t" into a room-description but it just shows up as "\t".
"\t" entered into a room-description is just that, an '\'(character 92) and a 't'(character 116), as opposed to an '\t'(character 9) which is required for protocol_output() to acknowledge an upcoming code. To utilize a colour code, use character 64(@), followed by the required code, Example: @RRed@n, and then use the editor option "/t" to swap characters between '@' and '\t'.

Why did you change the colour code "@" to the tab? This is confusing, and I don't like it.
The special character is now used for more then just colour, and as such a more in-depth processing system was required. Refer to the above security information.

Having to type in "/t" into the improved editor to manually exchange characters offends me to my core, I want proc_colors() back.
"proc_colors()" is a simple static function, and can easily be pulled from the old circleMUD ftp site, or a previous version of tbaMUD and slapped back in within a matter of minutes. It will offer unnecessary cpu overhead, and redundant, out-dated functionality, but the choice is yours.

Placing a "parse_at()" in the functions I would like to allow the player to contribute special codes to is taking me far too long, isn't there a faster way?
Yes, Thread: Post 4516 includes an example where I placed a parsing function in "get_from_q" which would automatically swap any incoming '@' for an '\t'. As mentioned though, this opens the door to potential security risks if the MUD developer isn't careful.

Why not use a cedit toggle to swap between proc_colors() and protocol_output() based on developer preference?

But why? Is anyone who downloads the source code for 3.63 gonna switch on a cedit toggle for an outdated parsing function that only enables 16 colours, when the default system enables 256 Xterm colours, 16,772,216 Colours through MXP, as well as clickable links/lists, tool tips, gauges etc, as well as charset icons, and yadda yadda yadda.

How do I enter an MXP clickable link into a helpfile?
To use an MXP clickable link, you require an MXP capable client, and similar to colour codes you would do something like this in hedit's improved editor:

Code:

> @(HELP MXP@)
> /t

If you are using MXP within your code, for say selecting a character's sex at creation time. You'd do something like this:

Code:

write_to_output(d, "Select your sex, \t(M\t)ale or \t(F\t)emale.\r\n");

How do I play a sound?
Sound can be played in 3 ways:
1) Through an OOB protocol such as MSDP or ATCP, with the aid of a client plug-in
2) Through MSP(Mud Sound Protocol), with the aid of a compatible client
3) Through MXP's MSP, with the aid of a compatible client

For information on SoundSend() refer to ProtocolSystem.txt found in the /doc folder.
For basic MSP, you can refer to this * for some more information.
For MXP-MSP, you can refer to this *
For sound through OOB protocol and a compatible client, you'll have to refer to your client's documentation.
*Protocol Standards for MXP, and MSP aren't set it stone, as what works for zMUD might not work for another client.

tbaMUD developer/programmer

Last edit: 22 Jun 2012 04:31 by Vatiken.

The following user(s) said Thank You: rudeboyrave

The topic has been locked.

Time to create page: 0.191 seconds