Summary: 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.
Yes, we can. But it’s called inconsistency. Luckily none of the default colors use this, plus I can also just make anything on interval (0,1] just equal to 1.01 and it doesn’t make much of a difference.
Yes I believe so.
If you use the HSB block and then optimize it run AEs shortcut, the number values for the S and B places are registered incorrectly.
It used to work fine and this is a new bug that came after one of the more recent updates.
It used to work fine and then it broke, and it’s apparently a problem with hs, not the shortcut