suguested small change for functions.lua

[lisa]

I was wondering if it would be a good idea to have the bot use a different colour when printing it is loading a WP. At the moment there is a sea of prints of changing to different waypoint coords which is all green and then it changes WP and also green, so hard to find sometimes.

Code: Select all

cprintf(cli.rgreen, language[0], __WPL:getFileName());	-- Loaded waypoint path

to maybe red?

Code: Select all

cprintf(cli.red, language[0], __WPL:getFileName());	-- Loaded waypoint path

So now it will say
Loaded waypoint path XXXX.
In a more noticable colour.

Just a thought.

Edit: I quoted wrong code, fixed now.

[rock5]

The question I think you need to be answering is "why should the 'moving to waypoint' messages be singled out from all the other green messages?".

[lisa]

because it's a major change in what the bot is doing. changing from 1 WP to the next is an event that I know I personally look for if reading what bot is doing and at the moment it takes reading each line to see it.

It's not a change I would do an update for, just something to concider changing when the next update occurs. I've already changed mine to red, so I'm fine, not sure if anyone else would like it though.

[rock5]

I'd like to hear from anyone else who supports this idea.

I don't know about red. I think red is harder to read than green, well on my projector anyway. And red means 'error, something is seriously wrong'. Maybe 'lightgreen' so it just stands out? Actually I wouldn't mind making all the colors 'light'. It makes them a lot easier to see and read.

[lisa]

Original thought was orange but when I tried it the Textcolor hasn't been set for orange, so I just went with red.

[rock5]

I just checked. The 'lightest' colors in order (by my eyes) are:
white
yellow
lightblue/lightgreen/lightgray
pink
lightred
forestgreen/gray/turquoise/green

The last 4 colors are just barely acceptable. I wouldn't mind changing green to lightgreen, red to lightred and using white/yellow/lightblue/lightgreen/lightgray/pink to highlight other messages as needed.

[lisa]

I find the green hard to read, White is very easy to read but there is already so much of it with it being skills used.
I hadn't really put any thought into redoing the colour scheme but for me personally I'd change the skills to not white and have things that I want to grab my attention to be white.

[rock5]

I find the green hard to read, White is very easy to read but there is already so much of it with it being skills used.
I hadn't really put any thought into redoing the colour scheme but for me personally I'd change the skills to not white and have things that I want to grab my attention to be white.

Actually the skills are lightgray.

[lisa]

I've got my load WP set to yellow, same as the message you would get if you don't have a return path. Kinda fits together that way I think.

[rock5]

Administrator suggests user settings so the user can change the colors.
Something like;

Code: Select all

["MESSAGE_COLOR_ERROR"] = cli.red,
["MESSAGE_COLOR_WARNING"] = cli.yellow,
["MESSAGE_COLOR_STANDARD"] = cli.green,

I still think we could review the default colors used.

I think we need to define a system of levels. Something like;
error = lightred
warning = yellow
skilluse = lightgray

Maybe multiple levels of info colors
infolow = green
infomedium = lightgreen
info high = lightblue

Then decide what color messages should use. The least important and often never read messages should use infolow. Messages that still come out often but are a bit more important should be info medium. Maybe 'move to waypoint' messages fall in this category. Messages that don't come out often and are more important would use infohigh, messages like loading waypoint file or reversing direction or using a function to changes a setting. You get the idea.

[lisa]

sounds like a good plan, I like the user settings idea too as not everyone has the same setup or liking of colours.

[Alkaiser]

I agree that cli.red is hard to read. I use cli.white for my own custom notifications. I don't think that allowing for more user customization has a downside.

[jduartedj]

Administrator suggests user settings so the user can change the colors.
Something like;

Code: Select all

["MESSAGE_COLOR_ERROR"] = cli.red,
["MESSAGE_COLOR_WARNING"] = cli.yellow,
["MESSAGE_COLOR_STANDARD"] = cli.green,

I still think we could review the default colors used.

