Resurrect old color picker #20742
Resurrect old color picker #20742
Conversation
|
i wanted to mention that players in general don't mind if multiple players - in the same team or not - have about the same color - for as long as they are able to recognize and distinguise their own units. so if i.e. the progress bar for your own units would have a different color than of other players, or there is some mode/key that tells you to turn other players to another tint, that could work. the issue is not that colors may look alike, but that you don't know which units are yours or not. |
OpenRA.Mods.Common/UpdateRules/Rules/20221203/AddColorPickerValueRange.cs
Outdated
Show resolved
Hide resolved
PunkPun
force-pushed
the
colorpicker3
branch
3 times, most recently
from
b0e6704
to
f609226
Compare
|
Made the IColorPickerManagerInfo interface much more generic and cleaned up a bunch of code in the process |
|
Changing to a predefined color and then switching back to mixer does not update properly:
|
|
fixed |
|
There is a superflous dot in the first commit message. |
|
If you so wish @abcdefg30 |
There was a problem hiding this comment.
We still seem to be missing some colors very close to white, but I don't think that was ever the goal. We do now have so very dark colors.
Bonus points for yaml hex colors actually matching their in-game representations (making that particular ORAIDE feature useful again). 👍
Couldn't spot issues ingame. I went over the first commit and got halfway through the second, so this isn't a complete review, but I still have a few comments to work on.
| [Desc("List of saturation components for the preset colors in the palette tab. Each entry must have a corresponding PresetHues definition.")] | ||
| public readonly float[] PresetSaturations = Array.Empty<float>(); | ||
| [Desc("List of colors to be displayed in the palette tab.")] | ||
| public readonly Color[] PresetColors = Array.Empty<Color>(); |
There was a problem hiding this comment.
Should we be checking when loading these colors if they violate the Saturation or ValueRanges above?
There was a problem hiding this comment.
They are going to get fixed anyway. But we could add a lint check if you feel it's needed.
There was a problem hiding this comment.
Lint checks are always nice, but I wouldn't say it's required here. I was talking about runtime and as long as these colors are fixed to valid ranges that should be fine.
OpenRA.Mods.Common/UpdateRules/Rules/20221203/AddColorPickerValueRange.cs
Outdated
Show resolved
Hide resolved
OpenRA.Mods.Common/UpdateRules/Rules/20221203/AddColorPickerValueRange.cs
Outdated
Show resolved
Hide resolved
OpenRA.Mods.Common/UpdateRules/Rules/20221203/AddColorPickerValueRange.cs
Outdated
Show resolved
Hide resolved
OpenRA.Mods.Common/Widgets/Logic/Settings/DisplaySettingsLogic.cs
Outdated
Show resolved
Hide resolved
|
Sounds like this should finally close #20415. |
|
Note: PR NOT cherry-picked to |
|
I vote for picking to |
Closes #20415
Credit to @darkademic. I just added a few of the missing bits such as the update rule.
Color picker in this PR
Old color picker
Bleed color picker
As you can see the the color picker looks better with S and V axes flipped.
I also implemented
IColorPickerManagerInfointerface so that third party mods would be able to implement their own color pickers. When reviewing the second commit I recommend to start with the interface.