[RELEASE] Tracker OXP

[dybal]

Tested it... tagged 5 ships, could see all of them on ASC, couldn't tag a sixth one, re-tagged a tracked ship, got the "... tracking removed" console message and couldn't see the ship on ASC.

Be sure to be in scanner range when you try to re-tag to remove the tracker - if your target is beyond scanner ranger your target is really a telescope marker and not the tagged ship (I need to find a way to go from the marker reference to the ship it's standing for, then it would be possible to at least remove the tracker from a distance - though for in-universe story consistency that would perhaps not be a good idea: the tracker would be a physical device that you "fire" and attaches itself to the tagged ship... if it's not in scanner range, it would have to travel a greater distance back to your ship, which should take time and perhaps be beyond its endurance)

[cag]

I need to find a way to go from the marker reference to the ship it's standing for, then it would be possible to at least remove the tracker from a distance

In the telescope oxp, there's the list of scanned entities $TelescopeList and an index $TelescopeListi into it. So if you're targetting the telescope marker,

$TelescopeList[ $TelescopeListi - 1 ]

should get you the ship. (FYI: the - 1 is Norby's convention; he uses $TelescopeListi == 0 as target not found, so when $TelescopeListi == 1, it's referring to the first in the list, at [0])

from NumericHUD_3.27.oxz, numerichudv3.js line 1231

Code: Select all

var t = this.$telescope;
if( t && player.ship.target.dataKey == "telescopemarker" ) //get distance over scanner range
{
    var ti = t.$TelescopeListi;
    var who = t.$TelescopeList[ ti - 1 ];
    if( who && who.isValid )
    ...

For more examples, check out
CombatMFD_1.12.oxz, script.js line 235
EscortDeck_1.11.oxz, escortdeck.js line 1090

To maintain compatibility in telescope 2.0, $TelescopeList[ $TelescopeListi - 1 ] should also work (I hope ).

though for in-universe story consistency that would perhaps not be a good idea: the tracker would be a physical device that you "fire" and attaches itself to the tagged ship... if it's not in scanner range, it would have to travel a greater distance back to your ship

I don't see a problem here. I read it as added processing power to the ASC, with extra CPU's dedicated to tracking. \_0_/ Otherwise, you'd eventually run out of trackers, as their targets jumped, docked or died.

Sure, it's implemented as a 'ship' but that just made it much easier to code. They even respawn if they die due to "scrape damage"

[dybal]

$TelescopeList[ $TelescopeListi - 1 ]

should get you the ship. (FYI: the - 1 is Norby's convention; he uses $TelescopeListi == 0 as target not found, so when $TelescopeListi == 1, it's referring to the first in the list, at [0])

Thanks, cag!

I would also like to suggest placing a reference to the entity it "surrogates" for in the marker object (if the marker is a ship, perhaps in ship.target?)... it would allow whoever needs to find the "surrogated" entity to do it without looking into Telescope internals (which might change from version to version... given time, it might turn into a nightmare to maintain )

though for in-universe story consistency that would perhaps not be a good idea: the tracker would be a physical device that you "fire" and attaches itself to the tagged ship... if it's not in scanner range, it would have to travel a greater distance back to your ship

I don't see a problem here. I read it as added processing power to the ASC, with extra CPU's dedicated to tracking. \_0_/ Otherwise, you'd eventually run out of trackers, as their targets jumped, docked or died.

Sure, it's implemented as a 'ship' but that just made it much easier to code. They even respawn if they die due to "scrape damage"

I usually place much more importance in the in-universe story consistency than in how we might implement it... ASC shouldn't be omniscient, so we have to explain how it gets the info for what it shows... I see several cases:

a) objects with fixed position (in the real world would be known and stable trajectories) listed in the system's almanac or player ship's nav computer: planets, moons, stations, waypoints
b) objects with a Navigation Beacon broadcasting their position (position in the broadcast signal payload)
c) objects with a simple beacon broadcasting a "locator" signal (no position in the signal payload, but it could carry some ID, broadcasting power, etc.): we could postulate ASC has directional receivers so it can tell the signal direction, and distance could be estimated from the signal intensity vs broadcasting power or triangulation (over time)
d) it could have a gravitic sensor and "see" objects depending on their mass/distance (like Telescope extension)
e) it could track any visible eletromagnetic source, triangulate to get distance (we already postulated directional receivers) and tag with IFF info when in scanner range (as Telescope does for visible wavelengths)

I always thought ASC does (a) and (b), assuming a Navigation Beacon would always have broadcasting power to be "heard" across the system.

If Tracker uses (b) or (c), there would be a physical device that had to be attached to the tracked ship (we can postulate the device would broadcast with enough power to be heard across the system), you would have to be close to attach a tracker or recover a tracker, and you are right, it should be lost if the tracked ship jumps or is destroyed, so there should be a Tracker Pack for sale in Ship Outfitting.

If Tracker uses (d) or (e), yes, it's an upgrade of ASC hardware (the gravitic sensors or directional receivers, memory and processing power), you could define a tracker when in IFF range (to attach ID info to it), you could "remove" a tracker anytime, the ASC hardware would define the number of simultaneous trackers, but there should be a range limitation to the tracking.

Which would be more interesting for the gameplay, the player having to manage a physical supply of trackers, or having a range limitation on tracking?

