Here’s the Project it was discovered on.
The “value” of the color parameter behaves weirdly.
- The format as we know it is HSB(172,86,96). (Fun fact “HSB 172 86 96” also works).
- Most programs interpret or convert this into a decimal form, where Hue ranges from 0-360, 0-1, and 0-1.
- What’s wrong with Hopscotch? It’s interpreting colors with saturation’s 0-1 as the scaled down form. So 1 correlates to 100 Saturation or 100 brightness, and 5 correlates to 50 Saturation our brightness.
- Basically, Hopscotch is drawing the color based on the decimal system for certain values and is using the 0-100 system for other values.
It not something that occurs naturally, but using my “optimization” feature in my Siri shortcut led to the discovery of this bug.
- The color previews properly in the editor.
- HSB(1,1,1) is a black-ish color.
- In the editor, the preview shows black when that is the color slot’s value.
- However, when I play the project, the color is bright red – HSB(1,100,100).
The Sample Project:
- The sample project’s color is HSB 188,1,97
- The editor shows the proper white-ish color.
- When played, the trail color is instead HSB 188,100,97.
- Optimized just means the color is stored in the value parameter instead of an hsb operator block to use less storage.
@Ana here’s another bug (confirming I shouldn’t tag awesomeonion on individual bug topics? I’ll take your word with that I guess.)