Re: [INC] More Colors (1.0.0BETA)
 

Ok, but my previous question was just pointed at bl4nk's code :3

Re: [INC] More Colors (1.0.0BETA)
 

I added in CRemoveTags. I didn't include bl4nk's random RGB, yet, though. I'm also slightly worried about the idea of having a trie and an array for each plugin using colors. While a bit strange, using a plugin to manage color stocks may be a bit better, though then plugins would have to share the same custom colors added via CAddColor... I dunno. And yes, it's probably just easier to use \x07CUSTOM instead of {#CUSTOM}, but I was concerned about if it was fine in translation files, so I made the suggestion anyways.

If you're planning on implementing \x08, for simplicity I'd suggest having everything use \x08, using FF for the alpha for the included colors that are using \x07 right now.

... https://forums.alliedmods.net/showpo...0&postcount=25

Re: [INC] More Colors (1.0.0BETA)
 

I'll update the .inc in the OP when I get to a computer.

I was slightly concerned about every plugin having its own trie, but whatever.

I'd rather continue using \x07 for text with full alpha, since color codes take up part of the maximum chat message length. Each color would take up two additional characters.

Re: [INC] More Colors (1.0.0BETA)
 

This is pretty much unusable [for me] because CPrintToChatAllEx never works

Re: [INC] More Colors (1.0.0BETA)
 

Technically, we don't need CPrintToChatAllEx anymore, it's only there for backwards compatibility with colors.inc-using plugins. Its only function was to specify a color based on a particular client via the {teamcolor} tag, but you can do that now in various other ways, so.... yeah. What's the issue you're having with it?

Ooh, found the bug. VFormat under CPrintToChatAllEx should have '3' as the last arg, not '2'. McKay, you've gotta be saying 'damn you copypaste' right about now. Change that and you should be good to go, noodle.

McKay: your concerns over the extra 2 chars makes sense, considering some of the stuff people like to print to clients.

EDIT: Here.

Re: [INC] More Colors (1.0.0BETA)
 

Oops…

I'll try to update it today. That being said, this is still a beta and shouldn't be used in any released plugins…

Re: [INC] More Colors (1.0.0BETA)
 

Thanks breh

Re: [INC] More Colors (1.0.0BETA)
 

FlaminSarge: I'm not a huge fan of the way you're using both an array and a trie… uses up more memory and is a bit unnecessary. I prefer to parse the string to find tags then check if they match a color tag, but that's just me.

Re: [INC] More Colors (1.0.0BETA)
 

You'd still have to iterate through the trie's keys, and for that you need an array. Think about it:
1) Parse string, find { } tags. Save these locations somewhere.
2) At each location, check to see if the tag matches any color tags. You'll need to check every key in the trie, but you can't iterate through tries, so you'll need to go through some other thing that stores the keys. That's what the array's for (you could use the non-ADT array, but that won't have dynamic sizing so you'd have to have a MAX_COLORS define).
3) You replace those with empty space. You'd have to move all other pieces of the string down to where the tag is removed.

I believe in either case, you'd need something like that. Using ReplaceString and iterating through the array is much easier than manually editing the string like that.

If you're worried about space, you could make this a plugin, and then all plugins using it would share the same set of colors, and each time you added a color all plugins would get that color. That may or may not be a good thing.

Re: [INC] More Colors (1.0.0BETA)
 

Just use GetTrieString and check it doesn't return false. It's whole point is that it's a Trie so lookups are fast, iterating the whole list would be stupidly slow.