0000092: announcer says "<3, 2, 1> frag(s) left." for each individual player

Notes
(0000303) user35 2010-10-10 06:30 edited on: 2010-10-10 06:30	wow, I like the ideea! its meant to be exactly like in Quake 3

(0000305) Torr Samaho (administrator) 2010-10-10 07:29	For me each of the "x frags left" announcers is only played once (and not once per player). Did you turn cl_alwaysplayfragsleft to true? In this case, the announcers are played always.

(0000309) unknownna (updater) 2010-10-10 07:59	I see. It was set to true for some reason, but I found another issue. When the frag limit is set to 4 and one player reach 3 frags, then suicides back to 0. When either one of the players frag the other, no announcement is made other than "You are tied for the lead./You've lost the lead./You've taken the lead.". However, if one of them then reconnects, the announcer plays properly again for the reconnected client.

(0000312) Torr Samaho (administrator) 2010-10-10 08:46	That's the intended behavior. Each client is only supposed to hear the announcer once. Whether or not the current behavior is "optimal" is debatable of course, but I think it's fine.

(0000313) unknownna (updater) 2010-10-10 08:53	I don't know. It somewhat feels like a bug, since you can reconnect to make it work "optimally" again. Because, even if the player suicides back to 0 frags, there still are x frags left to win the game, but no announcement is made. If you want it to work as it currently does, clients must not be able to change the behavior each time they reconnect. What do you think about this, FistMarine?

(0000314) Torr Samaho (administrator) 2010-10-10 09:56	If you reconnect, you are intentionally treated as new client and thus hear the announcers again (but only once). IMHO if you announce "x frags left" more than once in your scenario, you'd also need to announce "more than three frags left" (which is not going to happen). Otherwise, the players are probably confused when they hear "x frags left" more than once.

(0000318) unknownna (updater) 2010-10-10 11:04	I don't see why you'd need to announce "more than three frags left". Every time you'd hear "3 frags left" you'd know that someone had reached the threshold. The next one triggering "3 frags left" would alarm the other players again, for then they'd know that someone reached the threshold. If the one who triggers "3 frags left" suicides or kills himself/herself by accident, the announcer doesn't say anything. If the one who triggers "2 frags left" does the same, the announcer will say "3 frags left". If the one who triggers "1 frag left" also does the same, the announcer will say "2 frags left". And should a client with 23 frags frag another one with 24 frags, and the frag limit is set to 25 (1 frag left), the announcer will not say "1 frag left" again, as the one who frags the one with the higher frag count takes the position. Basically, the request is to make the announcer dynamic. Are there any problems with having a dynamic announcer? If so, please correct me. But if the current behavior is working as intended, I suppose that it doesn't need to change.

(0000320) Torr Samaho (administrator) 2010-10-10 11:46	IIRC SuperGod explicitly requested the "x frags left" announcer to be only played once each, because he didn't like to hear them more than once. I see merit in both approaches and think that the current behavior is neither better nor worse than the one you requested, it's just different. IMHO the issue is too minor though to create another CVAR to configure this (there already is cl_alwaysplayfragsleft if you don't like the default behavior). If a lot of people want to have this handled differently, I could add something like cl_playfragsleftmultipletimes though.

(0002595) Torr Samaho (administrator) 2012-02-12 17:50	Since nobody commented on the cl_playfragsleftmultipletimes idea in more than a year, I assume that there is not enough demand for this and close the issue.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2010-10-10 05:43	unknownna	New Issue
2010-10-10 06:30	user35	Note Added: 0000303
2010-10-10 06:30	user35	Note Edited: 0000303	View Revisions
2010-10-10 07:29	Torr Samaho	Note Added: 0000305
2010-10-10 07:29	Torr Samaho	Status	new => feedback
2010-10-10 07:59	unknownna	Note Added: 0000309
2010-10-10 07:59	unknownna	Status	feedback => new
2010-10-10 08:46	Torr Samaho	Note Added: 0000312
2010-10-10 08:46	Torr Samaho	Status	new => feedback
2010-10-10 08:53	unknownna	Note Added: 0000313
2010-10-10 08:53	unknownna	Status	feedback => new
2010-10-10 09:56	Torr Samaho	Note Added: 0000314
2010-10-10 09:56	Torr Samaho	Assigned To	=> Torr Samaho
2010-10-10 09:56	Torr Samaho	Status	new => feedback
2010-10-10 11:04	unknownna	Note Added: 0000318
2010-10-10 11:04	unknownna	Status	feedback => assigned
2010-10-10 11:46	Torr Samaho	Note Added: 0000320
2010-10-10 11:46	Torr Samaho	Assigned To	Torr Samaho =>
2010-10-10 11:46	Torr Samaho	Status	assigned => feedback
2012-02-12 17:50	Torr Samaho	Note Added: 0002595
2012-02-12 17:50	Torr Samaho	Status	feedback => closed
2012-02-12 17:50	Torr Samaho	Resolution	open => denied
2012-06-09 13:22	Torr Samaho	Category	General => Bug

Relationships