Tracker is best used to keep tabs on moving objects (I usually use it to keep tabs on the Deep Space Dredger I have seen, so I can find them again easily - DSDs are the only place I can go to get those escape pods processed when I'm a fugitive), for static objects like derelicts I use Waypoint Here if I'm in a hurry, or "tag" them with a Towbar or EscortDeck beacon if I have the time (the EscortDeck being better because the beacon has a more descriptive label)

[dybal]

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?

Sorry, Damocles, I had missed that post.

I haven't tried it, but I think if you tagged a ship and afterwards "derelicted" it, the tracker should still track the derelict (I think isValid property remains true for derelicts, it's the only thing on the tracked ship that's checked).

The tracker could be destroyed when you turn the tracked ship into a derelict depending on how the core game deals with entities sharing the same location receiving energy damage (the one with the larger bounding box get it?) and who is processed first, the FCB that moves the tracker to the tracked ship location or the routine that deals the energy damage (the tracker could be "outside" the tracked ship bounding box for a little while if the tracked ship is moving fast)

I usually create a waypoint just before the battle begins, then try to remember to create other waypoints if the battle moves too much and I "derelict" someone, then after the battle is done I make a derelict stash (choose one of them and carry the others there, by Towbar or EscortDeck, and that places beacons on the moved derelicts so I can remove the waypoints)

[dybal]

Version 1.04 available in the Expansion Manager and here.

Changes:

• disabed tracker beacons while player's ship is docked (so the tracked ships don't show on Station Interfaces (F4) In-system Distances;

• logging of tracker's destruction or invalidation;

• console messages when trying to track/untrack a target out of range, or without a target.

I hope the console messages are visible and descriptive enough for the players to realize what's wrong when trying to use Tracker.

In the previous version I added collision exceptions between tracker and tracked - the tracker was often destroyed by scrap damage with the tracked and had to be re-spawned.

I haven't seen the tracker destroyed by scrap damage after adding the collision exception, but in one of my testing sessions the tracker disappeared while the tracked was still there in front of me, without anything that I could see to destroy it, and nothing logged... after that I added log messages for when the tracker destruction wasn't by scrap damage by the tracked, but all I have seen in my gaming since then were the logs of when the player (me) removed the Tracker.

[dybal]

 Tracker OXP v1.05 is available on the Expansion Manager and here.

Changes

• Changed messages from console to comms.
• Updated license to remove the "Thargoid clauses" after Thargoid allowed modification when retired from maintaining his OXps (viewtopic.php?f=4&t=17085).

[Cholmondely]

I usually place much more importance in the in-universe story consistency than in how we might implement it... ASC shouldn't be omniscient, so we have to explain how it gets the info for what it shows... I see several cases:

a) objects with fixed position (in the real world would be known and stable trajectories) listed in the system's almanac or player ship's nav computer: planets, moons, stations, waypoints
b) objects with a Navigation Beacon broadcasting their position (position in the broadcast signal payload)
c) objects with a simple beacon broadcasting a "locator" signal (no position in the signal payload, but it could carry some ID, broadcasting power, etc.): we could postulate ASC has directional receivers so it can tell the signal direction, and distance could be estimated from the signal intensity vs broadcasting power or triangulation (over time)
d) it could have a gravitic sensor and "see" objects depending on their mass/distance (like Telescope extension)
e) it could track any visible electromagnetic source, triangulate to get distance (we already postulated directional receivers) and tag with IFF info when in scanner range (as Telescope does for visible wavelengths)

I always thought ASC does (a) and (b), assuming a Navigation Beacon would always have broadcasting power to be "heard" across the system.

If Tracker uses (b) or (c), there would be a physical device that had to be attached to the tracked ship (we can postulate the device would broadcast with enough power to be heard across the system), you would have to be close to attach a tracker or recover a tracker, and you are right, it should be lost if the tracked ship jumps or is destroyed, so there should be a Tracker Pack for sale in Ship Outfitting.

If Tracker uses (d) or (e), yes, it's an upgrade of ASC hardware (the gravitic sensors or directional receivers, memory and processing power), you could define a tracker when in IFF range (to attach ID info to it), you could "remove" a tracker anytime, the ASC hardware would define the number of simultaneous trackers, but there should be a range limitation to the tracking.

Which would be more interesting for the gameplay, the player having to manage a physical supply of trackers, or having a range limitation on tracking?

Tracker is best used to keep tabs on moving objects (I usually use it to keep tabs on the Deep Space Dredger I have seen, so I can find them again easily - DSDs are the only place I can go to get those escape pods processed when I'm a fugitive), for static objects like derelicts I use Waypoint Here if I'm in a hurry, or "tag" them with a Towbar or EscortDeck beacon if I have the time (the EscortDeck being better because the beacon has a more descriptive label)

Very nice analysis!
I have a mild preference for the physical over the immaterial. It might also be nice if they were numbered or lettered* or whatever!

Assuming physicality, would there need to be a Tracker Projector fitted to a missile pylon - and should fuel scoops and a shorter maximum distance be needed for their retrieval (how do they fly back to my ship)? And, presumably you get your tracker back for free if your tagged derelict is recovered by the station and you then visit the shipyard there before leaving the system?

________________________________________________________________
*This of course assumes that Oolite can tell them apart!
When flying between planets in the Ensoreus System (as embellished by Spara & RedSpear's extra planets and orbital stations) some months ago, I spent some time merrily milking the Deep Space Dredgers strung out between several of the planets - and perforce noticed that the relationship between named planet, named orbital station and named DSD seemed fluid in the utmost! Or else Benedict has been spicing up my First Flush Darjeeling with a spot of lethal brandy!