The most annoying aspect of playing team games for me is how the team messages from the console is outputted/spammed to the screen. The problem lies in that all the team players are competing to have their message advertised to teammates whilst each member is also attempting to read the messages previously and currently being sent. To me this is an exhausting process of multi-tasking and a highly inefficient use of time better spent focusing on actual gameplay. What I propose is when the team-match starts, the console display is divided into as many separate lines as there are teammates and each line is reserved solely for that teammate. To signal a new message being sent from a teammate a quick flash colored overlay could be highlighted over the visual console members line of text. For instance:

Team1-Reppie: Get Pent
Team1-Milton: Need RL
Team1-You: Got YA

This will organize team messages and will prevent the need to spam the same message repeatedly to get your message approprately noticed. Spam can also be further reduced if the last message sent is always onscreen until replaced by a new message. This feature could also be optionally enhanced by automatically always showing things like h, a, w, l, etc. which is updated separately in real-time from the say_team messages (which only gets updated when a new msg is sent.) An example:

Team1-Reppie(54/200)[RL]: Get Pent
Team1-Milton(26/89)[LG]: Need RL
Team1-You(100/150)[SG]: Got YA

There is a feature that already accomplishes giving an onscreen visual of h/a/w/l but combining the 2 features would allow the eye to only look to one area of the screen for such information so you don't have to waste time looking elsewhere. It would also be cool if a team-member was to get pent, text would show in red, quad in blue, eyes in yellow and combined powerups would blend those colors together.

I seriously believe that we would witness an unprecedented level of team play if such a feature was implemented because it would allow a greater accuracy of sending/receiving messages to teammates thus enabling more efficient use of time focusing on gameplay and less time spamming and deciphering messages.

You would lose all the history of messages though? You would also not get the messages combined with death messages in chronological order.

"Ake Vader rides RandomPlayer's rocket"
Ake: RA Lost

Would i have to use an extra bind saying "RL at RA" for that with your suggested method? (if not using MM3 that is)

Hmm, well my proposal is a little bit misleading when tying the "console" into it which I realized after posting. I visualized that the console could still be in service but overloaded when this feature is enabled to be restricted to 1 line of text to delay message outputs to approx 1 secs apart and to filter out say_team outputs on-screen, although when pulled down appear exactly as in it's usual form.
Example:

Console: Ake Vader rides RandomPlayer's rocket
Team1-Reppie: Get Pent
Team1-Milton: Need RL
Team1-Ake: Got YA

1-2 seconds later , "Console: "Ake Vader rides RandomPlayer's rocket",
Would change to read:
"Console: Ake: RA Lost"

I also imagined that the console when viewed by hitting tilde (default bind) would appear exactly as it does today, it is only the visual "on-screen display" that would change in format.

Although eliminating the console line is entirely possible whilst still displaying mm3, death msg's and the like so long as it is delayed properly.

Example:

Team1-Ake: Got YA
Would change to read:
Team1-Ake: Ake Vader rides RandomPlayer's rocket
1-2 sec later from last msg would change to read:
Team1-Ake: RA Lost
1-2 sec later from last msg would change to read:
Team1-Ake: RL at RA

Each change would be signaled by a colored overlay highlighted flash of your message so even tho the messages are changing quite rapidly, will be easy enough for your teammates to track in sequential order.

Keep in mind the on-screen feature would disappear when the console is pulled down and the console would appear exactly as it does today. When minimizing the console the feature would become active again and the visual format described would be returned. All console logging would still be in effect as it always was it is just the visual formatting and how that info is updated that would change.

Somewhat like that could be done with regexp triggers and hud elements.
It is often used in TF for showing flag status def status etc.

But as I know triggers are prohibited in tdm.

I don't think so. This is just a variant of scr_teaminfo. The proposal is to make a modified version of scr_teaminfo to be reformatted and include mm2/mm3 and death messages following the player names to be used in place of the in-game console display. mm1 could work in this format as well. If including a/h/s/l is overkill or considered non-permissive it would still be a great feature without it and greatly revolutionize team-play imo and there should be no ethical reason why it couldn't be implemented. All it would be doing is organizing the messages into a more readable and player-friendly format.

