[404UserNotFound]

This plugin started its life as a copy of simple-chatprocessor.sp that I had converted over to new syntax. Redwerewolf was interested in redoing SCP from the ground up to make it better, but he didn't want to have to convert it all over to new syntax...until I told him I had already done so. That was pretty much the moment he decided to work on this.

Some of you may be looking at this, and thinking "What's the point of this when I can just use Simple Chat Processor?". Well, there's one thing that you can do with this that isn't possible with Simple Chat Processor, and that's using PrintToChat functions within OnChatMessage. SCP suggests not using PrintToChat functions within OCM because OCM itself uses a PrintToChat function to send the chat message to all valid recipients, which results in multiple copies of the same message being printed in chat (one message for each player) when you use a PrintToChat function within OnChatMessage when you use SCP.

Page-lengthening technical info within, proceed at your own peril

So what does that mean exactly? Well, it means you can get around the MAXLENGTH_NAME limitation (which is 64 characters), thus allowing you to do longer tags and even multicolored or rainbow tags. You see, not only did I provide the idea and base framework for this plugin, I had paid Redwerewolf to make me a private tag-related plugin and as a result of that project, I discovered this little trick to get around the MAXLENGTH_NAME limitation. For the sake of page length, and easier reading, I'm going to separate the next bit into individual spoilers.

The code snippet to accomplish longer/multicolored chat tags

Spoiler

Here's a snippet from my custom tag system plugin that I don't mind spreading around because it would help out so many people;

PHP Code:

public Action OnChatMessage(int& iAuthor, Handle hRecipients, eChatFlags& flag, char[] strPlayerName, char[] strMessage)
{
    TFTeam iAuthorTeam = TF2_GetClientTeam(iAuthor);
    
// iTagID is part of my custom chat tag plugin, this check just determines if the
// message sender has a chat tag "equipped" or not, and then displays the chat message
// based on whether or not the player has a tag equipped.
    if (iTagID[iAuthor] > 0)
    {
// Now we check the trie of tag strings that we pulled from the SQL table of tag strings
// which are stored in "{valve}[OWNER]" format alongside a "plaintext" string version for the tags menu
// which is stored as "[OWNER]".
// First we get the ID value of the tag (ID value from the SQL table)
        char sID[12];
        IntToString(iTagID[iAuthor], sID, sizeof(sID));
// Then we reference the trie and look for the matching ID, then pull the tag string for that ID #
        char sTag[256];
        GetTrieString(hTagsTrie, sID, sTag, sizeof(sTag));
        hTagsTrie.GetString(sID, sTag, sizeof(sTag));

// Strip quotes and such off the tag
        StripQuotes(sTag);
        
        if (strlen(sTag))
        {
// Client has a tag, so we'll set the message up to display the tag before the player's name.
// I'm also using a custom "teamcolors" thing for the player's name which is basically this:
//char g_strTeamColors[][] = {
//    "{teamspec}", // unassigned, only visible on iOldTeam != 0
//    "{teamspec}",
//    "{teamred}",
//    "{teamblu}"
//};
            CPrintToChat(iAuthor, "%s %s%N{default} : %s", sTag, g_strTeamColors[iAuthorTeam], iAuthor, strMessage);
        }
    }
// Client's tag ID is 0, they do not own a chat tag yet, or they have unequipped their chat tag altogether
    else if (iTagID[iAuthor] == 0)
    {
// Set up the chat message without the chat tag, and display it.
        CPrintToChat(iAuthor, "%s%N{default} : %s", g_strTeamColors[iAuthorTeam], iAuthor, strMessage);
    }
// This prevents the original chat message from being sent
    return Plugin_Stop;
} 


Basically, what I'm doing is using CPrintToChat to display the entire message; The sender's chat tag (if applicable), their name, and their message are all part of this one CPrintToChat. I know what some of you are thinking "That's gonna cut off a lot of the player's chat messages if the tag string is too long".

My personal notes from testing the above snippet, plus indepth information on what's going on, and some alternate methods I tried.

Spoiler

Well I tested out a rainbow colored tag ingame using two different methods of attaching the tag;
1. The standard method, formatting the tag string into the sender's name string of OnChatMessage.
2. The nonstandard method, using CPrintToChat to print the chat tag, the sender's name and the chat message all in one CPrintToChat message.

With method #1, it would result in not only text being stripped from longer messages, but it would also result in longer, multicolored chat tags cutting off half of your Steam name if you had a longer Steam name. Check out this screenshot for evidence. Notice the multicolored "[HOT]" tag results in the majority of the "marketplace.tf" link in my name getting cut off. When I switched to the single colored "[OWNER]", tag, it prints the entirety of my name just fine. That was an issue for me because I wanted multicolored tags to be a possibility and I know other people have asked about multicolored tags too (Shavit for example, I saw an old post of his where he inquired about it)

With method #2, it displayed everything perfectly. Check out this screenshot for evidence. The list of characters I typed into chat was to test how much of the chat message got cut off. As it turns out, it only removed one character (the % symbol, for some odd reason), and the rest of the message displayed just fine. As well, while typing up that huge bunch of characters, that message you see in chat is 1 character away from being at the max # of characters you can send in a message.

By the by, please ignore the duplicate chat printout in the screenshot, that's a result of a bug with Simple Chat Processor and originally this plugin too, caused by how SCP relayed OnChatMessage messages to clients, which Redwerewolf has patched up in this plugin.

Originally Posted by redwerewolf It does work, I tested it. I pushed some fixes to it though such as duplicate messages for the author himself and I also made sure to add the author to the list of recipients array.

Yeah, this was an issue, but for anyone interested as to how the solution was figured out...well...you have Bottiger to thank for that. He suggested aggregating recipients through an array to ensure the message was only sent once globally, but the bug was never fixed in SCP.