[RELEASE] Tracker OXP

[Thargoid]

The Ships Systems Department of the Aquarian Shipbuilding Corporation would like to present to you their latest product, the Tracker. An invaluable add-on to the advanced space compass (ASC - which must also be fitted to the ship), it allows the simultaneous tracking of up to five distinct targets anywhere within the current system (or area of interstellar space).

Once purchased, it is selected by using the "shift-n" key, and then activated with the "n" key (under standard keyboard configuration). This will transfer the current target lock (be it an ident-lock or a missile-lock) to the system. It can then be viewed on the ASC by cycling through to the "T" indicator. Note that a target lock is required before the system can track the entity, so cloaked ships and certain other entities cannot be tracked.

The system has capacity to store five lock-ons. To remove an existing lock-on, just repeat the above procedure. If the target docks, lands on a planet/moon, enters witchspace or is destroyed then the lock is also lost.

Available from tech level 9 systems for 5000 credits to Commanders who already have an ASC fitted to their ship. It's also fully compatible with (and indeed complements nicely) Cim's talkative compass.

Requires Oolite 1.75 or higher, and is with thanks to Ramirez for his trick for non-colliding entities.

Download via the wiki or from my box.com account (links below).

[Commander McLane]

So it works by placing a very small entity with a beacon code inside the entity you want to track, and then updating its position all the time?

Brilliant idea!

[Fatleaf]

Great idea.

I really liked it before when with the ident system you could track a target beyond scanner range. But not a missile lock. I thought this was quite realistic as if a ship can jump to a different galaxy then it shouldn't be too difficult to track a target in-system.

I really hope the capability to target beyond scanner range returns.

Downloading

[Thargoid]

So it works by placing a very small entity with a beacon code inside the entity you want to track, and then updating its position all the time?

Brilliant idea!

Yup. I read Ramirez's post (the one I linked above) and thought "I've got a use for that...".

It does still seem possible for the tag to collide with the entity and get destroyed (as only 5 of its 6 faces can be holes, although all 6 faces are zero sized), but the code just regenerates it if that happens.

[Ramirez]

Yup. I read Ramirez's post (the one I linked above) and thought "I've got a use for that...".

Damn, you managed to get your product to market before me!

Only joking - I've got a slightly different implementation in mind for use with the crewed ship idea (in what I'm starting to call Wreckers.oxp) and is focused more on tracking/analysing targets beyond scanner range. I hadn't got around to working out how to do the auto update though so no doubt I'll be having a close look at your method...

[Thargoid]

Glad it didn't spoil anything.

As I noted after your original post in the ships thread - I couldn't get Wings3D to accept a box with all 6 faces using holes. Hence mine is 5x holes + 1x normal, so if you've somehow managed to get a 6'er you may not have the collision issue at all. In mine it only happens occasionally, but often enough to need the re-spawn check.

It's quite simple coding though between the three scripts (the whole thing took <1 hour to put together - so much simpler when there's little modelling and no texturing to do!), but feel free to use any of the methods or stuff. Happy to return the favour

[Okti]

One minor improvement can be to take consideration of the bounding box at the frameCallBack function to avoid unnecessary collisions.

Good work,

> Thinks about updating his LRS<

[Thargoid]

Doesn't work so well for two reasons:

1) For large objects the tracking beacon will be offset from the entity it's tracking, at least at close range.
2) Even with frame callbacks, putting something at or just beyond the combined collision radii of the two entities still leads to collisions if one is stationary and one is accelerating quickly.

The second is why I have another OXP sitting in WIP on my HD, and a bug report on Berlios.

My (well Ramirez's) way is I think better, even allowing for having to occasionally re-spawn things if they get scrubbed by collision. At the moment those collisions don't happen too often (as the tracker entity is at the same position as the tracked one, hence there is minimal edge collisions as it's actually inside it, plus the tracker entity is tiny).

[Fatleaf]

How about putting the beacon thingie a bit further away from the target so it would be out of the way. As once it is within scanner range the ASC is somewhat redundant.

[Thargoid]

'Cos I'm a perfectionist

The suggestion is basically what Okti said too.

[Ramirez]

Thargoid, this is the content of the holebox.dat that I've been using in my test OXP - there's literally nothing there:

Code: Select all

// output from Obj2DatTex.py Wavefront text file conversion script
// runnign within an app created by Platypus 
// (c) 2005 By Giles Williams
// 
// original file: "holebox.obj"
// 
// model size: 0.000 x 0.000 x 0.000
// 
// textures used: []
// 
NVERTS 0
NFACES 0

VERTEX

FACES

TEXTURES

END

Despite apparently making no sense it seems to work, at least so far as creating a virtual beacon for tracking purposes.

[Capt. Murphy]

'Cos I'm a perfectionist

The suggestion is basically what Okti said too.

the imperfect method is more or less what escape pod locator uses.....

Wouldn't life be much easier if beaconCode was read/write

[Thargoid]

Indeed, although using a r/w beaconCode would add additional complications of tracking which beacons are via the tracker and which are generally set.

Anyway I tested Ramirez's version of the model and it works fine, so I'll upload v1.01 using that (but keep the respawn code in anyway just in case, as it's already fully coded).

[Solonar]

I have been using the tracker and on two occasions I got unusual errors from the tracked target. One was a Vendetta ship on auto pilot with a salvage probe missile and the other was a bounty target from Random Hits. On each occasion the track was not found on the ACS, displaying the 'T' but not the direction finder of the target, and the distance gave an unusual display on Okti's Long Range Scanner, a distance of NaN. I saw that same display on a log as follows..

09:46:56.645 [script.javaScript.exception.ooliteDefinedError]: ***** JavaScript exception (LongRangeScanner 0.1): Error: Quaternion.rotate: Expected number, got (NaN).
09:46:56.645 [script.javaScript.exception.ooliteDefinedError]: ../AddOns/LongRangeScanner v0.2.oxp/Scripts/lrScanner.js, line 399.

When using the Get Closer function on Okti's Long Range Scanner on the NaN target it puts me into some kind of dead space, no stars, planet, sun, stations. All of the usual ACS targets appear lettered on the compass but no direction finder is indicated. The display is similar to when one is in interstellar space and the ACS ceases to function there. I am forced to use the Jump to Station function on Okti's Long Range scanner in order to exit from this dead space.

[Thargoid]

That generally means that the target no longer exists. The posted log error is from Okti's OXP, not mine, but I expect the root cause is the same in that the thing you're trying to approach no longer exists in the system.