According to the release note this has been fixed since 1.72.
However, if type player.ship.setOrientation([1, 0, 0, 0]) in the console, and then inspect my ship with the Target Inspector, it says Orientation: -1.000 (0.000 0.000 0.000).
Which one is right? Is the Target Inspector wrong, because Debug.oxp is still in the state of Oolite 1.71? But if it is so, why does it say 1.000 (0.000 0.000 0.000) (without the minus) during the start screen?
question about switched w-component of quaternions
Moderators: winston, another_commander, Getafix
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
you are right... various scripts like save anywhere oxp, takes this into account... as player orientation is very important
normal w for player is -w in output and in scripting.. so before you use it, use this
normal w for player is -w in output and in scripting.. so before you use it, use this
Code: Select all
let w = -player.ship.orientation.w
// do whatever you want with W
Bounty Scanner
Number 935
Number 935
- Eric Walch
- Slightly Grand Rear Admiral
- Posts: 5536
- Joined: Sat Jun 16, 2007 3:48 pm
- Location: Netherlands
I don't know how the player is currently interpreted by the engine, but before 1.72 the w-component was inverted for the player. In the code itself the w-component always had to be inverted before using it. This was very woven through the code. I don't know how deep in the code Ahruman has fixed this, but since 1.72 a scripter has no longer to worry about this. For a scripter the player now is just any other ship. It could be that deep in the code the player w-component is still inverted and the console uses this real quarternion.
But wen you type:
You will get back: (1 - 0i - 0j - 0k) with a positive 1 component. And that is all the script needs. So since 1.72 we as scripters don't have to worry anymore about this anomaly.
To be valid the square of all four components of a quarternion must be one. And for this rule inverting a value doesn't matter. The square of both is the same. It could be that this is old code in the target inspector that tried to correct this old bug by showing it inverted and was overlooked for the 1.72 release.
A quarternion is a complex thing as you probably found out. However it makes rotation calculations faster than with normal representation with vector and rotation angle. Therefor a lot of simulation games seem to use it and we have to live with it.
But wen you type:
Code: Select all
player.ship.setOrientation([1, 0, 0, 0])
player.ship.orientation
To be valid the square of all four components of a quarternion must be one. And for this rule inverting a value doesn't matter. The square of both is the same. It could be that this is old code in the target inspector that tried to correct this old bug by showing it inverted and was overlooked for the 1.72 release.
A quarternion is a complex thing as you probably found out. However it makes rotation calculations faster than with normal representation with vector and rotation angle. Therefor a lot of simulation games seem to use it and we have to live with it.
UPS-Courier & DeepSpacePirates & others at the box and some older versions
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
To clarify what Eric’s saying: the w component is still inverted internally, but not in the scripting interface. The target inspector shows what’s really there; the JavaScript property should consistently and reliably lie to you.
E-mail: [email protected]