[r188] Decimal error in angle on created

Objects created at an angle have a decimal error

When I place a sprite in the editor at any angle besides 0, it will give it a very small decimal.

The angles are also consistent. setting it to 180 in the editor always resulted in 180.00000500895632 degrees with multiple objects in different projects.

Description of Capx

The Capx has multiple objects at different angles in the editor, and logs their angles to the console on creation.

Steps to Reproduce Bug

• Add a sprite
• Set it to an angle other than 0
• Observe the actual angle given

Observed Result

Crazy decimals.

Expected Result

Regular decimals that I gave the objects

Affected Browsers

• Chrome: YES
• FireFox: YES
• Internet Explorer: NOT TESTED

Operating System and Service Pack

Windows 8.1 64 bit

Construct 2 Version ID

r188 beta, also happened on r184 stable

Isn't this the same floating point rounding 'error' (which is normal) that's been brought up a number of times?

codah Not really. That happens when you're doing maths with numbers usually. But I would assume it would set properly if you're explicitly telling the value to be a certain number. How come the angle doesn't get set weird when I set the objects angle through an event? It's only happening when the object is created.

oh ok. I didn't actually load the capx as I'm on 187b (although I'm pretty sure that's what it is , somehow).

This is the same gotcha as "expecting math calculations to be exact", but it's not obvious why: the runtime actually stores angles in radians, since that's how all the math is worked out, and the conversion between radians and degrees involves a slightly lossy multiply/divide. Closing as not a bug... this is another reason you should rely on values being "close enough", not exact. (The new 'Is within angle' system condition is useful for this type of thing - you can say "Is within 0.5 degrees of 180" for example, and it's accurate to the nearest degree.)

Ashley Thanks for the reply. I didn't expect this problem to occur when setting a value without doing any actual calculations to it. How come this doesn't happen if I use the Set Angle to 180 action then? Isn't that doing the same thing?

Ashley Thanks for the reply. I didn't expect this problem to occur when setting a value without doing any actual calculations to it. How come this doesn't happen if I use the Set Angle to 180 action then? Isn't that doing the same thing?

It's because 180 degrees is equal to 1 radian, so it's a simple conversion (so it's actually equal to pi, too).

> Ashley Thanks for the reply. I didn't expect this problem to occur when setting a value without doing any actual calculations to it. How come this doesn't happen if I use the Set Angle to 180 action then? Isn't that doing the same thing?

>

It's because 180 degrees is equal to 1 radian, so it's a simple conversion (so it's actually equal to pi, too).

Still confused. Does the engine set the angle when it's created differently than when you use the action?

No, 180 degrees is not equal to 1 radian. 1 radian is 57.2957795 degrees.

I thought the same thing would happen at runtime since it has to do the same calculation. Perhaps it's rounding it slightly (which the text object does by default for example), or in the past we've had issues where the exporter uses a different precision.