| 
		
	
	
	
		
	Posts: 954 
	Threads: 16 
	Joined: May 2013
	
 Thanks: 68Given 112 thank(s) in 93 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: 66Given 133 thank(s) in 112 post(s)
 
 
	
	
		Maybe, but this would probably cause quite a bit of clutter to the chatbox. Maybe just standardise the colours?
	 
	
	
	
		
	Posts: 4,637 
	Threads: 115 
	Joined: Dec 2011
	
 Thanks: 697Given 518 thank(s) in 441 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: 954 
	Threads: 16 
	Joined: May 2013
	
 Thanks: 68Given 112 thank(s) in 93 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,637 
	Threads: 115 
	Joined: Dec 2011
	
 Thanks: 697Given 518 thank(s) in 441 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: 954 
	Threads: 16 
	Joined: May 2013
	
 Thanks: 68Given 112 thank(s) in 93 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,482 
	Threads: 176 
	Joined: Jan 2012
	
 Thanks: 131Given 1085 thank(s) in 857 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: 66Given 133 thank(s) in 112 post(s)
 
 
	
	
		Yep, makes sense. I might work on it in the morning.
	 
	
	
	
		
	Posts: 6,482 
	Threads: 176 
	Joined: Jan 2012
	
 Thanks: 131Given 1085 thank(s) in 857 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,482 
	Threads: 176 
	Joined: Jan 2012
	
 Thanks: 131Given 1085 thank(s) in 857 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().
 |