# Custom movement bug question

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
• I am trying to figure out why this approach to cos/sin based movement isn't working. I am making a spread of objects that travel outward from the point of origin. For some reason, if I try to apply the new position to the object's x and y positions directly in an expression, it doesn't work. It only works if I first store the position in a variable and add the new position to that variable. Then set the position of the object to the variable. Can someone take a look at this test file and explain why the first 2 approaches don't work? Approach 3 shows the desired result, but is just using variables that seem unnecessary.

## Files

• I don't know if you know, but the Position variables aren't floats (No decimal points, if they appear, it rounds it down)

- BartekB

• Yea, if you remove the floats (do NOT multiply by 1.0) the same problem occurs. Approach 3 works with or without float values, but approach 1 and 2 do not work in either case.

• Well, Cosine and Sine are already technically floats as they give a float when entered e.g. Sin(45) = 0.85

- BartekB

• I am guessing you didn't look at my mfa example? Even if you multiply the position and all components of the expression by 1.0, the result is still not working.

• I have.
What Fusion does is this for the X and Y positions:

Let's take X as 50

"Active" ) + ( Cos(VecDirAngle( "Active" ) ) * 1.0 )

Will result in:
50 + 0

Why?
Because Fusion rounds down everything in a decimal. Multiplying stuff by 1.0 will just make it 1 as floats are not accepted in that expression.
But if you were to store X and Y as a variable (And never updating them again with x or y) (I call them XActual and YActual), then update the position depending on them, Fusion will automatically round them down but the float will stay in a variable.

What you did in Approach 1 is you rounded down sine and cosines (Lower than 1 = 0, exactly 1 = 1), and what you did in Approach 2 is you updated your variables with no decimal points, reverting variable back to a integer (And then adding a decimal to it, which too would be rounded down by position x or y expression).

- BartekB

• I agree it may have to do with floats:

1)
if X is set to X + N.(float),
X will be set to X because converted in INT
(only changes when N.=1)

2)
newxpos= X(int) + N.(float) = X.N
set X to X.N= X
(again, only changes when N.=1)

while in case 3 you always update value NewXpos,
and this will get changing in floats
so that
NewXpos=NewXpos + float
thus correctly ranging on any possible value
(while the resulting positions will be obviously INTs, but this doesn't matter sinche the value has been "shaped" correctly in relation to frame-changes)

• I think I understand now, thanks. I thought there might be a way to get the position value with the position expression and covert it to a float on the fly. I guess not.

• Quote

I am guessing you didn't look at my mfa example?

I think BartekB is trying to convey that the position value of an object always is an integer. He might very well have looked at the example.

Anytime Fusion converts a float into an integer, a floor() call takes place. This is why actives in approach 1 & 2 travels negative x/y and not positive x/y, except for the eastbound (0 degrees) because cos(0) = 1 = floor(1).

I think this is good work Mobi. You have made a buffer in your last approach that might turn into a good structure of buffers when/if you incorporate delta of timer.