MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000845Zandronum[All Projects] Suggestionpublic2012-05-12 02:472018-09-30 21:35
Reporterlegion 
Assigned ToDusk 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version98d 
Target Version1.3Fixed in Version1.3 
Summary0000845: Forcing Enemy/Teammate Colors
DescriptionAs discussed here:'http://www.skulltag.com/forum/viewtopic.php?f=155&t=25520 [^]'

This would definitely be helpful towards competitive players, especially players like me who have some vision problems.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0001867closed Torr Samaho Setting skin via skininfo crashes zandronum 
has duplicate 0001552closed  Colors and more colors 
has duplicate 0001611closed  Force Player Color 
related to 0000872acknowledged  Force skins of enemies and allies 
Attached Filespng ZDaemon.png (315,574) 2012-09-10 19:06
/tracker/file_download.php?file_id=706&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-05-12 02:47legionNew Issue
2012-05-12 03:48almnNote Added: 0003617
2012-05-12 04:03TIHanNote Deleted: 0003617
2012-06-09 21:00FritsNote Added: 0003722
2012-06-09 21:02WartornNote Added: 0003723
2012-06-10 13:44DuskAssigned To => Dusk
2012-06-10 13:44DuskStatusnew => assigned
2012-06-10 16:00DuskNote Added: 0003734
2012-06-10 16:00DuskStatusassigned => needs review
2012-06-11 06:20FritsNote Added: 0003738
2012-06-11 08:51FritsNote Edited: 0003738bug_revision_view_page.php?bugnote_id=3738#r2059
2012-06-11 08:51FritsNote Edited: 0003738bug_revision_view_page.php?bugnote_id=3738#r2060
2012-06-11 11:12DuskRelationship addedrelated to 0000872
2012-06-13 02:38Parad0xNote Added: 0003753
2012-06-13 07:34ZzZomboNote Added: 0003756
2012-06-13 19:16FritsNote Added: 0003758
2012-06-13 22:20ZzZomboNote Added: 0003759
2012-09-10 12:02unknownnaNote Added: 0004634
2012-09-10 18:54DuskNote Added: 0004639
2012-09-10 19:05unknownnaNote Added: 0004640
2012-09-10 19:06unknownnaFile Added: ZDaemon.png
2012-09-10 19:07unknownnaNote Edited: 0004640bug_revision_view_page.php?bugnote_id=4640#r2504
2012-09-11 00:44DuskNote Added: 0004642
2012-09-11 18:18Torr SamahoNote Added: 0004646
2012-09-11 21:38DuskNote Added: 0004649
2012-09-11 22:19FritsNote Added: 0004650
2012-09-12 20:45Torr SamahoNote Added: 0004654
2012-09-12 21:42Edward-sanNote Added: 0004655
2012-09-13 00:07QentNote Added: 0004656
2012-09-13 00:08QentNote Edited: 0004656bug_revision_view_page.php?bugnote_id=4656#r2512
2012-09-16 03:26QentNote Edited: 0004656bug_revision_view_page.php?bugnote_id=4656#r2533
2012-09-16 10:14Torr SamahoNote Added: 0004687
2012-09-16 10:14Torr SamahoStatusneeds review => feedback
2012-09-16 11:26unknownnaNote Added: 0004694
2012-09-16 11:49Torr SamahoNote Added: 0004697
2012-09-16 13:11unknownnaNote Added: 0004703
2012-09-16 13:11unknownnaNote Edited: 0004703bug_revision_view_page.php?bugnote_id=4703#r2542
2012-09-16 13:19Torr SamahoNote Added: 0004705
2012-09-16 17:08QentNote Added: 0004709
2012-09-16 17:10QentNote Edited: 0004709bug_revision_view_page.php?bugnote_id=4709#r2554
2012-09-16 17:12QentNote Edited: 0004709bug_revision_view_page.php?bugnote_id=4709#r2555
2012-09-16 17:12QentNote Edited: 0004709bug_revision_view_page.php?bugnote_id=4709#r2556
2012-09-21 14:20FritsNote Added: 0004735
2013-03-14 16:37WatermelonNote Added: 0006124
2013-03-14 16:39WatermelonNote Edited: 0006124bug_revision_view_page.php?bugnote_id=6124#r3376
2013-03-14 16:39WatermelonNote Edited: 0006124bug_revision_view_page.php?bugnote_id=6124#r3377
2013-03-15 12:10DuskNote Added: 0006130
2013-08-01 14:18WatermelonNote Added: 0006881
2013-08-01 14:27DuskNote Edited: 0004639bug_revision_view_page.php?bugnote_id=4639#r3843
2013-08-01 14:27DuskNote Edited: 0003734bug_revision_view_page.php?bugnote_id=3734#r3845
2013-08-09 00:57legionNote Added: 0006951
2013-08-09 00:57legionStatusfeedback => assigned
2013-08-09 01:37ZzZomboNote Added: 0006952
2013-08-10 09:21Torr SamahoNote Added: 0006967
2013-10-21 03:03ArcoRelationship addedhas duplicate 0001552
2013-12-17 01:45DuskRelationship addedhas duplicate 0001611
2013-12-17 13:46Dark-AssassinNote Added: 0007702
2013-12-17 20:20legionNote Added: 0007703
2013-12-17 22:56CatastropheNote Added: 0007707
2014-03-09 21:12DuskNote Added: 0008376
2014-03-10 20:15Torr SamahoNote Added: 0008378
2014-03-10 20:16Torr SamahoNote Edited: 0008378
2014-03-10 20:16Torr SamahoNote Edited: 0008378bug_revision_view_page.php?bugnote_id=8378#r4570
2014-03-10 20:16Torr SamahoNote Revision Dropped: 8378: 0004568
2014-03-10 20:17Torr SamahoNote Revision Dropped: 8378: 0004569
2014-03-10 20:56DuskNote Added: 0008379
2014-03-10 21:04Torr SamahoNote Added: 0008380
2014-03-11 07:39Konar6Note Added: 0008383
2014-06-02 03:03WatermelonNote Added: 0008834
2014-06-02 03:04WatermelonNote Edited: 0008834bug_revision_view_page.php?bugnote_id=8834#r4783
2014-06-02 03:04WatermelonNote Edited: 0008834bug_revision_view_page.php?bugnote_id=8834#r4784
2014-06-02 03:07WatermelonNote Edited: 0008834bug_revision_view_page.php?bugnote_id=8834#r4785
2014-06-02 03:08WatermelonNote Edited: 0008834bug_revision_view_page.php?bugnote_id=8834#r4786
2014-06-02 03:08WatermelonNote Edited: 0008834bug_revision_view_page.php?bugnote_id=8834#r4787
2014-06-02 03:09WatermelonNote Edited: 0008834bug_revision_view_page.php?bugnote_id=8834#r4788
2014-06-02 04:26DuskNote Added: 0008836
2014-06-02 20:59WatermelonNote Added: 0008838
2014-06-04 04:57JKist3Note Added: 0008842
2014-06-04 18:38DuskNote Added: 0008846
2014-06-04 18:38DuskNote Edited: 0008846bug_revision_view_page.php?bugnote_id=8846#r4800
2014-06-04 18:40DuskNote Edited: 0008846bug_revision_view_page.php?bugnote_id=8846#r4801
2014-06-04 18:41DuskNote Edited: 0008846bug_revision_view_page.php?bugnote_id=8846#r4802
2014-06-04 18:57DuskNote Edited: 0008846bug_revision_view_page.php?bugnote_id=8846#r4803
2014-06-04 19:05DuskStatusassigned => needs review
2014-06-05 06:06Torr SamahoNote Added: 0008849
2014-06-05 06:08Torr SamahoNote Edited: 0008849
2014-06-05 06:09Torr SamahoNote Edited: 0008849bug_revision_view_page.php?bugnote_id=8849#r4807
2014-06-05 06:10Torr SamahoNote Revision Dropped: 8849: 0004805
2014-06-05 06:10Torr SamahoNote Revision Dropped: 8849: 0004806
2014-06-07 09:50Torr SamahoNote Added: 0008861
2014-06-07 09:54Torr SamahoNote Edited: 0008861bug_revision_view_page.php?bugnote_id=8861#r4813
2014-06-07 10:25Torr SamahoStatusneeds review => feedback
2014-06-07 10:43DuskNote Added: 0008863
2014-06-07 11:01Torr SamahoNote Added: 0008866
2014-06-07 12:46FritsNote Added: 0008868
2014-06-07 13:28Edward-sanNote Added: 0008869
2014-06-07 13:29Edward-sanNote Edited: 0008869bug_revision_view_page.php?bugnote_id=8869#r4817
2014-06-07 14:43Torr SamahoNote Added: 0008870
2014-06-08 01:20DuskNote Added: 0008897
2014-06-08 01:20DuskStatusfeedback => needs review
2014-06-08 07:34Torr SamahoNote Added: 0008901
2014-06-08 07:35Torr SamahoStatusneeds review => feedback
2014-06-08 09:53DuskStatusfeedback => assigned
2014-06-08 11:32DuskNote Added: 0008909
2014-06-08 11:32DuskStatusassigned => needs review
2014-06-08 12:08Torr SamahoNote Added: 0008911
2014-06-08 12:08Torr SamahoStatusneeds review => needs testing
2014-06-08 12:08Torr SamahoTarget Version => 1.3
2014-06-09 17:58ArcoNote Added: 0008972
2014-06-09 20:41Torr SamahoNote Added: 0008974
2014-07-05 09:56Torr SamahoNote Added: 0009841
2014-07-05 17:18Torr SamahoNote Edited: 0009841bug_revision_view_page.php?bugnote_id=9841#r5272
2014-07-05 17:19Torr SamahoNote Revision Dropped: 9841: 0005271
2014-07-05 19:58DuskRelationship addedparent of 0001867
2014-07-09 16:12ArcoNote Added: 0009919
2014-07-09 16:12ArcoStatusneeds testing => assigned
2014-07-24 03:03unknownnaNote Added: 0010052
2014-07-24 03:04unknownnaNote Edited: 0010052bug_revision_view_page.php?bugnote_id=10052#r5400
2014-07-24 03:30unknownnaNote Edited: 0004694bug_revision_view_page.php?bugnote_id=4694#r5402
2014-07-24 03:31unknownnaNote Edited: 0010052bug_revision_view_page.php?bugnote_id=10052#r5403
2014-08-14 15:07LeonardNote Added: 0010203
2014-09-29 09:35DuskNote Added: 0010306
2014-09-29 22:55DuskStatusassigned => needs review
2014-10-03 16:32Torr SamahoNote Added: 0010316
2014-10-03 19:14DuskNote Added: 0010322
2014-10-05 17:17cobaltStatusneeds review => needs testing
2014-10-05 17:17cobaltDescription Updatedbug_revision_view_page.php?rev_id=5602#r5602
2014-10-05 17:17cobaltNote Added: 0010335
2014-10-05 20:03ArcoNote Added: 0010340
2014-10-05 20:03ArcoStatusneeds testing => feedback
2014-10-05 20:03ArcoDescription Updatedbug_revision_view_page.php?rev_id=5604#r5604
2014-10-06 01:32DuskNote Added: 0010360
2014-10-06 01:32DuskStatusfeedback => resolved
2014-10-06 01:32DuskFixed in Version => 1.3
2014-10-06 01:32DuskResolutionopen => fixed
2018-09-30 21:35Blzut3Statusresolved => closed

