[RELEASE] Tracker OXP

[Solonar]

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.

The errors are occurring under unusual circumstances, not the targets remaining persistent after being destroyed or docked with a dredger. In each instance each target displayed this unusual condition in under two minutes and after each went outside of my scanner range. In the case of the Random Hits target my mission was still not complete. I had to dock with the main station, save the game and then restart it for the target to reappear and complete the mission.

[Thargoid]

Hmm, odd. The tracker works as noted before by using a separate entity with a beacon code, which automatically places itself at the same location as the tracked entity and moves itself every frame. It keeps a target lock on the entity, and if that lock is lost, then the entity is no longer valid (has died, landed, docked or jumped) and so the tracker entity should then remove itself.

But in your case something is going odd, and given it also threw Okti's tracker off too (the NaN range etc) I wonder if it's something a little deeper down in the trunk code. We've had some other reports of oddities with things at long range or ships ending up in odd places (e.g. as reported with my Swarm OXP).

I'll grab a copy of the long-range scanner and see if I can reproduce things when I get some time. But the RH one particularly sounds like the target left the system (via one of the 4 methods above) but didn't go completely.

[Solonar]

Both ships were OXP ships, a Random Hits mark and one pilotted by a salvage missile drone. I will try to reproduce the errors and experiment with other non-OXP ships for the tracking.

[Thargoid]

I don't think it should matter being OXP or not.

[Solonar]

Another incident of the tracking error occurred with a Vampire MkIII ~Purgatory, an active ship that was by itself. I tracked it near the witchpoint beacon and it was being tracked correctly. I then set a course for the sun and en route I scrolled through the ACS targets. The 'T' again appeared on the ACS but no directional finder. The distance NaN for the Purgatory was shown in Okti's Long Range Scanner. If this ship is leaving the system in some fashion the tracker is somehow not leaving with it.


17:07:35.713 [script.javaScript.exception.ooliteDefinedError]: ***** JavaScript exception (LongRangeScanner 0.1): Error: Quaternion.rotate: Expected number, got (NaN).
17:07:35.713 [script.javaScript.exception.ooliteDefinedError]: ../AddOns/LongRangeScanner v0.2.oxp/Scripts/lrScanner.js, line 340.

[Thargoid]

I think I know what might be happening (but will need to test it) - the tagged ship is jumping, and before the tag can detect that the ship is no longer there and self-destruct, it is being sucked into the wormhole. That might be causing a duplicate tag to be created, which of course has no target to lock onto. That in itself should cause the second tag to self destruct, but seems not to be for some reason.

Let me test it and see, as I should be able to code around that perhaps.

[Thargoid]

I managed to reproduce the problem. Tracking a tembo hauler which decided to go into a jump gate, and then things went weird:

