• PB - programmable block.
  
• CD - Custom Data of the PB.
  
• Tag - part of a blocks Custom Name, usually put into [square brackets].
  
• Tracker turret - custom auto-stabilized "turret" on rotors, with a remote and cameras. Can be controlled manually through that remote.
  
• Target offsets - a set of points attached to a target in its coordinate space, represents sub-targets of interest (could be certain blocks or just points a user had painted with a raycast)
  
• Subscribers - PBs running compatible scripts which are interested in getting target data
  
• Target query - a mechanism for a subscriber to actively ask for target matching certain criteria (being in specific area, etc.)
  
• Target offers - a simplified data about a target exposed to potential subscribers
  
• Detaled Info (or echo) - PB printout in the right panel when you check it in the terminal UI.
  
• APck - AutoPillock script, PB that runs AutoPillock script.
  
• TGP - targeting pod script and its hardware (this one).
  
• CTC - Custom Turret Controller
  
• Command - a script argument. It can be several types - toggle, command, etc, but I would refer it as just command.
  
• Boot Sequence - commands/toggles placed into PB CustomData. They are ran immediately on recompile.
  
• Raycast - in-game mechanism of using a virtual ray to find objects by intersection, in the context of TGP means camera block raycast
  
• Designator - normal turret with ai enabled and marked to be used by TGP as targeting source

All blocks should be in the same terminal group with the PB (unless stated otherwise), group name does not matter.

Reference builds:
carrier control module blueprint
APckCommand control bridge (Core 1.0)

Group must have at least one controller block on the same grid as the PB (remote control or cockpit).

• Camera blocks
  
• Turrets (can be either in the main group, or just have "tgp" tag and be on the same grid)
  
• Custom Turret Controllers (can be either in the main group, or just have "tgp" tag and be on the same grid)
  
• Rotor blocks
  
• Remote control blocks (on a tracker turret topmost subgrid)

The last two points are required to have tracker turrets. To add them, start building from the rotor stator, add the second rotor for the second rotation plane, and on the last subrid add a remote and cameras. The rotors rest angles would be their zero marks, so if you want your tracker to be reset aligned with your ship forward direction, place both rotors in a way that their zero marks are pointing forward as well, and build a remote/cameras facing that direction too.
One (single) camera must have "tracker" tag, it would tell the code that it needs to initialize the tracker turret based on the grid that camera is placed on.
That camera would be the main one, add it to the remote control as the camera of choise for convenience.
You can (and should) have additional cameras so the tracker can maintain raycast tracking when needed.
Make sure the tracker turret has good coverage and that its cameras have no obstructions in +-45 degree cone.
If all good, after recompile you should see tracker turret counter in the Detaled Info.

Raycasting cameras can be placed anywhere, these tracker turrets just rotate them to have better coverage on targets.

TGP now supports pulling target data from WeaponCore mod. In case WC is detected, all other targeting options are being disabled (raycast, turret targeting, CTC, no target offsets, etc) due to WC limitations.


The whole purpose of TGP is providing targeting data. For that, it does the following:

TGP is global and would expose data to anything within antenna network. APck and HD can also be target providers on the same terms, but TGP is more advanced as a dedicated targeting script.


Turrets (automatic)
If TGP has turrets or CTC it would attempt to get data from them automatically. In case of success, it updates a target info, otherwise it uses raycast to refresh it. If the latter fails, the target is dropped after a short expiration period.
To enable scan mode for a specific turret, use command:set-offset-scan-designator-tag:{custom name part}. I.e. you can name a turret "Arty Turret 10 [scanner]" and have command:set-offset-scan-designator-tag:scanner in CD (Boot Sequence).

WeaponCore API (automatic)
If WC is detected, this would be the only way of getting target info.
Refer to WC documentation on how the target sensing works and what are the settings. You can use WC-based targeting mods for (supposedly) better target filtering options.
Use command "allow-target-relation" to allow non-hostile targets by white-listing target relation if needed (by default only hostile targets are accepted by TGP). The parameter is the relation enum value.
For example:
command:allow-target-relation:Neutral
command:allow-target-relation:NoOwnership

Raycasting (manual)
There are two separate raycast implementations - static and tracking.

Static is simple - it gets the point of ray intersection and saves it permanently (until you clear it with a command). It does not track and have no pruning (works with planet surface).
To use it, run command:static-cast (or press S while being inside a tracker turret). You don't have to look through camera (if you don't the direction would be deduced from your controller block).
The depth (length of the ray) would be based on raycast-range variable.

Tracking raycast would try to get a target and then update the target data (unless it is already tracked by AI turrets). That target can be lost.
To use it, run command:cast (or press E while being inside a tracker turret).

Important notes:

• Relations are checked, by default locking non-hostile grids is forbidden (toggle:lock-friendlies)
  
• Voxels are always forbidden (use a static cast for that)
  
• In case of miss, it would attempt to do a burst of raycasts around the initial direction (toggle:raycast-burst, enabled by default)
  
• In case it hits the hit relative position is added as an offset
  
• Tracked target would be picked to follow by one of these tracker turrets
  
• Added offset would be selected by default so a tracker turret would stick to the last point

To permanently remove selected target, use command:drop-and-ban (this would prevent that target from being locked on again). command:drop would remove target but allow it to be tracked again.

Target Offsets Manager
ToM stores two sets of offsets for every target - raycast and turret (the former are added by your manual raycasting, the latter are added by turrets scanning automatically).
If you do a raycast, the ToM would switch source to raycast automatically, but you can change that with a command at any moment.
The purpose of ToM is to "unpack" offsets into separate target entities which are presented to subscribers - you can have many targets to engage at the cost of tracking only one "real" target.

From TGP point of view, there are "target roots" (separate grids) and it has a selector marker for that, and in the scope of one target there are offsets (the second selector is for them).
"cycle-offset" command cycles offsets in the scope of the current target
"remove-offset" command removes current offset.
"save-offsets" commmand would permanently store offsets for the current target (based on entity id, so it won't work in the differnet world or if you copy-paste that target grid).
"next-target", "prev-target" commands switch the target root.

The default way of interop between TGP and subscribers is the Target Offers mechanism. It's a way of saying "hey I have these targets, pick one if you want".
GlobalSelector sets the way how tracked targets and their offsets are transformed into target entities for outside world. You can see the current setting in the Detaled Info (Selector: ...)
GlobalSelector default value is Everything. Possible values:
1. Selected - expose only curretly selected target offset (single target output). E.g. you want to focus everything on a specific point of certain target.
2. AllOffsets - expose all offsets of the current target. E.g. you want to spread-fire or kill all specific blocks of a single important target.
3. AllTargets - expose all target roots without offsets, i.e. simple Positions of all targets (in current game implementation that is the center of the target bounding box).
4. Everything - expose all offsets of all targets - engage all known offsets globally.

"set-selector:..." and "cycle-selector" commands are used to change that.

The other way is answering the target queries of other scripts (refer to APck documentation for more info). In this case the order in which targets are given, as long as criteria for selection, is full responsibility of the calling script, although the set to pick from is still controlled with the GlobalSelector (see above).

When you are using tracker turret through remote, your mouse/WASD input is intercepted. Mouse controls rotation, button presses trigger commands. Current bindings can be seen at the top of the code, now they look like this:

You can edit them to trigger any supported command/toggle (see commands reference). Or you can add toolbar actions as usual.