New COB constants?
Moderator: Moderators
There is one more constant you may be interested to add. It's the plane crashing state (bool crashing in CUnit). At least get only (although the code in AirMoveType looks like it will work with set, too - if you set that to TRUE, the aircraft will enter the crashing state). Can be used for a lot of things.
FLOZi wrote:At a glance, the pitch information is held as a float3 so that would be trickier, unless I allowed manipulation of each component.
Argh wrote:If ya did a rough conversion on the GET, returning radians, it'd probably be acceptable for most purposes.
AF wrote:Or GET PITCHX, GET PITCHY, GET PITCHZ especially since radians assumes floating point which just isnt possible in cob so there'll be a huge margin of error....
That "huge margin of error" we're speaking of is more than 28°.Argh wrote:"huge margin of error" should still be quite a bit less than 1 degree, I would think- and I'm not planning on using this to aim a rocket at Saturn 2 years from now, so it's ok. This is strictly to improve the visual quality of vehicles with, without having to resort to more complex methods.
But yeah of course you're the amazing breakthough scripter, and I'm only a flaming troll for reminding for the upteenth times the COB only handles integers, not floats, and that within scripts, angles aren't noted in radians but instead in 1/2^16 of full circle (like, 182 for 1°). Your dreamy beliefs (ref: "I would think") are obviously truer than proven facts and elementary math, since you're The One. I'm just being ungrateful that you deigned sharing with us your infinite wisdom.
Not to mention in "float3", there's not only "float", but also "3", but yeah if we used only one single number, as long as it's in radians it would contains all the information, since you said so.
-
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
Argh, compound error can turn a small value change into a huge error difference.
Your being told by zwzsg the most experienced BOS coder in the OTA community and arguably the spring community, who has spent years fiddlign and done things that many thought were impossible, to disregard what hes learnt and listen to you.
I dont know what it is you two have against eachother that drives you to constantly bicker but arh somtimes its better to listen to the person whose spent 10x longer looking at soemhtign than you have unless you can proove what he says is wrong.
In this case I can backup zwzsg by saying that even fi COB supported floating point in OTA spring doesnt support it. Spring COB cannot use floating point, it uses whole integers. The same with BOS. That 3.129 you saw? Its a 3 now, that 2.9? Its a 2 now. Look at that 0.9999? Oh its just a 0.
In COB floating point values will be truncated according to how mingw32 casts floating points to itnegers, which in C++ means, truncate everything after the decimal, aka round downwards. Constants within the COB will be truncated based on the rules of the COB compiler source code language.
The lesson?
BOS doesnt support floating point values, it never has, you will need lua if you want accurate trig based calculations or you can get huge margins of error. Compound error is real and it can get exponentially higher. Ask any A level physics student whose calculated the margin of error.
Your being told by zwzsg the most experienced BOS coder in the OTA community and arguably the spring community, who has spent years fiddlign and done things that many thought were impossible, to disregard what hes learnt and listen to you.
I dont know what it is you two have against eachother that drives you to constantly bicker but arh somtimes its better to listen to the person whose spent 10x longer looking at soemhtign than you have unless you can proove what he says is wrong.
In this case I can backup zwzsg by saying that even fi COB supported floating point in OTA spring doesnt support it. Spring COB cannot use floating point, it uses whole integers. The same with BOS. That 3.129 you saw? Its a 3 now, that 2.9? Its a 2 now. Look at that 0.9999? Oh its just a 0.
In COB floating point values will be truncated according to how mingw32 casts floating points to itnegers, which in C++ means, truncate everything after the decimal, aka round downwards. Constants within the COB will be truncated based on the rules of the COB compiler source code language.
The lesson?
BOS doesnt support floating point values, it never has, you will need lua if you want accurate trig based calculations or you can get huge margins of error. Compound error is real and it can get exponentially higher. Ask any A level physics student whose calculated the margin of error.