Notes
(0003722)
Frits   
2012-06-09 21:00   
Giving my strong support.
(0003723)
Wartorn   
2012-06-09 21:02   
Since the support buttons are broken for some reason on my end, I'll say it here: I support this.
(0003734)
Dusk   
2012-06-10 16:00   
(edited on: 2013-08-01 14:27)
A fun little challenge it was :P

'https://bitbucket.org/slatenails/neurosphere/changeset/ae17d910e31d [^]'
(0003738)
Frits   
2012-06-11 06:20   
(edited on: 2012-06-11 08:51)
Really epic stuff there!
Please include this into zandronum.
(0003753)
Parad0x   
2012-06-13 02:38   
This is really needed in some server, strong support.
(0003756)
ZzZombo   
2012-06-13 07:34   
The old forum isn't working either, so I ask to say what is the reasons to do it?
(0003758)
Frits   
2012-06-13 19:16   
Competitive gaming ZzZombo. Forcing colors makes sure one team doesn't have a color advantage.
(0003759)
ZzZombo   
2012-06-13 22:20   
Ok.
(0004634)
unknownna   
2012-09-10 12:02   
Yes, this is a very important feature for competitive players.
(0004639)
Dusk   
2012-09-10 18:54   
(edited on: 2013-08-01 14:27)
Since this got bumped, I transplanted this to a new head:
'https://bitbucket.org/slatenails/neurosphere/changeset/cc0f9bc9badee0d91f0f9660887bbe4bac36c5af [^]'
Changed style a bit and added changelog entry.
(0004640)
unknownna   
2012-09-10 19:05   
(edited on: 2012-09-10 19:07)
Great work, Dusk. How will sv_maxteams 3+ be handled? Will all the enemy teams share the same color? Could we have menu sliders in the future? ZDaemon has menu sliders.
(0004642)
Dusk   
2012-09-11 00:44   
> How will sv_maxteams 3+ be handled?
By the logic, all enemy teams share the same color because they're - well - enemies.

