0000845: Forcing Enemy/Teammate Colors

(0003722)
Frits (reporter)
2012-06-09 21:00

Giving my strong support.

(0003723)
Wartorn (reporter)
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 (developer)
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 (reporter)
2012-06-11 06:20
edited on: 2012-06-11 08:51

Really epic stuff there!
Please include this into zandronum.

(0003753)
Parad0x (reporter)
2012-06-13 02:38

This is really needed in some server, strong support.

(0003756)
ZzZombo (reporter)
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 (reporter)
2012-06-13 19:16

Competitive gaming ZzZombo. Forcing colors makes sure one team doesn't have a color advantage.

(0003759)
ZzZombo (reporter)
2012-06-13 22:20

Ok.

(0004634)
unknownna (updater)
2012-09-10 12:02

Yes, this is a very important feature for competitive players.

(0004639)
Dusk (developer)
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 (updater)
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 (developer)
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 (administrator)
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 (developer)
2012-09-11 21:38

Anyone got ideas on how this should be handled?

(0004650)
Frits (reporter)
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 (administrator)
2012-09-12 20:45

Since the hard coded maximum of teams is 4 this should be sufficient.

(0004655)
Edward-san (developer)
2012-09-12 21:42

is it possible for a command to accept two parameters? Like:

cl_enemycolor %selectedcolor% %teamid%

(0004656)
Qent (updater)
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 (administrator)
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 (updater)
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 (administrator)
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 (updater)
2012-09-16 13:11
edited on: 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 (administrator)
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 (updater)
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 (reporter)
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 (developer)
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 (developer)
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 (developer)
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 (reporter)
2013-08-09 00:57

bump, pls indicate if this will be implemented or not

(0006952)
ZzZombo (reporter)
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 (administrator)
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 (administrator)
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 (reporter)
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 (reporter)
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 (developer)
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 (administrator)
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 (developer)
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 (administrator)
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 (reporter)
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 (developer)
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 (developer)
2014-06-02 04:26

I'm not going to be coding that.

(0008838)
Watermelon (developer)
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 (reporter)
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 (developer)
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 (administrator)
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 (administrator)
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 (developer)
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 (administrator)
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 (reporter)
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 (developer)
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 (administrator)
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 (developer)
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 (administrator)
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 (developer)
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 (administrator)
2014-06-08 12:08

Great! I transplanted your patch to the head.

(0008972)
Arco (updater)
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 (administrator)
2014-06-09 20:41

Does the crash only happen in 2.0 or also in 1.3?

(0009841)
Torr Samaho (administrator)
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 (updater)
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 (updater)
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 (developer)
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 (developer)
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 (administrator)
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 (developer)
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 (updater)
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 (updater)
2014-10-05 20:03

The "FFA only" selection for teamcolors appears to effect cooperative.

