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

[phkb]

A few additional thoughts after some more play time.

1. You don't need to put a waypoint of gravity wells (planets, suns, moons etc). In almost all cases the cause of the gravity well will be pretty obvious.

and

2. I don't think you need to put waypoints on anything. It makes it far too easy to meander down the space lane, watching out for any waypoints appearing, and adjusting course as required. Great for getting to the station faster, but bad for giving the player encounters. Besides, the MFD itself will show up any bogeys, so it's not as if the information is not there. By restricting the info to the MFD if becomes a bit harder to avoid some contacts. The KV32 goes from being something of a long range scanner, to an assistant that can notify you ahead of time that there is a ship ahead.

If you want to keep the waypoints then I would suggest adjusting their behaviour. Don't put waypoints on smaller ships. Restrict them to larger ships (Anaconda's, Boa's, and possibly Pythons). Only put up at most 1 waypoint, possibly to the nearest ship, or even the ship more directly ahead. If you really want to keep the waypoints then limit their use to larger ships (eg Anaconda's, Boa's, etc) - that is, only allow them to be used if the player is flying a larger ship. On smaller ships they aren't available. Handwavium could indicate that it requires large reserves of energy that only these larger ships can provide.

At least, if you could provide a switch to turn them off (using Svengali's Library OXP) that would be handy.

I'm looking forward to this OXP being completed. I mean, as complete as any piece of programming is - until the next update.

[Redspear]

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

Cool! And you're welcome

[alaric of rothestes]

A few additional thoughts after some more play time.

...snip discussion about waypoints ...

You raise some interesting points. My character is a courier/bounty hunter, so he has only ever used his KV-32 to find ships to intersect! In fact, the only reason I originally added waypoints at all is because I wanted to be able to use the ASC to locate disturbances. Since the ASC targets *entities*, assigning a beacon to the detected entity meant that you could only cycle to the mass-disturbance mode once a disturbance was detected, and it would reset to the previous mode if the KV switched to a difference disturbance - a major annoyance. Waypoints solved this by allowing me to keep a persistent "prime" waypoint which was always targeted by the ASC, and simply setting it's position to Infinity when not it use so you could still bring it up on the ASC before engaging the Torus.

I would definitely like to keep some kind of directional indicator. It occurs to me I could perhaps achieve the desired behavior using a "null" entity instead of a waypoint, but the one thing that nags at me is the same rational behind your "Modern Starts" OXP: Surely this far into the future, they can put a marker on the HUD? But I agree it's making it a bit too easy at the moment.

I might try and cook up a (relatively) quick waypointless version with ASC only using the null entity method. It's worth trying to see how it feels.

On a side note, I have added a new feature which helps address the too easyness... Once a target comes into the FOV of the analyser, there is a delay (1 second, but configurable - I might even tie it to ship service level) before the disturbance will be picked up. So if you suddenly turn your ship toward a disturbance which was previously not going to mass-lock, you may find yourself locked before the KV can pick up on it.

alaric.

[phkb]

Once a target comes into the FOV of the analyser, there is a delay (1 second, but configurable - I might even tie it to ship service level) before the disturbance will be picked up. So if you suddenly turn your ship toward a disturbance which was previously not going to mass-lock, you may find yourself locked before the KV can pick up on it.

That sounds like a good solution. I look forward to trying it out!

[alaric of rothestes]

Another weekend gone, and time for another update

Link to latest version (correctly packed OXZ this time - thanks, phkb!)

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

Major changes in this verison:

• Waypoints are now gone. The waypoint idea is dropped from the first release, but may be re-introduced later as an enhancement to the KV-32. You can still locate the nearest disturbance using the ASC - whether that be to run away or fly into it
• Less console spamming. As suggested up-thread, the console updates are less frequent at long ranges. The exact timing of messages can be adjusted via $option.consolePingIntervals in torus-field-monitor.js. There are still a few little bugs in this, with regard to skipping messages and when the time-to-mass-lock increases, but will be addressed shortly.
• The noise added to each ships Torus field signature is now dependent on both the target ship (as in the previous WIP) and player ship orientation (new to this version). This allows you to "tune" the analyser by rotating your ship to get a better signal, much like adjusting the antenna on an analog TV.
• The analyser will now record the min/max observed (noisy) signature of each bogey and perform ident based upon the average value. This allows you to increase accuracy by tracking the disturbance and rolling your ship around to find the sweet spot. Min/max values are reset if the bogey loses focus, so you must keep tracking the target(s). Makes for more accurate identification without giving it away for free. Which leads to...
• There is a now a delay from the time a ship enters the FOV of the analyser and the time it is registered. This means if you are maneuvering (as you would to "tune" the antenna, as above), you may encounter mass-lock with little or no warning.
• The KV-16 and KV-32 "equipment" is now listed for sale in the appropriate systems, though buying them won't do anything until the formal release - you still get the stuff for free with this OXP. The tech-level availability of the equipment is as described up-thread, with the exception that all Raeddi Systems Ltd. equipment is always available for purchase at Raeddi, Galaxy 4 at (not yet implemented) reduced prices.

Side note:

I was also thinking of making the equipment only available after a certain amount of game-time has elapsed. Since I am planning to release any/all equipment I author under the "Raeddi Systems" banner, I would like to create some sense of time/continuity and perhaps a little back-story for Raeddi Systems. So release intervals could be something like:

KV-16 - 3 game months
KV-32 - 1 game year
KV-16 upgrade - 1 game year + 3 game months

Thoughts? Would it be too frustrating for players to download an OXP only to find they can't use it until a later date?

Anyway,

Hopefully this will be the last, or at least penultimate, WIP before I have a release candidate! I think I'm at the point now of "finishing it off" with no more major changes to take place.

alaric.

[Smivs]

I was also thinking of making the equipment only available after a certain amount of game-time has elapsed. Since I am planning to release any/all equipment I author under the "Raeddi Systems" banner, I would like to create some sense of time/continuity and perhaps a little back-story for Raeddi Systems. So release intervals could be something like:

KV-16 - 3 game months
KV-32 - 1 game year
KV-16 upgrade - 1 game year + 3 game months

Thoughts? Would it be too frustrating for players to download an OXP only to find they can't use it until a later date?

You could probably check when the player has reached three months before making the equipment available, then offer upgrades at the other two time points.