> Could we have menu sliders in the future? ZDaemon has menu sliders.
I'm unfamiliar with this but I could try..
(0004646)
Torr Samaho   
2012-09-11 18:18   
All player of all opposing teams are forced to the same color? That means this feature is of very limited use if there are three or more teams. IMHO this definitely should be resolved before we think about adding this to Zandronum.
(0004649)
Dusk   
2012-09-11 21:38   
Anyone got ideas on how this should be handled?
(0004650)
Frits   
2012-09-11 22:19   
Cl_enemycolor2 and 3? 2 being used for the third team , 3 being used for the fourth team ? :p
(0004654)
Torr Samaho   
2012-09-12 20:45   
Since the hard coded maximum of teams is 4 this should be sufficient.
(0004655)
Edward-san   
2012-09-12 21:42   
is it possible for a command to accept two parameters? Like:

cl_enemycolor %selectedcolor% %teamid%
(0004656)
Qent   
2012-09-13 00:07   
(edited on: 2012-09-16 03:26)
How will it work for non-team games?

Edward-san, I think so, but here it would make it awkward to read back the color you set.

EDIT: So I think it could work as 5 CVars: cl_enemycolor (no teams), cl_enemycolor0-3 (teams), and cl_useenemycolor (to enable/disable).
(0004687)
Torr Samaho   
2012-09-16 10:14   
Does "cl_enemycolor (no teams)" mean you propose to let the players override the other players' colors in non-coop non-team games? I think this feature should be restricted to team games. In non-team games the color doesn't give you an advantage since every player can change his color freely.
(0004694)
unknownna   
2012-09-16 11:26   
(edited on: 2014-07-24 03:30)
Quote from Torr Samaho
I think this feature should be restricted to team games. In non-team games the color doesn't give you an advantage since every player can change his color freely.

