[SOLVED] Color UI widget broken if TutorialProgress != 5

Discovered this (bug?) today. My GTAV installation had TutorialProgress (in dxgi/d3d9/opengl32.ini) set to 5 (I'm assuming there was a 5th tutorial step before in a recent release of the binaries?) and the color picker widget was working just fine, whereas newer installations will apparently set TutorialProgress=4 after the tutorial is complete. This causes the Color picker widget to immediately disappear (when TutorialProgress=4) when clicked. To fix the issue, just set TutorialProgress=5 and it works as expected. I discovered this because some people testing my ReShade shader could not get the color picker to work, while mine was working fine.

My guess is that the color widget still thinks the tutorial is going on and is waiting to see TutorialProgress=5?

There is also another bug/odd behavior related to the color picker widget that I need to make a video to demonstrate and will do that soon. It has to do with the hue not retaining a set value if saturation is set to zero, so that if you want to set hue manually first (using HSV mode) and then saturate, the widget gets confused and sets a random hue.

Here is a video demonstrating both things described above:

I observed this behavior on 3.2.2 and someone else reported to me that 3.2.1 did as well. I'm not certain if older versions are affected.

"TutorialProgress" is set to 5 after you confirm the "Don't forget to switch to 'Performance Mode' once you are done editing" popup that should open the first time you modify a variable. The bug is that this popup does not appear when a variable has a tooltip, but the side effects still apply, which is why the color picker closes early. This is fixed now, thanks.

The second issue is a HSV/RGB conversion problem, that I can't really fix. The thing is that the color value is always stored as RGB, so everytime the widget is drawn it is first converted to HSV, displayed, checked for inputs and then converted back to RGB. Now if you change the the hue via the wheel, what's happening is that this conversion introduced a slight offset to the saturation (it's no longer 0, but 0.00001), so that the value stays where you put it. This is because if the saturation is exactly zero, there is no way to extract the hue from a RGB value anymore, so it defaults to red. You don't see this in the HSV and RGB sliders because they are capped to show a precision of three values after the dot only, but if you inspect the HEX value, you'll notice how it changes from #808080 to #7F7F80 when technically it should have stayed the same after changing the hue only. Now if you use the saturation slider after moving the hue, and keep the mouse in place too long or move it just slightly to the left, the drag widget will reset the saturation to zero because there is little precision in calculating the mouse distance moved and 0.00001 is a really small value. At that point, hue information is lost and it goes back to red. You can workaround this by dragging the mouse to the right as soon as you clicked the value. This way the saturation is kept above zero and the hue stays accessible.

What about forcing the widget to limit the lowest possible saturation value to 0.0001 even when the user sets 0.000? Would this solve the issue?

But that's wrong. You want users to be able to enter zero or else wrong RGB values are generated.

I understand the need for accuracy here, but (just thinking out loud without enough actual knowledge, so please forgive me) perhaps an option in the future for "color widget HSV workaround" with a tooltip explaining that RGB values will not be exact if it's enabled?

Would it not be visually indistinguishable from the "accurate" value, despite being technically incorrect? Again, my lack of actual knowledge is causing these questions. I'm not meaning to argue with you or anything.

Yes, you got a valid point. There is another small issue preventing such an implementation unfortunately. The color widget isn't actually part of the ReShade codebase, but part of one of its dependencies, namely imgui ( github.com/ocornut/imgui ). Now I could easily change the imgui code to reflect what you propose, but that would mean I'd have to create a copy of the imgui source code base and do the changes, instead of being able to just reference the imgui repository, which is what's happening right now. Doing the later has the advantage of always keeping step with the latest updates done to imgui (which is under heavy development), while the former would require manual merging all the time, which quickly becomes cumbersome. So I think it would make more sense to propose this feature to the imgui author(s) instead ( github.com/ocornut/imgui/issues ).

That's a good idea. I'll create a video for them to demonstrate the "problem" and see if they have any way or ideas to solve it on their end.