Proposed Message Standardisation
#1
Lightbulb 
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?
Reply
Thanks given by:
#2
Maybe, but this would probably cause quite a bit of clutter to the chatbox. Maybe just standardise the colours?
Reply
Thanks given by: NiLSPACE
#3
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.
Reply
Thanks given by:
#4
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.
Reply
Thanks given by:
#5
(08-08-2013, 03:11 AM)tigerw Wrote: vanilla was white for a reason

The chats background is dark for a reason. Wink

tigerw Wrote:green against forest, or red against wool

I tried it and I can read it perfectly.
Reply
Thanks given by:
#6
(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. Wink

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.
Reply
Thanks given by:
#7
I have a proposal, too Smile

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");
Reply
Thanks given by: NiLSPACE
#8
Yep, makes sense. I might work on it in the morning.
Reply
Thanks given by:
#9
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.
Reply
Thanks given by:
#10
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().
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)