pi/180 = a very small number.

cos(any angle)= mostly less then 1

cos x pi/180 = even smaller

Self.Speed must be like 10.000 to have VX resulting in a value of 1 pixel.

Rounding issues push VX closer to 1 and VY closer to 0.

Look into the Ghost Shooter Tutorial for a better sollution.

Another tip: Use Browser plugin > action > Log ... to log VX.

Press CTRL + SHIFT + i in Chrome's preview window to monitor logged VX.

Now you can see what is happening with VX.

Pin a rotating sprite to an invisible bullet.

You got all that math to translate RGB to HSL. Should be understandable with the links that HenryPK gave.

The Hue that the effect takes as value is in the range 0-100.

The calculated (and standard) H is in the range is in the range 0-360

Normalised this means ...

Value to bring into the effect for Hue = (H / 360) * 100

The Saturation that the effect takes as value in in the range 0-100

That is also the range for the calculate S, so no prob here.

Value to bring into the effect for Saturation = S

The Luminosity that the effect takes is in the range 0-200.

Calculated L is the range 0-100.

But the plugin wants to 'adjust'. So, if there is already a value 50 present, it needs to be able to adjust (relative) that to zero.

This means that the plugins value effectively has a range 0-100, but (absolute) is using an offset of 50.

Or.

Luminosity value to bring in the effect = L + 50

All that makes the values that you feed to the plugin absolute, although its working is relative. But only if you start with a sprite that is pure red. Pure red = zero degrees in the colour wheel, has 100% saturation, and a luminosity of 50.

Here you go,

https://www.dropbox.com/s/aln1k3lsv0p92 ... .capx?dl=0

Finally understand those numbers in the HSL effect.

I would add to what HenryPK says.

https://www.dropbox.com/s/pqvzx2ygxd3ve ... .capx?dl=0

This is not gonna work with the effect "Adjust HSB/HSL".

Why? Because of that little word 'adjust'.

It takes the HSL of the sprite and rotates that colour, adjusts that lightness and saturation.

In other words, the outcome is relative to the existing color of the sprite (unless that is what you want)

But there are two other effects that work well and without conversion.

Blank = same as 'Every tick'. For me, that way the events read better. And they are 'collapsable' to 1 line. Less mess.

They pre-calculate the situation for those 3 blocks that are set in the layout, the set up does not start with no blocks selected, there are 3 blocks pre-selected.

Now, there are 2 rows. I could have done it with 1 event using sprite.row = 0. And then duplicate those evens and change sprite.row = 1 for the other row. But that are 'Duplicates' for a minor change. Duplicated events (and if one does that a lot) makes up for more events. While it should be efficient: as less events as possible.

You can do this by calling a function to the same code, using row as a parameter. That is the main reason for using a function: eliminate duplicated events.

I opted for a repeat loop. Loopindex is the current iteration of the loop. The repeat performs those evens twice. That first time loopindex = 0. The second time loopindex = 1. So the first time it picks the first row, the second time the second row. It looks for selected blocks only in that row, and calculates the sums.

The TextBox 'steals' the mouse. That is why the TextBox has its own condition > On clicked.

Start from the TextBox (not form Mouse) to add the condition.

In the editor, it does actually recycle UIDs, to keep them low-ish. (Otherwise if you deleted all your objects and added a new one, it would have a high UID - this way it goes back to being low.) However at runtime UIDs keep incrementing by 1 for every new object, they are never re-used. The limit is the integer limit of Javascript's double-precision floating point numbers, which is 9,007,199,254,740,992 (9 quadrillion I think that's called?). Hopefully high enough

Only recycled in the layout during development.

Unique during runtime.

'Off screen' is not really a player in the flow. It is just a 'place' where you place those that are 'not in play'.

I suppose you use instances, else use a family.

Give them a instance Boolean 'InPlay'.

When the global variable demands to bring one in play ....

___ Object > Is Boolean instance set 'InPlay' <--- INVERTED (so it reads as 'InPlay' = false)

___ System > Pick random instance (Object)

__________action > Object > Set Boolean 'InPlay' to true

__________Actions to place it somewhere on screen.

When an object is destroyed.

_________action > Object > Set Boolean 'InPlay' to false

_________action > Object > set X to -9999

Do not actual destroy it, just move it off screen.

If you want to use ''Off screen' as kind of 'the Boolean' ...

When the global variable demands to bring one in play ....

___ Object > Is On screen <--- INVERTED

___ System > Pick random instance (Object)

__________Actions to place it somewhere on screen.

When an object is destroyed.

_________action > Object > set X to -9999

If you still need help, we need the encryption key of that Mega Share.

Ah yes, i should have realized the consequence when is stated "It updates its expressions during the tick".