[WIP] Torus Field Monitor/Analyser - UPDATED 13/11

[alaric of rothestes]

NOTE:

13/11/16
Current WIP is linked to from this post


--- original post ---

For the impatient, here is the download link until I get set up on the wiki. Zipped .oxp folder.

This is an OXP which will warn of impending mass-lock and can also act as a pseudo long-range scanner of sorts (see details below - there are caveats). At the moment it is probably not going to sit to well with any OXPs which dodge around mass lock (like Norby's variable m/l and escort contracts), but I plan on accounting for them. I also plan on making this a piece of equipment (at the moment you just have it once the OXP is installed) available in two versions: The low-tech KV-16 Monitor which will provide mass-lock warning only, and the high-tech KV-32 Analyser which provides the long-range ident ability. I have no idea what price point or tech level to set, so any suggestions are welcome.

screenshot

Now, for a bit of backstory:

Backstory:

The backstory of the KV-32 is that mass-lock is a physical phenomenon, and not an imposed safety system. I have heard both explanations in the various Elite incarnations; I'm not sure which is considered Oolite canon. In my explanation, mass-lock occurs due to Torus field disturbances caused by large gravity wells (celestial objects) and emissions caused by other Torus field generators even when not in use (other ships).

The KV-32 Torus Field Analyser is a new piece of equipment from tech up-start Raeddi Systems. As well as being able to predict mass-lock, the KV-32 can also analyse the field signatures to determine probable IDs on the source of the disturbance. However!..

Due to {reasons}, GalCop has prohibited the sale of the KV-32 pre-loaded with torus field signature data. As a result, a freshly purchased KV-32 will identify any non-celestial object as an "Unidentified disturbance". Users of the KV-32 can register the field signature of other ships into the KV-32 by locking their ident system onto the object immediately after mass lock has occurred. Depending on the size of the disturbance, you may have anywhere from 2 - 15 seconds to do this before the signature decays too much to be correlated to any specific source. The KV-32 MFD will warn of signature decay when the bogie line starts blinking.

Developers note: It is worth mentioning at this point that the KV-32 does not "cheat". It really does have a signature library and can confuse similar size/mass ships with each other. like_ships will almost certainly be indistinguishable from each other, and in the early days when the library is small, it will frequently mis-identify ships. Accuracy increases as range decreases, so at long range you may find it, for example, marking Sidewinders and Star Boars as Vipers. Internally, the ship signature is correlated to its mass and collision-radius. Similar size ships will produce similar signatures.

Usage is fairly straightforward; no equipment needs priming. The MFD will display all the relevant information during (and for a few moments after) Torus cruise. When field disturbances are detected, the most immediate disturbance is displayed via a waypoint, along with the ASC beacon "m" (small m - for mass). A timer will also ping the console every second - though I am thinking of removing this for the MFD-enabled KV-32 (but retain in non-MFD KV-16).

If anyone has any suggestions on directions I could take this, love to hear them. Still working on refactoring the source a bit; some of it is heinous.

Regards,

alaric

[phkb]

This sounds intriguing! I'll try it out later today. A quick point, though -- in your manifest.plist file, the title reads: title = "Missing and Wanted Persons OXP"; - possibly a cut-and-paste issue, maybe? And your version number seems odd for a first release: 0.13.9? If that's correct then that's fine. It just seemed odd.

[alaric of rothestes]

This sounds intriguing! I'll try it out later today. A quick point, though -- in your manifest.plist file, the title reads: title = "Missing and Wanted Persons OXP"; - possibly a cut-and-paste issue, maybe? And your version number seems odd for a first release: 0.13.9? If that's correct then that's fine. It just seemed odd.

Lol. yep. Cut and paste. Well spotted. It's not so much a release yet as just a request for feedback - still much work to do!

[Norby]

Nice work!

What to do with variableMassLock: check if scanClass is CLASS_BUOY (all ships within scanner range get this until should not produce masslock) then look into the worldScripts["variablemasslock"].$VMShips 2 dimensional array for the original scanClass of that ship ([0] contain the ship itself, [1] hold the saved scanClass).

I suggest for performace that save worldScripts["variablemasslock"] into a script variable (your this.$option.variableMassLock is good for this, return false if my oxp is not present) right in startUp() then always use that instead of the worldScripts array which is very slow.

[alaric of rothestes]

Nice work!

What to do with variableMassLock: check if scanClass is CLASS_BUOY (all ships within scanner range get this until should not produce masslock) then look into the worldScripts["variablemasslock"].$VMShips 2 dimensional array for the original scanClass of that ship ([0] contain the ship itself, [1] hold the saved scanClass).

Thanks! Saves me some work digging through your code! I might do some start-up checks to make sure this array exists, just in case you ever change your implementation.

I suggest for performace that save worldScripts["variablemasslock"] into a script variable (your this.$option.variableMassLock is good for this, return false if my oxp is not present) right in startUp() then always use that instead of the worldScripts array which is very slow.

Thanks for the tip. I remember reading this was the case, but had forgotten!

Regards,

alaric

[maik]

For the impatient, here is the download link until I get set up on the wiki.

Done.

[alaric of rothestes]

Thank you maik, much obliged!

I will update the link with the next WIP once I have finished making some alterations:

• * add a "warm-up" period so the player can't cheat by hitting 'J' quickly to scan for ships (I currently do this, so I'm screwing myself here). The warm up period will probably last until the drive hits full speed, so a second or so.
  * adding an auto shutdown to shut down the drive if the player gets within a few seconds of impact with an asteroid.
  * Adding support to work with Norby's variablemasslock.