I think we need to define a system of levels. Something like;
error = lightred
warning = yellow
skilluse = lightgray

Maybe multiple levels of info colors
infolow = green
infomedium = lightgreen
info high = lightblue

Then decide what color messages should use. The least important and often never read messages should use infolow. Messages that still come out often but are a bit more important should be info medium. Maybe 'move to waypoint' messages fall in this category. Messages that don't come out often and are more important would use infohigh, messages like loading waypoint file or reversing direction or using a function to changes a setting. You get the idea.

Maybe a function could be done for that something like

Code: Select all

function printbot(msg,type,ingame)
local color;
local colorStr;

if not msg then
  return
end

-- define colors
if type == "warning" then
   color = cli.yellow;
   -- colorStr =   some code for ingame chat color system
end
-- and so on... ... ..
if not type then
  color = cli.white
  colorStr = ""
end

if ingame then
   --code to print in game chat using colorStr
end

cprintf(color,msg);

end

What do you think?

Code: Select all

printbot(msg[,type,ingame]);

EDIT: oops forgot about ["MESSAGE_COLOR_ERROR"] so it would be more like color = profile.settings.MESSAGE_COLOR_ERROR;

[rock5]

I like it but I'm not sure about mixing ingame and MM. Mainly because it could cause confusion but also because the colors you would use in the mm window would not necessarily be the same as you would use ingame.

I think it would be better to have a dedicated printtoclient function to make things clearer.

Also I'm not sure of the function name. Maybe 'printMSG'?

[rock5]

Then again, whats the difference between

Code: Select all

printf(type,msg)

and

Code: Select all

printbot(msg,type)

?

[jduartedj]

I like it but I'm not sure about mixing ingame and MM. Mainly because it could cause confusion but also because the colors you would use in the mm window would not necessarily be the same as you would use ingame.

The idea here would be that some people (I at least) would like some information to be presented on the client. For example I print my daily quests count in both MM and client.
Keeping the colors the same was only a matter of coherence between MM and game chat window.

Also I'm not sure of the function name. Maybe 'printMSG'?

printBot was an example we can use whatever. what about 'Text(msg,type)'?

Then again, whats the difference between printf(type,msg) and printbot(msg,type) ?

Not sure what you mean here. are you comparing cprintf(color,msg) with printbot(msg,type) ? or is it the order of args? anyway I think it is way simpler to write "error" than to remember that cli.lightred is the color used for errors, and also it would get the color from "settings.MESSAGE_COLOR_ERROR".

Also i included 'ingame' arg as OPTIONAL so that you can simply choose not to post to ingame which would be most common, yet sometimes you would like to post to ingame.

[rock5]

What I meant by "whats the difference between printf(type,msg) and printbot(msg,type) ?" is they are both just as easy to write and function the same (besides the arguments being reversed).

So the only reason to have the printbot function is so you can optionally write to the client but like I said I don't like using 1 function to do both.

So why not use

Code: Select all

printf(settings.MESSAGE_COLOR_ERROR,"Unable to read memory!") 

when writing to the mm window.

And have another function for writing to the client. You could also add other messaging options besides color like the options used with SendChatMessage

Still not convinced?

[jduartedj]

What I meant by "whats the difference between printf(type,msg) and printbot(msg,type) ?" is they are both just as easy to write and function the same (besides the arguments being reversed).

So the only reason to have the printbot function is so you can optionally write to the client but like I said I don't like using 1 function to do both.

So why not use

Code: Select all

printf(settings.MESSAGE_COLOR_ERROR,"Unable to read memory!") 

when writing to the mm window.

And have another function for writing to the client. You could also add other messaging options besides color like the options used with SendChatMessage

Still not convinced?

Convinced!

[rock5]

Actually, I recently came across the rombot function "addMessage(message)". It will send the message ingame. So the function you are looking for is already there if a bit low on options.

[lisa]

I thought we talked about using addMessage a couple of weeks ago when someone was trying to add messages to a certain tab on their chat screen?