(0010360)
Dusk (developer)
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.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	Minigunner Frits Parad0x Devon katZune DartPower unknownna ZzZombo fuleco someoneelse legion Yellowtail Argentum Soul Medicris Chronos Ouroboros Esum Ru5tK1ng Tux Leonard WaTaKiD JKist3 Monsterovich rosking swordgrunt
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2012-05-12 02:47	legion	New Issue
2012-05-12 03:48	almn	Note Added: 0003617
2012-05-12 04:03	TIHan	Note Deleted: 0003617
2012-06-09 21:00	Frits	Note Added: 0003722
2012-06-09 21:02	Wartorn	Note Added: 0003723
2012-06-10 13:44	Dusk	Assigned To	=> Dusk
2012-06-10 13:44	Dusk	Status	new => assigned
2012-06-10 16:00	Dusk	Note Added: 0003734
2012-06-10 16:00	Dusk	Status	assigned => needs review
2012-06-11 06:20	Frits	Note Added: 0003738
2012-06-11 08:51	Frits	Note Edited: 0003738	View Revisions
2012-06-11 08:51	Frits	Note Edited: 0003738	View Revisions
2012-06-11 11:12	Dusk	Relationship added	related to 0000872
2012-06-13 02:38	Parad0x	Note Added: 0003753
2012-06-13 07:34	ZzZombo	Note Added: 0003756
2012-06-13 19:16	Frits	Note Added: 0003758
2012-06-13 22:20	ZzZombo	Note Added: 0003759
2012-09-10 12:02	unknownna	Note Added: 0004634
2012-09-10 18:54	Dusk	Note Added: 0004639
2012-09-10 19:05	unknownna	Note Added: 0004640
2012-09-10 19:06	unknownna	File Added: ZDaemon.png
2012-09-10 19:07	unknownna	Note Edited: 0004640	View Revisions
2012-09-11 00:44	Dusk	Note Added: 0004642
2012-09-11 18:18	Torr Samaho	Note Added: 0004646
2012-09-11 21:38	Dusk	Note Added: 0004649
2012-09-11 22:19	Frits	Note Added: 0004650
2012-09-12 20:45	Torr Samaho	Note Added: 0004654
2012-09-12 21:42	Edward-san	Note Added: 0004655
2012-09-13 00:07	Qent	Note Added: 0004656
2012-09-13 00:08	Qent	Note Edited: 0004656	View Revisions
2012-09-16 03:26	Qent	Note Edited: 0004656	View Revisions
2012-09-16 10:14	Torr Samaho	Note Added: 0004687
2012-09-16 10:14	Torr Samaho	Status	needs review => feedback
2012-09-16 11:26	unknownna	Note Added: 0004694
2012-09-16 11:49	Torr Samaho	Note Added: 0004697
2012-09-16 13:11	unknownna	Note Added: 0004703
2012-09-16 13:11	unknownna	Note Edited: 0004703	View Revisions
2012-09-16 13:19	Torr Samaho	Note Added: 0004705
2012-09-16 17:08	Qent	Note Added: 0004709
2012-09-16 17:10	Qent	Note Edited: 0004709	View Revisions
2012-09-16 17:12	Qent	Note Edited: 0004709	View Revisions
2012-09-16 17:12	Qent	Note Edited: 0004709	View Revisions
2012-09-21 14:20	Frits	Note Added: 0004735
2013-03-14 16:37	Watermelon	Note Added: 0006124
2013-03-14 16:39	Watermelon	Note Edited: 0006124	View Revisions
2013-03-14 16:39	Watermelon	Note Edited: 0006124	View Revisions
2013-03-15 12:10	Dusk	Note Added: 0006130
2013-08-01 14:18	Watermelon	Note Added: 0006881
2013-08-01 14:27	Dusk	Note Edited: 0004639	View Revisions
2013-08-01 14:27	Dusk	Note Edited: 0003734	View Revisions
2013-08-09 00:57	legion	Note Added: 0006951
2013-08-09 00:57	legion	Status	feedback => assigned
2013-08-09 01:37	ZzZombo	Note Added: 0006952
2013-08-10 09:21	Torr Samaho	Note Added: 0006967
2013-10-21 03:03	Arco	Relationship added	has duplicate 0001552
2013-12-17 01:45	Dusk	Relationship added	has duplicate 0001611
2013-12-17 13:46	Dark-Assassin	Note Added: 0007702
2013-12-17 20:20	legion	Note Added: 0007703
2013-12-17 22:56	Catastrophe	Note Added: 0007707
2014-03-09 21:12	Dusk	Note Added: 0008376
2014-03-10 20:15	Torr Samaho	Note Added: 0008378
2014-03-10 20:16	Torr Samaho	Note Edited: 0008378
2014-03-10 20:16	Torr Samaho	Note Edited: 0008378	View Revisions
2014-03-10 20:16	Torr Samaho	Note Revision Dropped: 8378: 0004568
2014-03-10 20:17	Torr Samaho	Note Revision Dropped: 8378: 0004569
2014-03-10 20:56	Dusk	Note Added: 0008379
2014-03-10 21:04	Torr Samaho	Note Added: 0008380
2014-03-11 07:39	Konar6	Note Added: 0008383
2014-06-02 03:03	Watermelon	Note Added: 0008834
2014-06-02 03:04	Watermelon	Note Edited: 0008834	View Revisions
2014-06-02 03:04	Watermelon	Note Edited: 0008834	View Revisions
2014-06-02 03:07	Watermelon	Note Edited: 0008834	View Revisions
2014-06-02 03:08	Watermelon	Note Edited: 0008834	View Revisions
2014-06-02 03:08	Watermelon	Note Edited: 0008834	View Revisions
2014-06-02 03:09	Watermelon	Note Edited: 0008834	View Revisions
2014-06-02 04:26	Dusk	Note Added: 0008836
2014-06-02 20:59	Watermelon	Note Added: 0008838
2014-06-04 04:57	JKist3	Note Added: 0008842
2014-06-04 18:38	Dusk	Note Added: 0008846
2014-06-04 18:38	Dusk	Note Edited: 0008846	View Revisions
2014-06-04 18:40	Dusk	Note Edited: 0008846	View Revisions
2014-06-04 18:41	Dusk	Note Edited: 0008846	View Revisions
2014-06-04 18:57	Dusk	Note Edited: 0008846	View Revisions
2014-06-04 19:05	Dusk	Status	assigned => needs review
2014-06-05 06:06	Torr Samaho	Note Added: 0008849
2014-06-05 06:08	Torr Samaho	Note Edited: 0008849
2014-06-05 06:09	Torr Samaho	Note Edited: 0008849	View Revisions
2014-06-05 06:10	Torr Samaho	Note Revision Dropped: 8849: 0004805
2014-06-05 06:10	Torr Samaho	Note Revision Dropped: 8849: 0004806
2014-06-07 09:50	Torr Samaho	Note Added: 0008861
2014-06-07 09:54	Torr Samaho	Note Edited: 0008861	View Revisions
2014-06-07 10:25	Torr Samaho	Status	needs review => feedback
2014-06-07 10:43	Dusk	Note Added: 0008863
2014-06-07 11:01	Torr Samaho	Note Added: 0008866
2014-06-07 12:46	Frits	Note Added: 0008868
2014-06-07 13:28	Edward-san	Note Added: 0008869
2014-06-07 13:29	Edward-san	Note Edited: 0008869	View Revisions
2014-06-07 14:43	Torr Samaho	Note Added: 0008870
2014-06-08 01:20	Dusk	Note Added: 0008897
2014-06-08 01:20	Dusk	Status	feedback => needs review
2014-06-08 07:34	Torr Samaho	Note Added: 0008901
2014-06-08 07:35	Torr Samaho	Status	needs review => feedback
2014-06-08 09:53	Dusk	Status	feedback => assigned
2014-06-08 11:32	Dusk	Note Added: 0008909
2014-06-08 11:32	Dusk	Status	assigned => needs review
2014-06-08 12:08	Torr Samaho	Note Added: 0008911
2014-06-08 12:08	Torr Samaho	Status	needs review => needs testing
2014-06-08 12:08	Torr Samaho	Target Version	=> 1.3
2014-06-09 17:58	Arco	Note Added: 0008972
2014-06-09 20:41	Torr Samaho	Note Added: 0008974
2014-07-05 09:56	Torr Samaho	Note Added: 0009841
2014-07-05 17:18	Torr Samaho	Note Edited: 0009841	View Revisions
2014-07-05 17:19	Torr Samaho	Note Revision Dropped: 9841: 0005271
2014-07-05 19:58	Dusk	Relationship added	parent of 0001867
2014-07-09 16:12	Arco	Note Added: 0009919
2014-07-09 16:12	Arco	Status	needs testing => assigned
2014-07-24 03:03	unknownna	Note Added: 0010052
2014-07-24 03:04	unknownna	Note Edited: 0010052	View Revisions
2014-07-24 03:30	unknownna	Note Edited: 0004694	View Revisions
2014-07-24 03:31	unknownna	Note Edited: 0010052	View Revisions
2014-08-14 15:07	Leonard	Note Added: 0010203
2014-09-29 09:35	Dusk	Note Added: 0010306
2014-09-29 22:55	Dusk	Status	assigned => needs review
2014-10-03 16:32	Torr Samaho	Note Added: 0010316
2014-10-03 19:14	Dusk	Note Added: 0010322
2014-10-05 17:17	cobalt	Status	needs review => needs testing
2014-10-05 17:17	cobalt	Description Updated	View Revisions
2014-10-05 17:17	cobalt	Note Added: 0010335
2014-10-05 20:03	Arco	Note Added: 0010340
2014-10-05 20:03	Arco	Status	needs testing => feedback
2014-10-05 20:03	Arco	Description Updated	View Revisions
2014-10-06 01:32	Dusk	Note Added: 0010360
2014-10-06 01:32	Dusk	Status	feedback => resolved
2014-10-06 01:32	Dusk	Fixed in Version	=> 1.3
2014-10-06 01:32	Dusk	Resolution	open => fixed
2018-09-30 21:35	Blzut3	Status	resolved => closed