Target System Plugins

This expansion introduces three equipment items that add more features to the player ship's targeting system. These items are intended to be compatible with any target selector the player prefers.

Dependencies

All of these items require some core Vanilla game equipment before they will work. This equipment must be functioning at all times. In other words, if the dependencies are damaged or missing, then the plugins will fail and they will let you know about it.

SRS

The Short Range Snapshot (SRS) counts the targets within the player ship's scanner range, divides them into seven categories and displays the tallies in its MFD. Additional tallies are appended when applicable.

Requires the Scanner Targeting Enhancement from the Vanilla game. Purchasable at Tech Level 12 or higher. Cost: 300 ₢.

SRS Categories

Hostile: all targets that are hostile toward the player ship

Outlaw: offenders and fugitives, including Thargoids

Neutral: traders, hunters, etc.

State: police and military

Cargo: cargo containers, escape capsules, metal fragments, derelicts, etc.

Rock: asteroids, boulders, splinters, rock hermits

Other: almost everything else (excludes wreckage and wormholes)

SRS Additional Tallies

The SRS will append some tallies of sub-categories for more specific targets on the same line as the relevant category, if applicable. For example, if there are 10 rocks and 4 of them are scoopable splinters, then the SRS will display the following:

 Rock: 10 ... 4 splinters.

The categories with additional tallies are as follows:

Outlaw: Thargoid

Cargo: Escape Capsule

Rock: Splinter

TMI

The Target Memory Interface (TMI) displays a list of up to eight of the most recently targeted objects sorted by distance from the player ship in its MFD. It can also indicate the category of each target if the SRS is installed.

Requires the Target System Memory Expansion from the Vanilla game. Purchasable at Tech Level 9 or higher. Cost: 200 ₢.

TMI Category Symbols

The TMI MFD can indicate the category of each target if the SRS is functioning. This information is displayed symbolically to save space for target names.

There are eight symbols:

!H!    Hostile
!O.    Outlaw
Nt-    Neutral
St/    State
-C-    Cargo
-R-    Rock
.o?    Other
???    Unknown

TBM

The Target Banking Module (TBM) is primeable equipment that utilises the SRS target categories as memory banking modes. The player can select a category on the SRS MFD with the mode button, then press the activate button to assign up to 8 targets at once to the memory bank through the TMI.

Requires the SRS and the TMI. Purchasable at Tech Level 12 or higher. Cost: 500 ₢.

Cascade Weapon Alert

All MFDs of functioning plugins will alert the player if a cascade weapon like the Quirium Cascade Mine is within the player ship's scanner range.

SRS and TMI Tips

The plugins will display some helpful information about themselves on their MFDs when no targets are listed.

Download

Downloadable through the in-game Expansions Manager or from File:Target-System-Plugins 0.81.oxz

Development History

It all started when I discovered the Target System Upgrade expansion by Andrey Belov (also known as "timer"). I noticed that the equipment's hostile/outlaw mode was not selecting Thargoid ships that were attacking other ships. I had some prior experience with Javascript, so I decided to modify one of the functions a bit. It started selecting the Thargoids and I was satisfied for a little while, but then I wanted to add more target modes and information on the equipment's MFD. One thing led to another and I ended up creating what is now known as the Short Range Snapshot.

The feature formerly known as the TSU Snapshot was almost ready to be part of a new release, which could have been the first update to the TSU in five years. However, the more I used and enjoyed the enhanced TSU, the more features I wanted. I also wanted to release an expansion that did not favour one piece of targeting equipment over another. I wanted compatibility with the Fast Target Selector at the very least.

I also became aware of some performance issues I had created by integrating an MFD that tallied five target modes at once with filtering code that was designed for one mode at a time. I had already replaced Andrey's MFD code and rewrote the primeable equipment event handlers, but now I was facing the challenge of modifying the code that actually made the targeting work, which I barely understood at the time. I still can't figure out how the sort by distance function works. Fortunately, I learned from the Oolite Javascript Reference for the System class that sorting by distance was built into some of its methods.

New ideas were occuring to me as I learned more about how to script Oolite expansions. The idea for the Target Memory Interface was the turning point. I decided to make a new expansion from scratch that I would call Target System Plugins. The goal was to add features to the player ship's targeting system that could be used with the player's preferred target selector in addition to the memory banking feature of the TMI.

