entity orientation

[Commander McLane]

I don't know if it's a bug or a feature, for me it's an observation I've made.

Back in the day entities used to be spawned with an orientation along the z-axis. Therefore everything that was spawned on the main witchpoint-to-planet route was automatically facing the planet, for instance OXP-added stations.

A couple of versions ago (in 1.75?, or already in 1.74?, or yet earlier?; I don't remember) that changed. Entities now seem to get spawned with a random orientation, and they still are in 1.76. This is for instance highly visible with the Seedy Space Bars. In the early days of Random Hits their docking bay faced the planet. Nowadays not so much.

The same is true for the Sentinel Stations and Renegade Stations from Anarchies. They used to face the planet, but they don't anymore. For upcoming Anarchies 2.6 I've given them a ship script that rotates them towards the planet. It's only four lines of code which Eric wrote originally for the Hacker Outpost, because that is spawned in a random location outside the main routes and therefore was never facing the planet to begin with.

So for an OXP it's no big deal. If you want your station to face the planet, just give it this short rotation code. But I'm just wondering about the underlying change in the spawning mechanism. Was it deliberate? Or was it an unnoticed byproduct of some changes? Is it a feature, a bug, or something neutral in-between?

[Eric Walch]

This rotation has actually not changed. When you use the old legacy_addShip commands, they are still added with an [1,0,0,0] orientation. Only the new addShips commands give the ships a random orientation to start with.

When you want the fixed orientation of the legacy code you could use:

Code: Select all

this.foo = system.addShips(role, 1)
this.foo[0].orientation = [1,0,0,0]

Something similar I now do in one of the latest versions of random hits. Not an orientation towards the planet, but an orientation that always will be the same in a given system.

btw, calculating an orientation can be more efficient than the code I gave you a few years back. Enough is:

Code: Select all

    var targetVector = this.ship.position.subtract(system.mainPlanet.position).direction();
    this.ship.orientation = targetVector.rotationTo(new Vector3D(0,0,1));

It only works reliable since 1.75 as

Code: Select all

rotationTo

had a bug that was only fixed in 1.75.

Vector3D(0,0,1) is the forwardVector of the identity quaternion [1,0,0,0]. So any rotationTo towards that vector wil give you the quaternion that you need to place an objects with the z-vector towards the targetVector.

[Commander McLane]

Thanks for the explanation and for the shortened code.

[cim]

Code: Select all

    var targetVector = this.ship.position.subtract(system.mainPlanet.position).direction();
    this.ship.orientation = targetVector.rotationTo(new Vector3D(0,0,1));

As an aside on that, please could it be noted on the Wiki documentation for rotationTo that both vectors must be normalised, not just 'v'?

[Commander McLane]

btw, calculating an orientation can be more efficient than the code I gave you a few years back. Enough is:

Code: Select all

    var targetVector = this.ship.position.subtract(system.mainPlanet.position).direction();
    this.ship.orientation = targetVector.rotationTo(new Vector3D(0,0,1));

Small problem with this code: it makes the entity face away from the planet. I think it should be

Code: Select all

    var targetVector = system.mainPlanet.position.subtract(this.ship.position).direction();

just like in the longer original code.

[Eric Walch]

My mistake. I just copied the code from an oxp of me without cheching how I placed the object there. But yes, the object was a planetary launching site, so I should have known it was facing away from the planet.

And when you like 'oneliners', you can easy write the whole code in a single instruction.

[Commander McLane]

And when you like 'oneliners', you can easy write the whole code in a single instruction.

True, and when I'm writing myself I indeed tend to write one-liners. The downside is that they are much harder to decipher when you revisit them later (or dissect someone else's code).