I respectfully disagree. For instance, what if you're playing on an ice-themed map (white, light blue colors) and the enemy changes his/her color to blend in with the color scheme? With cl_enemycolor, you'll be able to set a color that makes it easier to see the enemy.

For multi-team games (sv_maxteams 3/4), I'd rather have all the enemy teams share the same color since it would make it easier to distinguish between enemies and allies in the heat of battle.
(0004697)
Torr Samaho   
2012-09-16 11:49   
Quote from unknownna

I respectfully disagree. For instance, what if you're playing on an ice-themed map (white, light blue colors) and the enemy changes his/her color to blend in with the color scheme?
Since every player is free to do the same, I don't see a problem with this. If you are willing to do spend the extra effort to chose the color in an advantageous way, why should you prevent the players from doing so? We don't forbid SR50 because it's complicated to use either.

This is very different in team games, where you cannot adjust the color to map the match.
(0004703)
unknownna   
2012-09-16 13:11   
Quote from Torr Samaho
If you are willing to do spend the extra effort to chose the color in an advantageous way, why should you prevent the players from doing so?

To level out the playing field by *modern* competitive standards.

Quote from Torr Samaho
We don't forbid SR50 because it's complicated to use either.

IIRC, they allow people to use custom enemy/team colors/models (even bright skins) in Quake Live, but they still don't prevent people from utilizing strafe-jumping, the SR50 of Quake.
(0004705)
Torr Samaho   
2012-09-16 13:19   
Quote from unknownna
To level out the playing field by *modern* competitive standards.
You are not making things more fair here, in non-team games the playing-field already is leveled out in this regard. You are just taking away possibilities from the players.
(0004709)
Qent   
2012-09-16 17:08   
(edited on: 2012-09-16 17:12)
Oh I see; I had thought that this ticket was primarily for non-team games, and secondarily for teams. (The default team colors are rather bright and easy to see, IMHO.)

My view is that changing colors is used mainly for personalization, and I don't like having to alter my color just to even the playing field. However, given that I *do* like using colors for personalization, I would only force (non-team) enemy colors maybe once in a blue moon (like when he's a black Strife Guy on a SpaceDM5 map). There's only one person in the community who changes color for camouflage, anyway. :P
(0004735)
Frits   
2012-09-21 14:20   
I don't see the problem with this and non-team games. On DM for instance everyone should be forced to your set enemycolor.
(0006124)
Watermelon   
2013-03-14 16:37   
(edited on: 2013-03-14 16:39)
How difficult would it be to add in support for 3 other teams? Most people tend to use it just for ally/enemy differentiation.

