Posts: 952
Threads: 16
Joined: May 2013
Thanks: 66
Given 105 thank(s) in 89 post(s)
08-08-2013, 02:45 AM
(This post was last modified: 02-04-2014, 08:46 AM by tigerw.)
Hullo!
Proposed plugin / server message standards:
All plugin messages to be prefixed with any following blocks, to be used as appropriate. - [INFO]
- [WARNING]
- [FATAL]
- [DEATH]
- [MSG]
The following properties to be assigned to each prefix:
- [INFO] - Green: success message, a command executed successfully
- - Yellow: informational message, a command needs more syntax
- - Rose: warning message, something mild (i.e. reload) happened / is about to happen
- [WARN] - Rose: something concerning (i.e. restart) happened / is about to occur
- [FATAL] - Red: a catastrophic error occurred (i.e. plugin crash)
- [DEATH] - Gray: denoting death of player, followed by reason
- [MSG] - Light blue: player to player ad hoc messaging, (i.e. /tell)
What do you think?
Posts: 1,469
Threads: 57
Joined: Jul 2012
Thanks: 66
Given 127 thank(s) in 108 post(s)
Maybe, but this would probably cause quite a bit of clutter to the chatbox. Maybe just standardise the colours?
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
08-08-2013, 02:55 AM
(This post was last modified: 12-19-2013, 04:31 AM by NiLSPACE.)
I liked the messages more before those prefixes came because it was more clear. You didn't suddenly have your screen full of capital letters. I agree with bearbin to just use colours.
Posts: 952
Threads: 16
Joined: May 2013
Thanks: 66
Given 105 thank(s) in 89 post(s)
Ah. The problem with colouring the whole chat: vanilla was white for a reason - the text was easily distinguishable whatever your background. Colouring just the prefix, and not the text, solves that whilst still distinguishing between chat and errors.
Besides, a multi-coloured chat full of hard-to-read messages (say, green against forest, or red against wool) is less clear than a colour coded tagging system, don't you think?
Personally, I think the caps are quite neat, but that's just my opinion.
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
(08-08-2013, 03:11 AM)tigerw Wrote: vanilla was white for a reason
The chats background is dark for a reason.
tigerw Wrote:green against forest, or red against wool
I tried it and I can read it perfectly.
Posts: 952
Threads: 16
Joined: May 2013
Thanks: 66
Given 105 thank(s) in 89 post(s)
(08-08-2013, 03:16 AM)STR_Warrior Wrote: (08-08-2013, 03:11 AM)tigerw Wrote: vanilla was white for a reason
The chats background is dark for a reason.
tigerw Wrote:green against forest, or red against wool
I tried it and I can read it perfectly.
Okay, what about condensing the prefixes? Say, to three letters? Minimum intrusion?
Okay, it's readable, but in my opinion, harder to do so. I can certainly speak for myself here, and the transparency of the chat doesn't help that much.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
I have a proposal, too
Let's make a bunch of functions in the Core that take care of sending those messages. For example:
function SendMessageFatal(a_Player, a_Message)
if (g_UsePrefixes) then
a_Player:SendMessage(cChatColor.Red .. "[FATAL]" .. cChatColor.White .. a_Message);
else
a_Player:SendMessage(cChatColor.Red .. a_Message);
end
end
-- global var at the top of the file, for Admin's configuration
-- If set to true, messages are prefixed, e. g. "[FATAL]". If false, messages are colored.
g_UsePrefixes = true;
Then other plugins can call these functions, too:
-- In the initialization:
function Initialize(a_Plugin)
g_Core = PluginManager:GetPlugin("Core");
end
-- Send message:
g_Core:Call("SendMessageFatal", Player, "message text");
Posts: 1,469
Threads: 57
Joined: Jul 2012
Thanks: 66
Given 127 thank(s) in 108 post(s)
Yep, makes sense. I might work on it in the morning.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
Another solution comes to mind, it would be less complicated for Lua devs, but it might get a bit involved for the C++ devs.
If there was a possibility for a plugin to load a specified Lua file from another plugin, we could just put all those messaging functions along with the config into a single Lua file inside Core and then have each plugin load that file by name ("../Core/Messaging.lua"). No need for the GetPlugin() / Call(FnName, ...) trickery, Lua could call those functions directly.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
02-06-2014, 09:06 PM
(This post was last modified: 02-06-2014, 09:07 PM by xoft.)
I like how you're currently moving the implementation directly into the server, so that we can avoid the awkward inter-plugin calls. I have a few notes, though:
- cWorld::BroadcastChat() should get an extra parameter, the message type, in front of the Exclude parameter
- cPlayer should get the same compliment of messaging functions (SendMessageInfo(), SendMessageWarning() ...)
- cPlayer:SendMessage() should get an extra parameter, the message type
- cWorld:BroadcastChatInfo() etc should redirect to cWorld:BroadcastChat using the appropriate MessageType parameter
- cWorld:BroadcastChat() should call cPlayer:SendMessage() with the appropriate message type
- cPlayer:SendMessage() should do the final message formatting
If the message formatting was configurable through a few world.ini settings (AddPrefixes, ColorizePrefixes, ColorizeMessages), that'd be great.
Moving the formatting to cPlayer::SendMessage() will allow us to later possibly add per-user formatting options, although currently it would only incur minor performance loss for the broadcast messages.
EDIT:
Note: by providing a manual binding for cWorld:BroadcastChat(), you will be able to support both the new and the old model - just detect the param count and types and decide what to do based on that. Similar for cPlayer:SendMessage().
|