New examples, and lots of bug fixes.
Most graphics programming is done in a 0-1 scale, so I think it's still appropriate for the event system. Also given that other parts of Construct such as opacity have long been in a 0-100 scale already, using a 0-255 scale would create an inconsistency with the rgba expression (either color components on a different scale to alpha, or opacity on a different scale to everything else in Construct). So this way is aimed at making sure Construct is internally consistent.
I totally appreciate how this benefits construct, the code, looks tidier, etc. But it's more work for your users. Photoshop and gimp both work in 255, and that's a huge chunk of the artist community. Now you're asking us those who are building palettes, sprites, etc in one system to keep converting to another every time they bring their work in construct.
Think about the huge impact this would have on the Replace Colour effect, for example, in a pixel-based game. Applying any kind of colour changing effects requires translation of every value.
It just seems like this translation from 255 to 100 could either be optional or certainly behind the scenes.
It's just hard to imagine anyone was troubled by opacity being in percentage and color being in 255. I think the pursuit of internal consistency is making your user experience considerably worse.
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.