I knew I had made the right decision after I discovered the wonders of the descriptions property list, which wasn't used in the TSU. It was the first part of the new expansion that I worked on, even before porting my Snapshot code. The TSP equipment was going to use a lot of strings, to put it mildly, which made descriptions.plist the best place for me to figure out the design of the frontend. For example, it was during my work on that property list that I realised I needed to have abbreviation symbols for the target modes in the TMI MFD, so that there would be enough room in the MFD to make it a useful frontend for the target memory bank. All of this happened before I wrote a single line of code for the TMI.

The next step was writing my own code that actually made the targeting work. My experience with modifying and testing the TSU's filter parameters (i.e. what to include and exclude in each target mode) would prove useful, but I wasn't confident until I did some more research into the filteredEntities method of the System class, the same method that Andrey used to get the targets from scanner range. I finally understood how that method was filtering the entities, which enabled me to write my own functions with similar functionality (pun not intended). This was the key to avoiding the performance issues from my previous work, as my entire expansion, even with three different pieces of equipment working simultaneously, would only need to call the filteredEntities method once per second. My own filtering code would do the rest.

I spent the next couple of weeks developing the expansion when another idea occurred to me. The first TMI design had two overall features: an MFD that served as a front end for the Target System Memory Expansion (TSME); and primeable equipment that would assign an entire category of targets from the SRS to target memory. I wondered if I was over-engineering the TMI, which was dependent on the SRS as well as the TSME (if either of them broke, then the TMI wouldn't work). The SRS also had its own dependency (the Scanner Targeting Enhancement), which meant that the TMI would fail if any of three other equipment items were broken or missing and the player would lose access to both features.

I decided to spin off the second feature into its own equipment item: the Target Banking Module. The TMI would only be dependent on the TSME as it was the front end for that equipment. The TBM would be dependent on the TMI and SRS, so only the most advanced feature would have the highest dependency stack (four equipment items in total). I was fortunate that the redesign only required a few changes to the code that I already wrote.

I finished the scripts on the 1st of February, 2019. The development history up to this point spanned approximately one month. Testing and debugging was about to begin.

I knew that writing everything before testing any of the functions was not a good idea, but my hubris got the better of me at the time. My lack of experience with the descriptions property list and string expansion did not help matters. I had not written the string expansion calls properly, because I had not read the reference material thoroughly. A lot of corrections were needed before my scripts would load at startup.

I had started working on another expansion pack for Oolite by this time, the Primeable Equipment MFD, because I wanted to make something less ambitious and time-consuming while testing this one. That was when the idea for the Hostile Awareness MFD occurred to me, but I would need to research the Vector3D class and learn about vectors in general before I could even begin working on that feature. My first project had become even more ambitious and time-consuming. I knew that my second project would be my first public release.

I was mistaken when I thought that the existing scripts were finished at the beginning of February, to put it mildly. The bugs in the TMI made it useless as a frontend for the TSME. One of the bugs took about a week to fix and I had to study the relevant parts of the core game's source code several times to figure out a solution. I was lucky that the syntax of Objective C was similar enough to Javascript that I could read it.

Unfortunately, it became apparent that the solution was not going to be enough. The Javascript engine does not provide enough access to event handlers like key presses to maintain the accuracy of the TMI list. It would not work as a complete TSME frontend. I decided to redesign the TMI to have less scope in a way that would be even more useful to the player.

The third incarnation of the TMI is an MFD that displays up to 8 targets at once sorted by distance from the player ship. This new design made my previous idea for the Hostile Awareness MFD redundant, since the TMI combined with the SRS can provide similar information, albeit without vector indicators. I decided to remove the Hostile Awareness MFD from my planned feature set.

This just leaves more testing and one more feature that would apply to all of my MFDs: a cascade weapon alert. This idea occurred to me after discovering the Quirium Cascade Mine Detector by User:Diziet Sma. I liked the general idea behind it, but disagreed with charging 5000 credits for an alarm.

License

License: Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) available at https://creativecommons.org/licenses/by-nc-sa/4.0/