New examples, and lots of bug fixes.
Hmm... I think maybe a better way to look at this is the difference between editing images vs. graphics programming logic. Image editors tend to work on a 0-255 scale for legacy reasons, or on the assumption you're editing an 8-bit image. However all graphics programming is done with a normalized scale. So keeping to that principle, the editing features would use the standard 0-255 scale, but the event features would use a normalized scale.
For sure, that makes total sense from the engineering perspective. The trouble is that most image editing software works in 255, and that's where our initial colour choices are made — regardless of the image's bit depth.
So from the game designer POV, 245 or whatever 255-based number becomes the value. Translating it back to 100-base is extra work, serious disruption in the workflow, and potentially problematic (imagine forgetting to convert 84 from 255-base to normalized).
As a game designer, I'm really hoping you can remove translating values at all for the R, G, or B channel value. If the designer's colours are chosen in 255-base, then they should be able to stay that way throughout the design process. Most colour interfaces give you option to use whatever system you prefer (hex, rgb, etc). I think it should be the case here.
I really do understand your case from the programming principle, but really think it's the wrong principle to base the construct experience on.
As described here I've added new expressions for the next release that work in a 0-255 scale, so you can have it both ways.
Ah sorry! I didn't see that! Thank you very much for the flexibility. It's a tough one, I'm definitely on your side from a logic perspective - the 255 system makes no sense - but it's how the tools speak. Hopefully it'll change to normative one day. Anyways, thanks again. Very much appreciated.