If we wanted to do upto n teams:

cl_teamcolors "hex of friendly;hex of enemy team (1);hex of enemy team (...n)"

example:
cl_teamcolors "" // Everyone is their normal color

cl_teamcolors "00FF00" // First parameter is friendlies, so they will always be green, all enemy teams are their normal color

cl_teamcolors "00FF00;FF0000" // Friendlies green, enemies red for all teams

cl_teamcolors "00FF00;FF0000;0000FF" // Friendlies green, lowest team number that is not your team is red, the rest are blue if there are 4 teams, or the remaining team is blue if there is 3

cl_teamcolors "00FF00;FF0000;0000FF;FFFFFF" // Friendlies green, pattern follows as previously shown


This method of doing that supports up to n teams in the future should more than 4 be implemented. If there is only 3 colors specified when there is >3 teams, then all the remaining teams will be filled with the last color


That's one way to do it if we ever plan on expanding past 4 teams. In addition, that will solve the error of making sure your allies are always the first color.



The reason this method works, is lets say you have something hardcoded like cl_enemyteam1 red and cl_enemyteam2 blue: if you change teams, then your enemy will change color based on your team which defeats the original purpose of this. The goal is to specify enemy colors no matter what team you're on.
(0006130)
Dusk   
2013-03-15 12:10   
IIRC it was desired that all enemies appear red and all allies appear green, regardless of team status.
(0006881)
Watermelon   
2013-08-01 14:18   
I've implemented this into a custom build and played with some friends w/ it, so far it was awesome and people want to see this in.
(0006951)
legion   
2013-08-09 00:57   
bump, pls indicate if this will be implemented or not
(0006952)
ZzZombo   
2013-08-09 01:37   
We need a way for a team to retain its predefined team color. Like -1 or "DEFAULT" or like that.
(0006967)
Torr Samaho   
2013-08-10 09:21   
Quote from Watermelon
I've implemented this into a custom build and played with some friends w/ it, so far it was awesome and people want to see this in.

How did you handle more than two teams?

Quote from legion
bump, pls indicate if this will be implemented or not
Although I personally still think that it's not necessary in non-team modes since everybody is free to change their color, I'd be fine with having this in as long as we have proper support for 4 teams.
(0007702)
Dark-Assassin   
2013-12-17 13:46   
I personally think that this does not need team support. Each team already has a forced color assigned to them. (announcer sounds would get confusing)
For non team and non coop, like deathmatch and lms, I agree and it could be helpful (camo people). But probably have restricted colors.
It doesn't need to be so technical and advanced just to see your foes wearing the same color.
Most Stratergy games have Friend or Foe colors, and the enemy is just Red while allies are just green. No need for them to be rainbow (alias loops) or a bright or dark color.
(0007703)
legion   
2013-12-17 20:20   
why doesn't this need team support? it could really help on maps which have been decorated to be nearly the same color as their default color.

for team games, its useful to easily differentiate friends (for example, your team is colored white instead of red OR blue) and enemies (you color all enemies black instead of red OR blue)

for non-team games, its also very useful because some highly competitive players try and play the map instead of focusing on gameplay, which is taking advantage of trivial things just to gain an advantage.

with regards to more than 2 teams: unnecessary to even think about having to do anything with that. you don't NEED color differentiation between teams since all of them are enemies (except your own team). PLUS: it would help prevent teams working together to take down another team (colluding)
(0007707)
Catastrophe   
2013-12-17 22:56   
Agreed, support for multiple teams is unnecessary since 3-way or 4-way wads are rarely played anymore aside from occasional FNF games (which are non-competitive on its' own). People will be really happy even if it is just for two players, and honestly it's at the point where players are willing to wait a version or two for multiple team support later.
(0008376)
Dusk   
2014-03-09 21:12   
Quote

[09-03-14 23:07:26] <Dusk> it does support multiple teams
[09-03-14 23:07:35] <Dusk> it does exactly what the reporter and others requested
[09-03-14 23:07:40] <Dusk> ally color and enemy color
[09-03-14 23:08:06] <Dusk> i in fact discussed about it on irc and the multi-team coloration thing wasn't much of a problem
[09-03-14 23:08:22] <Dusk> because 1) games with more than 2 teams are *very rare*
[09-03-14 23:08:31] <Dusk> like only fnf hosts them really
[09-03-14 23:08:47] <Dusk> and 2) even in 3-way tdm or ctf it doesn't really matter what color the enemy player is
[09-03-14 23:08:57] <Dusk> it's an enemy so it should be colored with cl_enemycolor
[09-03-14 23:09:17] <Dusk> however i think the cvar names should be r_ since it's a renderer thing?
[09-03-14 23:09:44] <Dusk> it's a matter of player translations