Regards,

alaric

[phkb]

I've enjoyed using this quite a lot. Apart from the exploit mentioned already I'd add the following comments:

1. I don't think you need to show time updates in tenths of seconds. Leave it at "X seconds". Tenths are irrelevant and a distraction.

2. The console messages that appear when within 65 seconds of shutdown are very "spam" like, in that my console feed feels like it's being spammed by shutdown messages. It probably doesn't need to be updated every second under 65 seconds. Perhaps every 10 seconds until 20 seconds to go, then 5 second intervals to 10 seconds, then 1 second intervals.

3. What's the range on this thing? It feels like it's a very long way, with gravity wells showing up right from the witchpoint. Do ships show up at that distance? If so (and it may already do this!) perhaps limit the range on ships, by mass or some other intrinsic factor, to be much closer to the player. Smaller ships should only appear in the list when they are closer to the player, larger ships further away, stations further away still, but I shouldn't be able to get a read on the mainstation from the witchpoint. At least, that's my take on it.

Regardless, this it an outstanding addition to the game. Well done!

[Norby]

Smaller ships should only appear in the list when they are closer to the player

Maybe use the isVisible property: the core game set it at about 2-4x scanner range depending on ship size.

[alaric of rothestes]

I've enjoyed using this quite a lot. Apart from the exploit mentioned already I'd add the following comments:

2. The console messages that appear when within 65 seconds of shutdown are very "spam" like, in that my console feed feels like it's being spammed by shutdown messages. It probably doesn't need to be updated every second under 65 seconds. Perhaps every 10 seconds until 20 seconds to go, then 5 second intervals to 10 seconds, then 1 second intervals.

Good idea. Added to my todo list.

3. What's the range on this thing? It feels like it's a very long way, with gravity wells showing up right from the witchpoint. Do ships show up at that distance? If so (and it may already do this!) perhaps limit the range on ships, by mass or some other intrinsic factor, to be much closer to the player. Smaller ships should only appear in the list when they are closer to the player, larger ships further away, stations further away still, but I shouldn't be able to get a read on the mainstation from the witchpoint. At least, that's my take on it.

The version in the OP has no range limit (which was useful for testing purposes). I have now added a range limit based upon ship mass and radius. The range is measured in seconds of torus time - this way your thinking-time is the same regardless of ship speed. There is also an inverse-square thing going on, so four Cobra IIIs in close proximity (within mutual mass-lock range of each other) will be detectable at about twice the range of a single Cobra III.

I dont have the figures at hand right now but, IIRC, a single small ship like a hognose will only be picked up 6 or 7 seconds out. Pythons and Boas are in the 30-60 seconds range. I think the main Station can still be picked up at the witchpoint, but fiddling with the equations is not too difficult.

I will see if I can get another working WIP up when I get home tonight, but I have broken some features which need to be fixed (a few Infinity.NaN seconds being displayed and Gravity wells are broken)

Regardless, this it an outstanding addition to the game. Well done!

Thank you! Quite a compliment coming from yourself. I have always considered your OXPs a cut above, especially in the attention to detail.

[phkb]

One other thing I noticed. If you drop out of torus because of a ship, then repoint your ship away from the target and use injectors to get clear of the masslock, quite often you can re-engage torus before the KV-32 has finished expiring data. It then goes through a couple of iterations of updating the MFD in funny ways before stabilising again.

I have always considered your OXPs a cut above, especially in the attention to detail.

Thanks! I'm glad you've found them useful. I have to say I'm pretty taken with your tabular text function. If I hadn't already coded up all the screens in Ship Configuration I think I'd be using your code for the job!

[alaric of rothestes]

As promised earlier today (or yesterday or tomorrow, depending on your time zone), WIP 2 of the Torus Field Monitor is now available:

http://wiki.alioth.net/index.php/File:T ... -wip-2.oxz


There are still quite a few issues, many cosmetic and some mentioned above which have not yet been specifically addressed, but the basic functionally is there.

Updates in this version:

