Color Value Inconsistency [OPEN] (custom edited projects only)

Demo Project:

@FearlessPhoenix thanks

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.)


This is the bug, and yes.

I meant 0.5


First non-creator reply

1 Like

If 0.5 is 50 then we CAN use 0.05 as 5

Weird tho, hope they fix this

1 Like

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.

1 Like

You’re welcome


I think this has something to do with the new update regarding HSB and RGB.

No, it most likely does not.

1 Like

Is this fixed? Optimized and not optimized look the same to me.


Nope I don’t think
You have to press the text to get the colors to show up btw

Oooh. I see

1 Like

to confirm: is this something that only happens if you edit the JSON directly? I couldn’t get it to happen while using the HSB block


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

1 Like

Only when the value slot is being used. The operator works fine.

I have a modification in the shortcut that accounts for this, so don’t worry about prioritizing this, as none of the default colors have saturation/brightness 0-1

Edit for better explanation:

  • Basically, this only affects the “value” key of the color operator in the JSON file.
  • When “value” = HSB(180,1,100), the Saturation and brightness values ranging from 0 to 1 get treated as if they were on a 0-1 scale instead of a 0-100 scale.
  • Basically, 0.5 ➙ 50, 0.25 ➙ 25, etc. etc.

This bug still occurs. (@Ana)


Ok this is low priority, no surprise.