I am liking the colors module very much even though I misunderstood its purpous a bit in the start.

What I am really missing is a "bot" color scheme with colors for stuff that the bot outputs. This would make for easier themeing of the bot imo as a person wanting a color for a nickname in one module most likely wants it in another module aswell.

I propose we make a predefined set of colors such as

* bot_nickname (default color of nickname)
* bot_level (default color for text containing the level of a toon)
* bot_ai_level
* bot_ai_rank
* bot_firstname
* bot_lastname
* bot_breed
* bot_gender
* bot_profession
* bot_guild_name
* bot_guild_rank

* bot_guild_text (default color for text sendt to GC)
* bot_tell_text (for tells)
* bot_tell2_text (for tells to people not member of the bot)
* bot_privgroup_text
* bot_gmsg_text
* bot_window_text (for the info windows)

* bot_omni (next three would be useful with whois and tower attacks)
* bot_clan
* bot_neutral

Please add to the list with colors you think we need to standardize the modules.


An alternative would be to check if a color has been defined for that module and for that text type (ie nickname) and use that. If such a color doesn't exist look in the default bot scheme and use that. That way end users could define colors separately for all modules and still have sensible (question of definition I know) defaults for others. They can also alter the default colors and have that reflected in all modules. This would however require some reworking of the colors module methinks.

Thoughts and ideas are welcome

- Blueeagl3

Are we adding too much complexity?

My initial thinking on this module was to define a number of elements ie:

##tell_out##, ##headline##, ##infotext##, ##warning##, etc.

Then set a theme for the bot. ie: theme == bebot default. New themes could be easily defined in XML, txt, whatever as it would be ##element## => hex code.

Then if the end user changes the theme, all the color output would change to the selected theme.

Example color theme, where default is error messages are red.
<xml>
<theme>
<name>BeBot Default</name>
<element>
<name>error</name>
<description>Color for Error Messages.</description>
<htmlcc>#FF0000</htmlcc>
</element>
</theme>
</xml>

So maybe Glarawyn decides that error messages should be yellow. Glarawyn would create a new theme:
<xml>
<theme>
<name>Glarawyn</name>
<element>
<name>error</name>
<description>Color for Error Messages.</description>
<htmlcc>#FFFF00</htmlcc>
</element>
</theme>
</xml>

The actual output code would be:
$this -> bot -> send_tell($name, "##error##You are an idiot.##end##");

but the output color would change depending on which theme is in use.

Make sense? Maybe...? Whatever...

My idea is similar to yours Glara - I want to add a layer between pure colors (which aren't supposed to change right now) and the schemes (which always refer to a color, the color can be selected and changed among all existing colors).

That layer should be something that refers to a color like a scheme, but can be refered too by schemes too like a color. A bunch of basic and global aliases.

My idea was to keep it in the db, with an interface in the bot.

About the xml structure, try not to nest elements without really needing it, just makes parsing a hassle

The source of that XML is my butt, so by no means does it have to be in that format. It was just an example.

I don't mind offering some way to read and write themes to xml files for easy distribution.

I think that themes should be written to some table too though, so the bot got easy and fast access to them.

The interface could be some bot commands or some simple scripts which parse the xml files or creates them if wished.

imo, the key to getting standardized colors to use only a strictly defined set of 3 or 4 colors.

Actually that might be a much better approach. Because too much configurability might make the whole feature worthless.

Perhaps reducing the list of colors would be the way to go?

Also the base colors need not be strict strict. Ie if someone wants a blue-ish theme they can chage ##red## to something more like purple to keep in with the theme (that is defining ##red## to be #FF8000 (orange) using for example xml or in-game commands)

That would make the default list:

//Primary colors:
red -> #FF0000
green -> #00FF00
blue -> #0000FF

//Secondary colors
yellow -> #FFFF00
magenta -> #FF00FF
cyan -> #00FFFF

//Contrasts
black -> #000000
white -> #FFFFFF

//Definable colors
heading -> #??????
highlight -> #??????
normal -> #??????

That still leaves us with the question of which color goes where. Take fore example the !whois reply. Should we only use normal + highlight + green (for ai-level) here?

And we should have a list to keep the use of anything but normal, highlight and header (which use should be quite apperant) standardized thruought the script. (ie all errors are ##red##.

Now the question is this: Would it be possible to make "##red##You need to have access level ##highlight##ADMIN##end## or higher to access this command##end##" show as a red-ish highlight not identical to for example "##normal##Relay was turned ##highlight##OFF##end## by ##highlight##Blueeagle##end####end##" in which case the two highlights would be lighter versions of what ever ##normal## would be. Ie. ##highlight## takes the current color and brightens it.
I am not sure how that would be implemented since you'd have to keep a table in the output functions that sais which color you're currently using. It might even be "a bad idea"(tm) to attempt, but methinks it would be cool. :p

Also drabing down the primaries might be a good idea as bright green is just plain ugly imho. But that's something for the default theme.xml if such a thing is made.

Blueeagle

I don't see any point in reducing the amount of available colors in the colors table (and predefined in the module). Especially if themes are going to use those color definitions.

Right now the send_gc, send_pgroup and send_tell functions already colorize the output. Only small bug is that pgroup and gc use the same scheme right now, should perhaps be seperated into two.

you'd only read the xml once imo.
read the xml and cache the results. when a different theme is selected from the interface it loads that xml and caches it.
if you make the xml files editable from ingame, you write the files and update the cache.
imo, keeping a few variables > doing a query every time to fetch colors.

I'm caching the colors tags anyways. Doing any correlating between themes, colors and schemes once by hand instead of in the db engine shouldn't create any noticeable overhead, so doesn't matter much either way.

Some modules use additional colors like a "light highlight" (!whois uses it for level and profession, and the "real" highlight, yellow, for the nickname). And, yes, stuff like green for AI levels, orange for clan and cyan for omni (some tower wars modules). But in the end, limiting oneself to 5 colors is probably better, anyway. I gotta say that I like the very sparse use of color in Vhab's bots for example. And the more colors you use, the harder it is to find a good fit that is pleasing to the eye.
But... if you split normal output into three, you maybe need to split highlighted and error output as well. Again, to make it easier to find a nice match of colors. If you split those as well, you only have to find a nice set of 3 colors, which is (for me at least) easier than to find one for 5. Although, that means finding 3 sets of 3 colors. But then again, I am a lousy artist.
Whatever format is being used for color schemes, would be cool if you could reuse the stuff you have defined already. Like, if you already defined gcerror (error message in guildchat, whatever) to be #FF0000, you can set pgerror to gcerror instead of setting it to #FF0000 as well.