Scripting requests

[Thargoid]

Something similar to the style of this entry may be more appropriate, depending on how it's worded. To ensure that it's clear that this is a non-standard property introduced by an OXP, and isn't in the vanilla trunk.

My only personal concern may be that if it's not worded well it could cause confusion if other OXP writers presume it's a standard built-in property and rely on it.

[Wildeblood]

My only personal concern may be that if it's not worded well it could cause confusion if other OXP writers presume it's a standard built-in property and rely on it.

You can't rely on any of the sun_* properties being in system.info. If no-one sets them, they won't appear there. That's the way planetinfo / system.info works.

[Commander McLane]

My only personal concern may be that if it's not worded well it could cause confusion if other OXP writers presume it's a standard built-in property and rely on it.

You can't rely on any of the sun_* properties being in system.info. If no-one sets them, they won't appear there. That's the way planetinfo / system.info works.

Wrong. All proper planetinfo properties have a default value, which appears in SystemInfo even if nobody sets anything.

That's exactly the reason why your non-standard properties should be marked as being non-standard, just like Thargoid suggested.

[Wildeblood]

My only personal concern may be that if it's not worded well it could cause confusion if other OXP writers presume it's a standard built-in property and rely on it.

You can't rely on any of the sun_* properties being in system.info. If no-one sets them, they won't appear there. That's the way planetinfo / system.info works.

Wrong. All proper planetinfo properties have a default value, which appears in SystemInfo even if nobody sets anything.

You know, it takes all of ten seconds for anyone reading this to open the debug console and type in ":d system.info".

[cim]

If it's not too late, can I request a new command addRoles to shipdata-override.plist. Functionality to tack its given roles onto the existing role list of the entity it's overriding, rather than replacing it (that functionality would remain within shipdata-override via using the role key there as now).

That would not be straightforward, with the way ship plist parsing works.

Can you use like_ship in shipdata.plist instead? This should give roughly the same results.

Code: Select all

"cobra3-myrole" = {
  "like_ship" = "cobra3-trader";
  "roles" = "myrole(1) myotherrole(0.2)";
};

[Thargoid]

In some cases yes, although it gets a little messy. If it's a difficult job then forget it - like_ship could work enough for single OXPs.

[Wildeblood]

Is there a way to detect whether the Missile/Ident display on the HUD is actually showing the missile icons or the target's name? If not, would it be possible to add?

[Thargoid]

More a question than a request, but seems the best place to ask:

What is the relationship between player.ship.orientation and player.ship.heading? I know one's a quaternion and the other a vector, but I would expect one to derive from the other in conjunction with the global unit vectorForward [0,0,1].

I was expecting PS.heading.rotationTo([0,0,1]) (or possibly the reversed rotation with the two vectors swapped) to give the orientation, but it doesn't. If I try it on a randomly placed player ship it equals (0.745586 - 0.0986376i - 0.659069j + 0k) whereas PS.orientation gave (0.205018 + 0.60654i - 0.276063j + 0.716845k).

I'm guessing orientation is in the global frame of reference, but I would also expect heading to be so as well. Or is that assumption wrong (if so what frame of reference is it in?).

I'm still trying to sort out trackerCam to not to that annoying barrel-roll, but keep ending up with weird effects as I think things aren't in the frame of reference I' assumed they are.

[cim]

PS.heading should at all times equal PS.vectorForward

The problem is that there are an infinite number of quaternions which can represent the orientation of an object, given solely its vectorForward. When you do rotationTo, only the turn to the new vector is considered - the resulting roll is arbitrary.

So if you do PS.orientation.vectorForward() you should get PS.heading ... but to get from PS.heading to PS.orientation, you'll need to also consider PS.vectorRight and PS.vectorUp to roll the ship to the correct orientation after the turn.

[Thargoid]

The thing that got me wondering was I was initially expecting the x/y/z components of vectorForward to be the ones used in the calculations of the corresponding parts of the orientation quaternion.

But that couldn't be true as the z component is zero, and the only way that could be true (as I wasn't on global z=0) is for the sin (a/2) part to be zero. But if that was so then x and y would also have been zero. Hence I'm obviously making an incorrect assumption here somewhere.

But yes, the headings and vectorForward do match up - that part is fine. I'm just getting my head twisted around quaternions again.

[Thargoid]

Or as a proper scripting request - would a simple built-in pair of functions to transpose between co-ordinates and orientations in world space and ship space be possible (as I presume such functionality must exist within the trunk framework to position sub-entities and the game viewpoints)?

Either that or the loan of a thumb or two to help untie the knots that all these quaternions and frames of reference have tied my brain in.

[Eric Walch]

would a simple built-in pair of functions to transpose between co-ordinates and orientations in world space and ship space be possible

Not possible as a quaternion has 4 independent parameters and a vector only 3. You need more info for a proper conversion.
But one function is already present: rotationTo. That creates a singe orientation (out of infinite possibilities) that has the requested forward vector.

[Thargoid]

Sorry I meant a translation between an orientation quaternion in ship space and in global space as one function (or pair of them) and a second one (or pair) to do the same between position vectors in the two frames of reference. I didn't mean between a position vector and an orientation quaternion.

[Thargoid]

OK, I can answer my own question as I've found the function I was looking for. The code below will take a quaternion and return its inverse. Hence to get from global to local, all you need to do is make the position relative to the player ship (by subtracting the PS.position) and then multiplying by the inverse of the PS.orientation.

Code: Select all

this.qInvert = function(quat)
	{ 
	var length = 1 / ( (quat.w * quat.w) + (quat.x * quat.x) + (quat.y * quat.y) + (quat.z * quat.z));
	quat.w *= length;
	quat.x *= -length;
	quat.y *= -length;
	quat.z *= -length;
	return quat;
	}

Seems to work well for the camera - will update the OXP shortly.[/color]

[JensAyton]

Cim has now exposed a conjugate() method. Your qInvert() is equivalent to quat.normalize().conjugate(); since any orientation you retrieve from Oolite will be normalized, quat.conjugate() is generally sufficient.