If you're fine with this I'll get a proper pull request together.
(0008378)
Torr Samaho   
2014-03-10 20:15   
(edited on: 2014-03-10 20:16)
IMHO it's mandatory that a player can distinguish opposing teams with the default settings if there are more than 2 teams. Also activating this feature for two teams should not automatically activate it for 3+ teams. Possibly the easiest solution is just to disable the feature completely if 3 or more teams are available. If such games are as rare as you say, it won't matter if it's just automatically deactivated anyway.

EDIT: Since this is a typical client option I'd preface the cvars with "cl_".
(0008379)
Dusk   
2014-03-10 20:56   
Wait, we seem to have a misunderstanding here. This is an opt-in CVAR, not default behavior. So in 3/4-way team scenario you still can obviously distinguish opposing teams with default settings.
(0008380)
Torr Samaho   
2014-03-10 21:04   
Let me clarify: I expect many people to opt-in for this feature and use it for team games with two teams or plain FFA. But I don't want that this opt-in will automatically deprive them of their ability to distinguish opposing teams in a 3+ teams environment, since it cannot be expected that they are aware what the opt-in will deprive them of.
(0008383)
Konar6   
2014-03-11 07:39   
I agree with Dusk here. AFAIK it's how ZDaemon works too (can someone check?). An enemy is an enemy and their real team color is irrelevant.
All what we need is one CVAR to enable/disable the feature, and 2 CVARs for setting ally/enemy colors.
(0008834)
Watermelon   
2014-06-02 03:03   
(edited on: 2014-06-02 03:09)
Quote
But I don't want that this opt-in will automatically deprive them of their ability to distinguish opposing teams in a 3+ teams environment, since it cannot be expected that they are aware what the opt-in will deprive them of.


I don't know if there's any way to handle this except what I'm about to propose, because of how teams work (digits rather than names)

The only solution would be the color code with a delimiter inside:
cl_enemycolor "<team 1 hex>; <team 2 hex>; <team 3 hex>; <team 4 hex>"


This way if it detects no delimiter, it forces it for everyone like ZDaemon and Odamex do -- if it detects a delimiter, then it applies all the values to the teams (and uses the last value for the rest) -- if it's an empty string it should default to black or something.


===================================================================
Win win for both worlds.

[*]People get their override for everyone if there's no delimiter
cl_enemycolor "00 00 FF"
// Make all players blue

cl_enemycolor "00 00 FF;"
// Make all players blue since it reads one delimiter for team one, but fills in the rest according to the last color which is blue

[*]People get the ability to set all the teams
cl_enemycolor "00 00 FF; 00 FF 00; FF 00 00; FF FF FF"
// Make team 1 blue, team 2 green, team 3 red, team 4 white

[*]Extendable easily so if we upgrade to more than 4 teams we can easily do it without having to do cl_enemyteam_x ... (which could get big)
cl_enemycolor "00 00 FF; 00 FF 00; FF 00 00; FF FF FF"
// Like our last example, if we suddenly change MAX_TEAMS to 8, then this would make teams 3 - 7 all white, we have forwards compatibility



Thoughts?
This is epic forwards compatibility (!)
(0008836)
Dusk   
2014-06-02 04:26   
I'm not going to be coding that.
(0008838)
Watermelon   
2014-06-02 20:59   
I don't mind adding it in if it's possible. Its the only thing that can match what Torr has requested.
(0008842)
JKist3   
2014-06-04 04:57   
This feature is a must for high level competition, so I'm eager to see some form of it get included.

A further suggestion: In addition to being able to set enemy color, fullbrights should also be a choice. For those unfamiliar with them they are common options in other competitive fps games. Here is an example:'http://i.imgur.com/Z9NWa.jpg [^]'

Also being able to have the edges of the player's hitbox outlined around their sprite would be a killer feature as well.
(0008846)
Dusk   
2014-06-04 18:38   
(edited on: 2014-06-04 18:57)
copied the commit from my neurosphere fork and reworked on it further:
-'https://bitbucket.org/CrimsonDusk/zandronum-stable/commits/1bfd6bec3fff882dcede9c742fa8fe82ae8bc774 [^]'
-'https://bitbucket.org/CrimsonDusk/zandronum-stable/commits/eac1e3d0a8c95046a64d01683c06e271a494887c [^]'