> S.shipsWithRole("wildShips_tembo")[0]
[Ship "Tembo" position: (-1.#IND, -1.#IND, -1.#IND) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT]

It's a valid ship still, but with broken position data. The top screenshot is when I moved my ship to proximity to it (offet 100m in x and 1000m in y, but note it's nowhere to be seen ) - see also the ship position that the shift-F is displaying. None of the ASC's worked and there was no sun, planets, dust, nebulae or anything, but S.mainStation.dockPlayer() took me successfully back to the station and from then everything was normal.

I think this is something a bit deeper and in the trunk code (possibly similar or same as we were seeing with Swarm.oxp a few weeks ago). Anyway, bug raised on Berlios...

[cim]

I managed to reproduce the problem. Tracking a tembo hauler which decided to go into a jump gate, and then things went weird:

> S.shipsWithRole("wildShips_tembo")[0]
[Ship "Tembo" position: (-1.#IND, -1.#IND, -1.#IND) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT]

Okay, so -1.#IND and -1.#J are odd printings of NaN/+inf/-inf as a number, so obviously if you set your own position to NaN things will be very strange indeed - that would explain the compass breaking as the other system objects no longer have a defined heading.

But when a ship enters a wormhole it should as far as I can tell from the source be almost instantly removed from the list of entities the system knows about (and only exist inside the wormhole), so I can't see how you could find it with shipsWithRole... And I don't see anything that changes its position either, until it exits the wormhole in the other system. Maybe the tracker holding a reference to it is causing the problems, then?

[Thargoid]

Jump gate (from gates.oxp), not a wormhole - at least in this case. Those specifically move the entity from the witchpoint to the planetary area (as in this case) or vice-versa.

So it does fit with the general scenario, although I don't know what the ships in Solonar's examples were doing but it's quite possible their positions were also being altered by script.

[Thargoid]

I've just updated this OXP to v1.02.

It uses a small but finite-poly model, and again a bit of script work-around in case it gets destroyed in use. But it should overcome any zero-poly issues, although I'm not sure they will apply here anyway as the entity is continually placed in a valid position anyway (position being NaN is the main zero-poly issue.).

Downloads via links below - anyone with v1.01 should update please.

[dybal]

Version 1.03 available in the Expansion Manager and here.

Changes:

- added collision exception between tracker and tracked ship;
- set the tracker's beacon label with the tracked ship name: ASC will show the letter 'T' and the tracked ship's name;
- do not track telescope markers;

[Damocles Edge]

Can this oxp be used to keep track of derelict ships?
I currently use Waypoint Here oxp to do this (especially if I have disabled a lot of ships in battle and am working my way through mining them one at a time), this oxp could have the added benefit of keeping tabs on live targets too.
I am just wondering if this oxp still tracks targets once the escape pod has launched?

[Damocles Edge]

Just had a quick play test of this oxp and I have to say that I really like it.
Great the way that it integrates with the advanced space compass.

The only fly in the ointment for me as a ship miner / salvager who uses an escort deck is that there doesn't appear to be anyway to remove a tracked target.
This results in my track allocation being filled by ships that are on the back of my escort deck and that I subsequently cannot track any further targets.
Would it be possible in a future revision to have a remove target key allocated 9say perhaps "b" as it is beside "n" which adds tracking target.

Other than this minor drawback for me (and my playing strategy) I really like this oxp, keep up the good work sir

[dybal]

Just had a quick play test of this oxp and I have to say that I really like it.
Great the way that it integrates with the advanced space compass.

The only fly in the ointment for me as a ship miner / salvager who uses an escort deck is that there doesn't appear to be anyway to remove a tracked target.
This results in my track allocation being filled by ships that are on the back of my escort deck and that I subsequently cannot track any further targets.
Would it be possible in a future revision to have a remove target key allocated 9say perhaps "b" as it is beside "n" which adds tracking target.

Other than this minor drawback for me (and my playing strategy) I really like this oxp, keep up the good work sir

The work isn't really mine, I just fix it

As it's now, you can remove a tracker by "re-marking" it for tracking: _in scanner range_ (that's the caveat...), target it ('r' in default keyboard configuration), prime ('N') and activate ('n') Tracker.

I did that in one of my testing sessions, marked a GalCop Manta as I left the station, put it on ASC, went about my salvaging business , then latter as I got back to the station un-tracked it: I saw the console message saying the tracker was removed, but I don't remember if I cycled ASC through to see if the beacon was really gone.

A possible improvement could be a MFD like Waypoint Here... the trouble being the really limited number of MFD slots, so you have to keep the really important ones (to you) fixed and use one or two slots to cycle through the less used ones. Will put this one in my TODO.

[Damocles Edge]

As it's now, you can remove a tracker by "re-marking" it for tracking: _in scanner range_ (that's the caveat...), target it ('r' in default keyboard configuration), prime ('N') and activate ('n') Tracker.

I'm sure that is what I have tried before (then again this is me we're talking about, so I'm probably doing something wrong if my track record is anything to go by )

That reminds me of a classic young ones scene from the early 80's
see the clip below @ 14m 17seconds.

https://www.youtube.com/watch?v=5b59Qp4bEFs


I'll try again next time I play.