Honestly why do you care who says what? Isnt the only thing that matters what happens where and when?
Cause it doesnt matter to me if you or ake died, what matters is that we lost ra.
Really dont see the point in it.

well. It matters very much. Because you make decisions based on which team mate has quad, etc..

I don't understand the question or the point you were trying to make. This feature has nothing to do so much with who says what, it has to do with organizing the messages in a way that's much more readable and productive in a team-game, especially in a 4on4. I'm not too sure what you're trying to say but if you think this has to do with who says what then you need to re-read the posts or have a friend translate and help explain it to you. I apologize if it comes across as convoluted to you.

pracc moaaar!

btw..I like the idea! \o/ i would welcome it! I think it could help a lot to get faster and clear understanding of situations.

There are several stuff that wont work with that system, but really I dont mind if anyone else would use it as long as I dont have to.
But to illustrate some things that wont be fun, 1st it doesnt take time into account, so you wont be able to easily see the order of something happening, for example a take, lost, retake scenario on dm3 at ra.
One guy takes ra area, sends safe, so someone goes there, and the previous guy leaves, the guy who went there gets killed and sends lost, the first guy returns and retakes it sending safe. Now with a quick look this could look like one guy saying safe and one saying lost, thus you wont have any idea of what happend and if ra is safe or not.

2nd: dm3 again, pent spawns, fight, player a takes pent, and also picks up a rl pack, ofc sends both, rj through window, sends comming window, goes to quad on his way there he kills a lg, sends took lg then goes and takes quad, sends took quad, goes to ra so sends comming ra, takes ra, sends took ra, kills a guy with rl there as well so sends pack at ra and also throws in a ra safe. Now with that system good luck seeing all those messages.

Please solve these two problems with your system, with the current one there isnt a problem as it is all readable and you can see the order as well.

Hi zappater. I believe Ake Vader brought this point up already but perhaps my answer needs further explanation. I mentioned messages could be processed with a queue delay system like in this example:

Team1-Ake: Got YA
Would change to read:
Team1-Ake: Ake Vader rides RandomPlayer's rocket
1-2 sec later from last msg would change to read:
Team1-Ake: RA Lost
1-2 sec later from last msg would change to read:
Team1-Ake: RL at RA

As you see, time is being taken account, it's just processing the messages with a slight 1-2 sec delay in the order that it would have appeared in the console but there needs to be a delay in this proposal because there is only 1 line of text for each player. The console already processes messages in order that they are received and this system would be in no way deviating from that. So how is that any different from how messages are being read now? The 1-2 sec delay is relative to the time it might take you to read the messages anyway so you would likely notice no difference at all to interpreting the data other than I believe it would be much more organized and easier to follow in such a system.

I hope this explanation is sufficient for you but feel free to ask away if you are unclear about anything.

Jon Snow: Cool!

That could be easily achieved with some kind of aging messages, which slowly fade out, similar to r_tracker_frags.

Then we got the potential for the delay to build up to rather unpleasant amounts for someone that sends a lot of tp messages (like one every 2 seconds )

Yes, that is true, a message filter would have to be in place so that messages would be updated fast enough and not have too many pending messages.

Part of what this feature is designed to do is reduce spam and the need for it. It is possible that by overwhelming/abusing the system with tp messages, message data could be lost. Players will adjust to not hammering their tp binds since there would no longer be a need to do that for their messages to be clearly seen. I think ideally the message delay should be a cvar so players can set the rate to something that is comfortable to them that is perhaps defaulted to somewhere around 1 to 2 secs.

I put in a ezquake feature request which is largely just a copy/paste of what I wrote here. Here is a link to the request:
http://sourceforge.net/tracker/index.php?func=detail&aid=2534437&group_id=117445&atid=678562

If this is a feature you are interested in please show some interest by speaking up.

Just for the record I put in a ezquake feature request and johnnycz replied stating this feature will be considered a low priority unless people speak-up on this thread and show interest. So if you can see the value in this feature, let it be known

Perhaps a poll is the better way to go?

Yeah, do a poll and move this thread to Client Talk!

K, I put a poll up under the client section here:
http://www.quakeworld.nu/forum/viewpoll.php?id=3546