Changes done:
- now properly works offline
- defaults of allycolor and enemycolor changed to white and black, red and green would be confusing when the local player is on the red team (and thus would see the blue team as red)
- color reverts to non-overridden color when the player dies. If the color would stick around, it wouldn't be updated after the player updates cl_overrideplayercolors/cl_allycolor/cl_enemycolor, spectates or changes to the enemy team and that could be mega confusing. The simple solution was to just make corpses appear non-overridden.

The more I work on this feature the stronger I feel that all enemy players should appear in cl_enemycolor no matter what team they are in. They are enemies, they should use the enemy color. The only compromise I see is making this (or at least cl_enemycolor) no-op in games using more than 2 teams.

EDIT:
That is done now:
'https://bitbucket.org/CrimsonDusk/zandronum-stable/commits/d4df3828884eacfc941df27ae2888a6c7adc37f5 [^]'
(0008849)
Torr Samaho   
2014-06-05 06:06   
(edited on: 2014-06-05 06:09)
Quote from Dusk
The only compromise I see is making this (or at least cl_enemycolor) no-op in games using more than 2 teams.

That's a compromise I can live with (and actually what I already suggested, see 0000845:0008378). I'll look at your combined patches in detail later.
(0008861)
Torr Samaho   
2014-06-07 09:50   
(edited on: 2014-06-07 09:54)
From your comments it sounds as if the color of a player reverts back to its non-overridden color if that player dies and turns into a corpse. Is that correct? That sounds not very visually appealing...

EDIT: G_QueueBody uses TRANSLATION_PlayerCorpses to make the translation of a corpse independent from the translation of the player to prevent these kind of effects.
(0008863)
Dusk   
2014-06-07 10:43   
Quote
That sounds not very visually appealing...

If they wouldn't revert back, they would keep whatever color they had after they die. And this means that if you for instance spectate, change teams, change coop spy target etc which changes the colors of everybody alive doesn't update those who are already dead. I think that's a problem and solved it by simply making them revert upon death. It's less bad than the alternative IMO.
(0008866)
Torr Samaho   
2014-06-07 11:01   
A player observes how another player dies far more often than a player switches teams or turns into a spectator. I personally would strongly prefer if common events are displayed properly instead of tuning the system to much rarer events.

What is the general opinion on this?
(0008868)
Frits   
2014-06-07 12:46   
I'm in favor of Torr's suggestion.
It's imho less noticable that the color of old corpes don't match up than having them change back to red/blue/green/gold. Especially because teamswitches mid game are rare.
Plus corpses in pvp serve no purpose other than aesthetics anyway.
(0008869)
Edward-san   
2014-06-07 13:28   
(edited on: 2014-06-07 13:29)
I suggest to leave the death scene with the same color as his team, then after some seconds, it reverts back to its non-overridden color by fading... it would be more appealing imo.
(0008870)
Torr Samaho   
2014-06-07 14:43   
Quote from Edward-san
then after some seconds, it reverts back to its non-overridden color by fading...

That's more work for a very small effect. The current behavior we inherited from ZDoom is simple and consistent: A corpse copies the color of the player at the moment of the player's death and then keeps this color, no matter what happens to the color of the player later. That's how it has been for ages, so everybody is used to it. Why break with it?
(0008897)
Dusk   
2014-06-08 01:20   
I removed the translation reverting. Finalized the patch, tested offline and online with 2 clients on deathmatch and team dm.

'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/41 [^]'
(0008901)
Torr Samaho   
2014-06-08 07:34   
Looks pretty good now! Two minor technical things:

- instead of putting EXTERN_CVAR( Bool, cl_overrideplayercolors ) into numerous .cpp files, one should put this into a single header, e.g. cl_main.h
- the ( NETWORK_GetState() != NETSTATE_SERVER ) check in client_SpawnPlayer is superfluous. All client_* functions don't make sense when called on the server and don't have any of these server checks

If you'd like me to, I can take care of these myself and amend the commit after transplanting it. If you prefer to change this yourself, that's fine too.
(0008909)
Dusk   
2014-06-08 11:32   
My internet connection went down for a little while, sent a pull request now
'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/42 [^]'
(0008911)
Torr Samaho   
2014-06-08 12:08   
Great! I transplanted your patch to the head.
(0008972)
Arco   
2014-06-09 17:58   
Cl_overrideplayercolors 1 appears to crash whenever I change maps.

