[RELEASE] - Synchronised Torus 1.0 (2015-12-14)

[Cody]

<Smivs starts wondering if they should wobble...>

A jelly with no wobble? Perish the thought!

[Amah]

Ha, sorry, I was joking - they don't really wobble. Actually they are static, but seem to rotate very slowly sometimes.
<Smivs starts wondering if they should wobble...>

definetely

[Smivs]

Of course they are not really jelly at all....

[Fritz]

I met my first jelly. The torus synchronisation controller classified it as "unsuitable target"...

[Smivs]

I met my first jelly. The torus synchronisation controller classified it as "unsuitable target"...

[Rustem]

Thanks! Patrol Duma was supported safe and quikly travel to A-star:

[Fritz]

What's this? Did you make an interstellar torus flight?

[Fritz]

Version 1.0 is online and available in the OXZ manager.

I've added a check for correct alignment of escorts. The distance to the next waypoint is now displayed continuously in the scanner targeting description, so if you are going to distant stars, you can see how long it will take.

[phkb]

I've downloaded this an am planning to test it tonight, but a quick question: Does the sync process take into consideration the NPC's view of the player? What I mean is, if the NPC considers the player an enemy, will that mean they can't sync the torus drive? Following on from that, if an NPC is fleeing from the player, can the player do a sync torus process to keep the target in view?

[Fritz]

There is no checking for this in the code, but testing has shown that is isn't necessary. An enemy will either flee - having a destination too close - or attack - in this case alignment is impossible and the destination is too close too. I wonder if NPCs have something like a red condition; this would be easy to check and give an additional security.

[Fritz]

I should do something here. Strangely, if you follow a fleeing ship for longer, the interval between two waypoints becomes larger and larger, so that short synchronisation phases are actually possible at some point. But it's no real advantage for the player, because he has to stay close to the fleeing ship anyhow (closer than 2500 m).

The wiki says that NPCs have an alertCondition too, either red or yellow. If fleeing ships have red condition, it will be easy. I should probably check player condition too because nobody should use torus drives to flee from a dangerous situation.

[Amah]

heh, ok... I was tyoing around with the snyc torus and just successfully qualified for the darwin awards by syncing with a ship launching from a rock hermit and hitting one of the asteroids on full torus

[Fritz]

As long as you don't crash innocent NPCs...

[Fritz]

I've found a little bug that occurs when you buy a new ship. The synchronisation controller is a piece of equipment and it is awarded on startup. But if you change ship, this fails until you save and reload the game - if you launch immediately after buying the new ship, the equipment is missing (obviously because there is no startUp event). Using "isPortableBetweenShips" in equipment.plist doesn't solve the problem.

Is there a proven and recommended way to handle this kind of problem? Awarding it on launching too could be a solution.

[spara]

Don't know what's recommended or not, but playerBoughtNewShip should work. Unless player ship is replaced by using js.