BeBot - An Anarchy Online and Age Of Conan chat automaton
Development => Coding and development discussion => Topic started by: Blueeagle on March 05, 2007, 11:04:54 pm
-
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
-
I've though about an extension of the basic color and scheme model.
One thing that I'm missing is that there is no way to define defaults (like your bot_* colors) that can be used in schemes, but aren't defined as pure colors.
Basically something like using schemes in scheme definitions. Basically that's possible, but you'd have to be extremely careful not to run into long circles.
To solve the circle problem while giving more flexibility I though about adding another layer between pure colors and pure schemes, something that can be used in schemes but still be fairly easy edited - with a change then being carried over to all schemes referring to it. I think the AO scheme Glara added as well as some of the global and most of the colors proposed by Blueeagle would end in there.
I'll try to add something like this to the colors and colorchange modules tomorrow.
-
Are we adding too much complexity? :D
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... :D
-
About the xml structure, try not to nest elements without really needing it, just makes parsing a hassle :P (I'll remember to post my xml parser later if we end up using xml for stuff)
So assuming there's only 1 <theme> in each file, we can lose the outer <xml>.
And maybe for the ease of editing, use attributes rather than elements
<element name="error" htmlcc="##557799" description="Color for WTFUSUX messages">
-
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.
-
XML files with themes wouldn't be bad at all really.
If each theme would be a seperate file, people could easiely exchange color themes and we can ship a bunch of themes with the releases without hardcoding queries in the source.
-
About the xml structure, try not to nest elements without really needing it, just makes parsing a hassle :P
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. ;)
-
About the xml structure, try not to nest elements without really needing it, just makes parsing a hassle :P
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. ;)
Better safe than sorry. always a hassle to edit something after it was implemented :P
on the main topic, I think that set of colors is a tad too much.
for example, for vhabot I use 3 different colors + base colors (orange/blue/red/green/etc).
the first 3 colors are configurable and the rest are static colors.
the colors are called header, highlight and normal.
imo, the key to getting standardized colors to use only a strictly defined set of 3 or 4 colors.
-
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.
-
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.
-
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 just had quite the eureka moment here. It actually got me out of bed just to type this.
Why don't
$this -> bot -> send_tell($target, $msg);
automagically set $msg = "##normal##".$msg."</font>"
and that all colors (ie. ##red##) go from being translated as '<font color="#FF0000">'
to being translated as '</font><font color="#FF0000">'.
And that ##end## gets translated into '</font><font color="$normalcolor">'.
That way the line:
##highlight##You ##end####normal##turned relay ##end####highlight##OFF##end##
could be written as
##highlight##You ##end##turned relay ##highlight##OFF
The first would be translated into
<font color="$highlight">You </font><font color="$normal">turned relay </font><font color="$highlight">OFF</font>
While the second would be translated into
<font color="$normal"></font><font color="$highlight">You </font><font color="$normal">turned relay </font><font color="$highlight">OFF</font>
Now checking if a line starts with a color code should be quite easy and then removing the first (now empty) <font> tag-pair and leaving exactly the same output for both inputs.
That would be a lot less color codes in the strings and thus making them much easier to read (and write).
This should be quite doable with minor changes to the current color module methinks.
Any thoughts?
-
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.
-
If you take themes to define default behavior for most output in standard form I think the following colors should be in a theme:
- normal output
- highlighted output
- error text
- blob text
- blob title
Normal output could additionally be split for the three channels - tells, private group and guild chat.
-
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.
-
Some modules use additional colors like a "light highlight" (!whois uses it for level and profession, and the "real" highlight, yellow, for the nickname).
That's what the schemes are for - if a module needs more defined colors, just go and add them for the module. No need to clutter the general theme with it.
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.
Personally I don't intent to loop the colors in the theme over the already defined colors of the theme. With five colors total most likely that's just not needed, editing 2 lines instead of one won't really hurt anyone.
-
If anyone got a decent XML layout for this I'll go around and add themes support into the colors module.
-
I'm not the worlds best on XML but I'll give it a shot.
<bebot color themes>
<version>0.3.svn</version>
<author>KoolDude</author>
<email>[email protected]</email>
<web>http://uberhost.net/kooldud3</web>
<theme>
<name>standard</name>
<module>
<name>global</name>
<normal>#123456</normal>
<highlight>#789012</highlight>
<error>#345678</error>
</module>
<module>
<name>ao</name>
<tell>#901234</tell>
<team>#567890</team>
</module>
</theme>
<theme>
<name>WayKoolColor5</name>
<module>
<name>global</name>
<normal>#123456</normal>
<highlight>#789012</highlight>
<error>#345678</error>
</module>
<module>
<name>ao</name>
<tell>#901234</tell>
<team>#567890</team>
</module>
</theme>
</bebot color themes>
Not sure if that's even close to being sane. I'm not an XML kind of dude.
Now the question is: Should there be a separate file for each module or should all of it be squeezed into one file?
In either case it is my opinion that we should limit the amount of colors to a core set. Vhab suggested something like 3 colors. That might be a bit low. The list I made would perhaps be too much too.
After reconsidering I am thinking something like
* Headline - For use on top of windows and perhaps with !c
* Highlight - For use on stuff that is to be highlighted like nicks, levels
* Normal - For normal text output to all channels.
* Error - For error messages apperantly.
* Enabled - For stuff that is turned ON (Might be skipped and use highlight instead)
* Disabled - For stuff that is turned OFF (As above
* Omni, Neutral and clan - For indicating faction (might be used instead of highlight for nicks
IMO that should be enough colors to liven up the output while keeping the theme configuration needs to a minimum.
I'm not saying we shouldn't support adding more colors but the modules shipped with the bot ought to use these standards.
By the way alreadythere. I wish you would hang with us on #[email protected] IRC channel. :)
-
Not sure we need all fields in your XML tree tbh. But a few more won't make much trouble I guess, while allowing nice informations.
- normal output
- highlighted output
- error text
- blob text
- blob title
I was planning to use those 5 colors in themes. For internal uses in the color modules they would be counted as colors, so you can make a scheme with the color ref of normal.
Now the question is should we allow scheme definitions in theme files too as an option?
It would allow a nice way of transporting whole theme and scheme definitions around, setup your bot, export all into a theme file, and overload any predefined values in next bot. But of course this would create some more overhead.
-
About the xml structure, try not to nest elements without really needing it, just makes parsing a hassle :P (I'll remember to post my xml parser later if we end up using xml for stuff)
So assuming there's only 1 <theme> in each file, we can lose the outer <xml>.
And maybe for the ease of editing, use attributes rather than elements
<element name="error" htmlcc="##557799" description="Color for WTFUSUX messages">
-
what i keep as general rule when working with xml, make sure all element names are constant and adding more data shouldn't cause newly named elements.
so instead of adding <colorname>#123123</colorname> you're better off with <color name="colorname" color="#123123" /> imo.
-
How about one theme per file and the following tags?
- <theme name="somename" version="0.1" author="someauthor" link="somelink" /> optional for some information about theme and author
- <color name="name" code="code" /> for the colors of a theme
- <scheme module="modname" name="schemename" color="colorname" /> for actual scheme information, optional again
That list got all information, is easy to parse if you keep to one tag per line for simplicity, and should cover all needs.
-
As I said. I'm no master of XML. :)
-
Implemented a first version of color themes. Theme files reside in the theme/ directory under the bot root, and end on the extension .colors.xml.
Right now 5 colors are expected in themes:
- normal
- highlight
- error
- blob_text
- blob_title
Recognized XML tags are:
- <theme name="somename" version="0.1" author="someauthor" link="somelink" /> optional for some information about theme and author
- <color name="name" code="code" /> for the colors of a theme using a color code
- <color name="name" color="colorname" /> for the colors of a theme using an existing color as color
Currently there is no UI to change the theme file yet.
I've left out the scheme support yet. Not sure if I'll add that to theme files, as it creates a few questions on updates. Should a scheme definition in a theme file be written into the table? And if you update it ingame should it be written to the theme file? Best would be to add support for importing and exporting scheme definition files, so you can setup your schemes, write them to a file and share or use in other bots.
-
ooh, small note about the xml.
valid xml requires there only to be 1 root element. think you could place the <color> within <theme> ?
-
So it should be something like the following?
<theme name="name">
<color name="color1">
<color name="color2">
</theme>
-
yep, that should do the trick.
-
Added UI for themes (!theme command).
Changed default XML structure to valid one - not that I really do any XML parsing, I just do simple pattern matching :)
-
is there a list of relevant color names for an Defualt.colors.xml?
The folder themes in trunk is empty...
Myself and a friend of mine tried the 5 colors that you mentioned in your previous post.
Right now 5 colors are expected in themes:
* normal
* highlight
* error
* blob_text
* blob_title
Recognized XML tags are:
* <theme name="somename" version="0.1" author="someauthor" link="somelink" /> optional for some information about theme and author
* <color name="name" code="code" /> for the colors of a theme using a color code
* <color name="name" color="colorname" /> for the colors of a theme using an existing color as color
But the blob_text and blob_title is black all the time.
It would be nice to find a default xml in one of the next revisions :D
Edit: We found a function wich tries to create this file. But we did not know that the bot needs writing rights on the themes folder :(
The Problme with body color is still there :(
-
Check the colors table, every color name in there is supported as colorname for theme colors. Most likely it's some spelling error, though the Default file should be spelled correctly.
Going to add Default theme file in themes/ asap though, should avoid some confusion.
-
Added importing and exporting of scheme settings.
Only existing schemes will be overwritten, no new created.