[Manual fix request] "AngleOfMotion" is wrapped between -180 to 180

0 favourites
From the Asset Store
2D Pack of 180 pixel art vehicles to make top view game. ( Cars, trucks, motorbikes, trains, boats ).
  • edit: added the image at the bottom to show exactly what I mean

    TL;DR: Can the C3 manual page for the bullet behavior please be updated to note that the "AngleOfMotion" property is automatically wrapped between -180 to 180?

    I was trying to figure out if a bullet was travelling left or right based on the angle of motion property so I could mirror the sprite appropriately. But I was getting some weird results because I incorrectly thought the engine was wrapping the angle between 0 and 360.

    It took about an hour to figure it out because the manual page for the bullet behavior does not mention this. This seems to work differently than the common "Angle" property because the editor wraps that property between 0 and 360.

    I think it would be very helpful to all construct creators if the manual page for the bullet behavior was updated to note that the "AngleOfMotion" property is automatically wrapped between -180 to 180.

    Here's the current manual page for bullet for reference:

    https://www.construct.net/en/make-games/manuals/construct-3/behavior-reference/bullet

    Thanks!

  • Well that might be even more confusing since technically -180, and 180 are the same angle, and it really does go from 0 to 360. It's just that the expressions return values based relative to zero rather than 360.

    Computer math, not regular math. That's what they might need to make users aware of.

  • ... and it really does go from 0 to 360. It's just that the expressions return values based relative to zero rather than 360.

    I'm not sure what you mean. You can definitely input any value into "AngleOfMotion" but the runtime engine will wrap it to -180 to 180. For example, if you input 270, the debugger will show -90.

  • You can put any value you like. You can put 20030 in but its still going to wrap it to a value between 0 and 360. It just so happens that the math says that -90 is also 270.

  • Asking a feature request

    You can maybe tag Laura_D or maybe suggest here:

    Link: construct3.ideas.aha.io/ideas

    A word of advice to all who use angle data

    The thing is, the Construct Engine doesn't take input angles as raw data. It always processes it first and converts it to radians, then to angle. That is recommended and users too should always use either System Angle Comparators like the Is Between Angles or make their own calculations from degrees to radian then back to an angle within a selected degree scope.

    As you can see in the image, there are many possibilities to this and that's why you always shouldn't just compare but process raw angle data.

    Conclusion

    It actually doesn't wrap the value from between -180 and 180 but Construct processes the raw data from degrees to radians then back to an angle degree within their pre-defined degree scope.

    And all users who want to use angle data in Construct, should take that into account and use either the built-in System Angle Comparisons or process the angle data themselves, from raw angle degrees to radians and back to an angle degree within the pre-defined degree scope.

    I hope that shed some light on the subject.

  • The -180 to 180 range is caused by the math function used to calculate the angle. Namely atan. Radians don’t effect that.

    Probably a good rule of thumb is any angle that is calculated will be in the -180 to 180 (or normalized angle) range, and any angle you set will just keep that value or make it in the 0-360 range. So even though you can set the angle of motion, it’s something the behavior can change so it’s calculated.

    Usually when comparing angles it’s best to just use the angle comparison system conditions. With them it sees things like 270 and -90 as the same.

  • I'm very confused. It seems like 2 people are trying to tell me that C3 wraps "AngleOfMotion" between 0 to 360. But the C3 debugger proves that the value for the bullet's "AngleOfMotion" property is wrapped between a range of -180 to 180 degrees. So if you want to compare "AngleOfMotion" in any way you need to know that, or your comparisons won't work as expected.

    Asking a feature request

    You can maybe tag Laura_D or maybe suggest here:

    Link: construct3.ideas.aha.io/ideas

    I'm not requesting a feature. I'm asking that a piece of missing information be added to the documentation.

    Laura_D What do you think? Should this note be added to the documentation for bullet angle of motion?

    The thing is, the Construct Engine doesn't take input angles as raw data. It always processes it first and converts it to radians, then to angle. That is recommended and users too should always use either System Angle Comparators like the Is Between Angles or make their own calculations from degrees to radian then back to an angle within a selected degree scope.

    Yes the angle comparators are great, but if you're comparing a bullet's angle of motion property you still NEED to know the angle wraps between -180 to 180 to compare correctly.

    It actually doesn't wrap the value from between -180 and 180

    Yes it does.

    If you dl and run this c3p file in C3 you can play with it yourself. Run it in the debugger, pause it, then start plugging in values into the "AngleOfMotion" property.

    dropbox.com/s/dt3worrdtd56u8m/bullet_angle_example.c3p

    This gif shows me doing that exact thing with the above sample project.

  • Lol I can still remember the arguments of why a bullet with no speed has zero angle.

  • Honestly, I'm not the person to ask. I didn't write the manual, and I've not dealt with angles since I left university in 2015...

    Ashley wrote the manual, but it might also be quite handy to get Kyatric's input here too, seeing as he spends an awful lot of time in the software.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Mathematically, -90 degrees is the same as 270 degrees. So it is correct either way.

    People regularly make the mistake of trying to make linear comparisons on angles. This is incorrect because angles are cyclical. For example if you try to test if an angle is within 10 degrees of another angle, then abs(angle1 - angle2) < 10 is the wrong formula, because it doesn't take in to account the fact angles cycle around from 360 to 0. For example with that formula comparing 359 degrees to 1 degree will incorrectly count it as being 358 degrees apart rather than 2 degrees apart. This is why there are system expressions for comparing angles, like "is within angle", which internally do the correct math to take in to account the cyclical nature of angles.

    So in short if you use the right angle conditions, expressions and calculations, it doesn't matter: -90 will be treated as identical to 270. If you make linear comparisons then your calculations are incorrect to begin with and will have other problems like not handling the 360-0 wraparound correctly, as well as other problems like incorrectly treating -90 as a different angle to 270.

  • I got it working using "Is between angles" system condition.

    I'm just noticing inconsistencies with how C3 wraps angles. Sometimes it wraps between 0 and 360, the bullet angle of motion wraps -180 to 180, and sometimes there's no wrapping at all.

    IMO it's worth noting these inconsistencies in the documentation.

  • What should the note say? "If your math is wrong then some mathematically identical angles will be treated incorrectly"?

  • Well it's not really designed to be used as left or right orientation.

    By that strict definition you could just check to see if the angle is greater than zero.

    Btw "For each" shouldn't be needed here, and is actually heavy on cpu.

  • By that strict definition you could just check to see if the angle is greater than zero.

    It's not clear to me if you are actually suggesting to do this, but this is another case of incorrectly making linear comparisons on angles.

  • I can't say its a better method, but it does work.

    With a limited set of rules.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)