• General improvements in the code flow. A lot more data is now cached once generated. I'm doing this by attaching my own property ("$" + script.name) to each Entity, which is an object containing the cached data for the Entity. I don't know if this is frowned upon (cim?), but it works, so I do it (until someone tells me why I shouldn't - again (cim?)).
• The monitor now only activates once the player ship hits "Torus Cruise" - 32 x player.ship.maxSpeed
• Introduction of the built-in TCAS (Torus Collision Avoidance System) which will shut-down the Torus drive if an imminent collision (2 seconds) with a non mass-locking object is detected. TCAS, like the monitor, only activates after Torus cruise speed has been reached, so you can still slam into an object by engaging from a short distance. This still needs a bit of cosmetic finessing but the functionality is there.
• Multiple disturbances are now tracked simultaneously. There is currently no way to identify the primary disturbance unless the ASC is switched to Torus Field Disturbances - this will eventually be fixed. Multiple-disturbance tracking will also only be available in the hi-tech KV-32 model. The low-tech KV-16 will be restricted to one disturbance.
• Disturbances are now indicated by (experimental) blinking waypoints achieved by (sometimes) drawing multiple waypoints. I felt the original waypoint indicators weren't visible enough. Again, I don't know if this is clever, or asking for Bad Things (tm) to happen in the future (cim?).
• Detection range of field disturbances is now dependent on the mass, collisionRadius and quantity of ships in the affected area, loosely following an inverse-square law. Groups of ships may be detected at a longer range than the ability of the analyser to identify them individually (even if their signature is known), resulting in "Unidentified disturbances" until the range closes sufficiently.
• The accuracy of the analyser in identifying ships is now affected by the ships view-aspect to the player. Accuracy is near 100% if one of the major axis' of the ship is oriented towards the player ship, and varies as the ship rotates. Still fiddling with this one a bit. Stations are annoying as their rotation results in an oscillating discrepancy. I like this approach because it allows the savvy player indirectly infer additional information, such as whether this is likely a trader formation or something else...

Still TODO:

• Reduce frequency of console messages, and disable entirely if MFD is being shown.
• Store player-recorded ship signatures based upon shipDataKey so changes to the ship can be identified if the ships characteristics are altered by OXP or update.
• Waypoint management needs to be done properly. Please don't search the source for 'setWaypoint' - it's embarrassing.
• At long range, coalesce multiple "Unidentified disturbances", probably based on ship signatures and separation distances.
• Actually turn this into a piece of equipment, buyable in three versions:
  • KV-16 Monitor (no ident capability and other limitations)
  • KV-32 Analyser (the whole works)
  • KV-32 Upgrade kit (for owners of KV-16)

I'm open to suggestions on pricing and tech-level availability. As far a tech-level is concerned, I was thinking along the lines of:

TL 9 - 11 = KV-16
TL 12-13 = KV-32 upgrade kit only (no KV-16 availability)
TL 14+ = KV-32 (no KV-16 or upgrade kit availability)

I haven't done equipment before, so I don't know if it's possible to restrict available in this way, but I figure there must be some script magic which can do it. It's an interesting way to play with things... "Should I travel to a TL-14+ to find a KV-32, or buy a KV-16 and find a TL-12/13 to upgrade in"? KV-16 + Upgrade would, of course, cost more than a KV-32 outright.

Regards,

alaric.

[Redspear]

I haven't done equipment before, so I don't know if it's possible to restrict available in this way, but I figure there must be some script magic which can do it.

Hi Alaric, this is actually one of the few things I know how to do

If you reference a condition_script in [wiki]Equipment.plist[/wiki] and write the condition script file with the appropriate restrictions then it should work just fine.

Should you need any help, just ask.

[phkb]

A couple more things I've noticed in the latest version:

1. You haven't packaged everything into the correct format for an OXZ. You zip the files at the sub-folder level, not the parent level. You're one level too high. Don't zip the ".oxp" folder itself, zip the contents of the ".oxp" folder.

2. I've seen some bizarre waypoints appearing, some of which seem to follow me rather than another ship. I would've gone looking as to what's going wrong, but I didn't want to cause you any embarrassment! I've been working on other things so I haven't nailed down the conditions in which the strange waypoint behaviour kicks in, but I'll try to get to this shortly, if you don't work it out sooner.

[alaric of rothestes]

I haven't done equipment before, so I don't know if it's possible to restrict available in this way, but I figure there must be some script magic which can do it.

Hi Alaric, this is actually one of the few things I know how to do

If you reference a condition_script in [wiki]Equipment.plist[/wiki] and write the condition script file with the appropriate restrictions then it should work just fine.

Should you need any help, just ask.

Thank you! With your help I ended up figuring it out

2. I've seen some bizarre waypoints appearing, some of which seem to follow me rather than another ship. I would've gone looking as to what's going wrong, but I didn't want to cause you any embarrassment! I've been working on other things so I haven't nailed down the conditions in which the strange waypoint behaviour kicks in, but I'll try to get to this shortly, if you don't work it out sooner.

Hmmm... I guess this is possible as the location of the disturbances are calculated as player-relative vectors. I haven't seen this for myself but will look into as I try to overhaul the whole waypoint mess