Welcome to the Builder Academy

Question 3.63 Colour Code FAQ and Information

22 Jun 2012 03:21 - 22 Jun 2012 04:31 #167 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.

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:
> @(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:
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.202 seconds