Bug: Color Themes (saved in color picker/palette) misbehaves

I’ve run into a rather frustrating bug with saved color themes in the editor - as it relates to the color picker dialog, not theming of the editor itself or anything.

The issue is ordering, labels, and undesired re-ordering and removal of labels. Here’s the expected workflow:

Let’s use typical saturated primaries:

  1. Red
  2. Green
  3. Blue
  4. Cyan
  5. Magenta
  6. Yellow

Create a new color theme via a color picker dialog, and here we see the first inconvenient issue: ordering. The list of colors you see above? Well in order to have them displayed in this order, it’s LIFO (last in, first out) so you need to add the colors to the theme backwards from the list. Not the end of the world if you are aware of this - but very inconvenient if you are embarking on creating several palettes, working from a list from your docs created for a project prior to this… now you’re forced to read backwards from your doc lists, and on top of being annoying, we’ve expanded the margin for error.

Next up is labels. Right clicking an setting a label on all the colors in the theme is easy enough, however, go ahead and close your UE project, then reopen it. Now go take a gander at your color theme… The order is now reversed! This happens whether you label them or not in my testing, but the labels and order is important for the next frustrating issue.

We can (should be able to) edit Saved/Config/WindowsEditor/EditorPerProjectUserSettings.ini, modifying the color themes we’ve saved in the [ColorThemes] section. Right, manually edit the order and labels, setting things straight. Now open back up the project.

The labels disappear. I haven’t done enough testing to see how predictable it is, but sometimes on top of this, the order isn’t respected either. Okay, so let’s re-order things and set labels again within the editor itself… close project, and re-open. Order reverses again, or labels disappear. So here’s what the bad behavior seems to be, overall:

  • Adding new colors is backwards within the palette view. New colors added should have the swatch and saved order appended, not prepended within the theme list. If I add Red/Green/Blue in that order, the swatch display order should be Red/Green/Blue - not Blue/Green/Red.
  • Re-ordering after adding labels to colors in a theme, removes the labels. This is very undesired of course.
  • Re-ordering, and then adding labels, and opening a project at a later time, keeps the labels but breaks the set order. This is also very undesired.

So overall, I think some love needs to be shown to this “little” feature of the editor. I got bit by these issues pretty hard, after spending many hours developing palettes/themes to re-use throughout other projects and such, only to close the editor, come back the next day to continue work on the project that housed the color themes so much time was spent on, and find everything busted. Sure, I have everything relating to the color themes (values, labels) saved in documentation elsewhere… but fighting the above issues and doubling/tripling work efforts is never fun.

I’m going to look into having color themes saved in another *.ini file that is safer… having this stuff in the current file that can often be nuked, or is constantly overwritten without respect by the editor/engine isn’t ideal for this type of thing anyhow. If I find a solid solution, I’ll circle back here to update.

I found an interim “fix” for this:

  • Create <PROJECT_DIRECTORY>/Config/DefaultEditorPerProjectUserSettings.ini
  • Copy (I cut, to avoid any config hierarchy behavior) the [ColorThemes] section from:
    • <PROJECT_DIRECTORY>/Saved/Config/WindowsEditorEditorPerProjectUserSettings.ini
  • Paste that in <PROJECT_DIRECTORY>/Config/DefaultEditorPerProjectUserSettings.ini

Swatch display order and labels are respected when using this approach, between editor sessions. This file is also safe from deletes/overwrites and more friendly to repo commits.

Another annoying issue with the color theme saving: in the ini the color values are shown as RGB but they are actually HSV. This made me do a double take, as I was working with linear RGB values when documenting and creating my color palette empire. Thinking in RGB when documenting, creating the color themes using RGB in the editor, and then having to think in HSV when reviewing/validating the ini is a bit clumsy. Something else that should be fixed. At the very least, listing the values like so:

Theme0Color0=(H=0.000000,S=1.000000,V=1.000000,A=1.000000)
Theme0Label0=Red

Versus the current implementation:

Theme0Color0=(R=0.000000,G=1.000000,B=1.000000,A=1.000000)
Theme0Label0=Red