'https://www.dropbox.com/s/p29vdy4dndhn4fs/CrashReport_cl_ov.zip [^]'
(0008974)
Torr Samaho   
2014-06-09 20:41   
Does the crash only happen in 2.0 or also in 1.3?
(0009841)
Torr Samaho   
2014-07-05 09:56   
(edited on: 2014-07-05 17:18)
The latest 2.0 version should fix the crashes (they were related to the addition of colorset). The overrides seems to stop working in single player after a map change though. This still needs to be taken care of.
(0009919)
Arco   
2014-07-09 16:12   
The mugshot background for the HUD is inconsistent with the color of the team, and it will remain so until you die. This happens in both 1.3 and 2.0.
(0010052)
unknownna   
2014-07-24 03:03   
(edited on: 2014-07-24 03:31)
Quote from Torr Samaho
Possibly the easiest solution is just to disable the feature completely if 3 or more teams are available. If such games are as rare as you say, it won't matter if it's just automatically deactivated anyway.

I disagree. See below.

Quote from Torr Samaho
But I don't want that this opt-in will automatically deprive them of their ability to distinguish opposing teams in a 3+ teams environment, since it cannot be expected that they are aware what the opt-in will deprive them of.

I'm pretty sure that when most people set cl_enemycolor they fully expect all opposing teams and players to share the same color. You're seeing it from the wrong perspective. Less is more here. I just tested ZDaemon and it works like this there (tested with bots):

* All opposing teams share the same color.
* You can enable the feature in several ways:
     - always
     - DM
     - team modes
     - non-team modes
     - never
* Corpses are also overridden and even update their colors if you change the ally/enemy color (teammate_color and enemy_color, respectively).
* Your own corpse is never overridden for some reason (might be a bug).
* Nothing is overridden until you join the game.
* When joining the game all player and corpse colors are overridden.
* HUD statusbar uses real team colors instead of teammate_color.
* When changing teams all player and corpse colors are overidden. So the corpse of a former orange enemy might now have the color of a blue ally.
(0010203)
Leonard   
2014-08-14 15:07   
Yes, ZDaemon was pretty much the way to go imo..
The ability to enable/disable it for (non-)team modes seems very interesting.
Personally I only want this in non-team modes because, you know, teams already have a specific color.
(0010306)
Dusk   
2014-09-29 09:35   
Taking this up for rework. Doing the following:

- adding a menu option for the feature in the multiplayer menu, will add a switch with values: 'always', 'up to 2 teams only', 'non-team modes only', 'never'. Defaults to 'never'.
- as a result of the above change, will be making it work with 3-way and 4-way games again. the user now has a clear
- fixing the issue with the status bar not updating. Will try to make it use the real team color, no promises
- corpse colors will not be overridden. Once a player dies and subsequently respawns, the corpse will no longer be a player and there's no way to override afterwards, so yeah.

Quote
The overrides seems to stop working in single player after a map change though. This still needs to be taken care of.

Will try to fix this.
(0010316)
Torr Samaho   
2014-10-03 16:32   
How thoroughly did you test your pull request? Are you sure that you want it to be pulled now, i.e. right before the release of 1.3?
(0010322)
Dusk   
2014-10-03 19:14   
I could only test it offline, though I think it could be tested considering how many people appear to want this feature. Though someone will have to make a build for testing.
(0010335)
cobalt   
2014-10-05 17:17   
Issue addressed by commit bd8b4407112a: - reworked player color overriding, fixes 845. mugshot is now updated correctly and should work properly offline now. Turned from a flag to an int of 4 values, always, 2-teams max, ffa and never.
Committed by Teemu Piippo [Dusk] on Sunday 05 October 2014 20:01:02

7 files modified, 120 lines added, 49 lines removed
Files changed: src/cl_main.cpp, src/d_netinf.h, src/d_netinfo.cpp, src/g_game.cpp, src/m_options.cpp, src/p_interaction.cpp, src/p_mobj.cpp
(0010340)
Arco   
2014-10-05 20:03   
The "FFA only" selection for teamcolors appears to effect cooperative.
(0010360)
Dusk   
2014-10-06 01:32   
That is by intention - but the wording could use some rework. But right now anything other than "FFA" doesn't fit the menu, so this is something to address for 2.0.