Colorizer - Build 7 RC

Found a bug: Fading seems to ignore floating points. E.g. if you set fade to 0.9, it will fade to 0.0 - if you set fade to 1.1 it will fade to 1.0

Ah, btw - I'm not certain if fading works perfectly well yet. Imagine the situation that you have a game where the color scheme changes often and quickly. You don't want the player to see any "hard" changes so you use fading.
Now if you have
[events]
* Always
- Fade Blue of Blue from BB( "Colorizer" ) to value ( "desired blueishness" ) in 20 frames
[/events]
With "always" nothing happens at all. If you restrict actions for a short time (which is less than how long the fade takes) you get some sort of flashing fade, that always jumps back to the start value. I believe it's something about the value the colorizer returns for the current colors while fading.

Currently the only way is to delay the next fade until the first fade is complete. Maybe you can look into that to see if the wrong value is returned while it fades. The point is - fading should never be jumpy (that's why you'd use fading in the first place).

Fading actions should be used in events that repeats.
Do something like start of frame-> fade

Should or should not?

Well it's neat to do it once - but what if you have constant change? As in.. always, constantly, all the time, every frame? Don't tell me that's a special situation..

I mean... Fading actions should NOT be used in events that repeats.
In your case, the Function Eggtimer by Andos should help.
[events]
*Start of Frame
-[obj_eggtimer] : Call "Fade In" after 20 events loop
*[color:#FF0000][obj_eggtimer] On function "Fade In"[/color]
-[obj_eggtimer] : Call "Fade Out" after 20 events loop
- [Inset some Colorizer fade actions here, with the length of 20 frames]
*[color:#FF0000][obj_eggtimer] On function "Fade Out"[/color]
-[obj_eggtimer] : Call "Fade In" after 20 events loop
- [Inset some Colorizer fade actions here, with the length of 20 frames]
[/events]

More Fixed on build 8:
Fading takes floats now.
Fading HSL didn't work right.
RR() and Height() got mixed up, Fixed.

Quote:

---

In your case, the Function Eggtimer by Andos should help.

---

Yeah that's nice but doesn't really solve my problem. I think I'll rather go for 18 counters then - 9 to set the desired values and 9 that constantly approach them. It's an ugly solution but I can't think of anything better right now.

The thing is - in my game the coloring is not really predicable - for example the screen might turn red within 3 frames when the player got hit - this is not predicable, and if two events that change the color run at the same time you get the color jumping again.