Differences

This shows you the differences between two versions of the page.

--- gps_target_system:home [2026/10/05 12:29] – created rock
+++ gps_target_system:home [2026/10/05 12:29] (current) – rock
@@ Line 1: / Line 1: @@
-====== RKSL CVWP GPS HUD Integration Guide ======
+====== RKSL CVWP GPS System - Player Guide ======
-**Audience:** Arma 3 addon authors integrating the RKSL CVWP GPS/release system into a third-party aircraft display. **Reference state:** CVWP GPS V19E production cleanup, 5 October 2026. **Examples:** static HUD, helmet-mounted display (HMD), and UAV/sensor turret optics.
+**System:** RKSL Combined Vehicle Weapons Pack (CVWP) GPS Targeting System\\  **Audience:** Players / pilots / UAV operators\\  **Reference state:** V19E production GPS/release system\\  **Document date:** 5 October 2026
-===== 1. What you are integrating =====
+===== 1. What the GPS system does =====
-The GPS/release solver belongs to **rksla3-cvwp**. Your aircraft addon should only provide a presentation layer.
+The RKSL CVWP GPS system allows supported weapons to be programmed against a fixed point on the terrain and then provides aircraft-specific steering and release information.
+The same underlying GPS/release system may be presented in several different ways depending on the aircraft:
+  * a **fixed HUD** such as the Gripen C;
+  * a **helmet-mounted display (HMD)** such as the StavJet;
+  * a **UAV/sensor turret display** such as the MQ-9;
+  * a pilot release display or overlay where the aircraft provides one.
+The display may look different, but the target, release-envelope and weapon-guidance logic is shared.
+**Important:** A GPS target is a **coordinate in the world**, not a tracker attached to a moving vehicle. If the vehicle at that coordinate moves after the target is programmed, the weapon will continue to attack the programmed point.
+===== 2. Quick start =====
+For a normal single GPS-guided attack:
+  - Select the GPS-capable weapon you intend to use.
+  - Open the **RKSL GPS** panel.
+  - Select the required weapon in the GPS panel.
+  - Select **MAP TARGET**.
+  - Click the required target point on the map.
+  - Return to the normal flight view.
+  - Fly towards the target and use the GPS target cue, LAR/DLZ and XTRK cue to establish a valid release.
+  - Wait for **RDY** before releasing.
+  - Release the weapon.
+The weapon is programmed for the point selected on the map. For weapons using RKSL scripted GPS guidance, the weapon will steer towards that point after release.
+===== 3. Opening the RKSL GPS panel =====
+==== 3.1 Manned aircraft ====
+On normally crewed aircraft, use the Arma action menu and select:
 <code ->
-CVWP
+RKSL GPS
-  GPS target / queue
-  selected weapon binding
-  release constraints
-  dynamic RMIN / RMAX
-  release-ready state
-  scripted guidance
-        |
-        +--> Static HUD adapter (aircraft/HUD-relative)
-        +--> HMD adapter (head/view-relative target projection)
-        +--> UAV turret optics (CVWP-owned RscInGameUI resource)
 </code>
-Do **not** copy the CVWP GPS solver, queue code, release predictor or guidance loop into your aircraft addon. If you find yourself reimplementing weapon physics in the display addon, the integration has gone wrong.
+This opens the GPS programming panel.
-The aircraft/display addon owns only:
+The option is shown when the active aircraft has a loaded GPS-capable weapon.
-  * dependency on ''rksla3_cvwp'';
+==== 3.2 UAVs - important control limitation ====
-  * display geometry and styling;
-  * local MFD/HMD user-channel allocation;
-  * projection appropriate to that display type;
-  * platform-specific FOV/gimbal tuning where required.
-===== 2. Requirements =====
+When remotely controlling a UAV, the normal Arma action menu is not reliable for accessing vehicle-specific GPS actions.
-Your addon must load after CVWP:
+This is an Arma remote-control limitation: the action menu can remain associated with the player's physical unit rather than the remotely controlled UAV.
-<code cpp>
+For UAVs, use the vanilla **Communication menu** instead.
-class CfgPatches
-{
+With the default Arma command-menu keys:
-    class MyAircraft_CVWP_GPS_Patch
-    {
+<code ->
-        requiredAddons[] =
-        {
+  -> 8 Communications
-            "MyAircraft_Base_Addon",
+       -> RKSL GPS Panel
-            "rksla3_cvwp"
-        };
-        units[] = {};
-        weapons[] = {};
-    };
-};
 </code>
-For aircraft ''class MFD'' integrations, ensure ''mfdMaxUserValues'' is large enough for the channels you allocate. The supplied static/HMD examples use channels up to ''user206'', so use at least:
+In short:
-<code cpp>
+<code ->
-mfdMaxUserValues = 207;
+> 8 > RKSL GPS Panel
 </code>
-If the aircraft already has a larger value, **do not reduce it**.
+Once the panel is open, it works in the same way as it does in a manned aircraft.
-The selected ammunition must participate in the CVWP GPS system. For CVWP weapons this is generated by the Config Factory. The basic capability marker is:
+**Do not assume that the absence of ''RKSL GPS'' from the scroll/action menu means the UAV is incompatible.** Try the Communication-menu route first.
-<code cpp>
+===== 4. The GPS panel =====
-RKSLGPS = 1;
+When the panel opens, it first displays the GPS-capable weapons currently loaded on the active aircraft.
+Only supported, loaded GPS weapons are listed.
+You can select a weapon using:
+  * the side soft keys;
+  * the up/down controls followed by **SEL**;
+  * the corresponding clickable row where available.
+After selecting a weapon, the targeting menu offers:
+^ Option ^ Purpose ^
+| MAP TARGET | Program one target by clicking the map. |
+| MANUAL GRID | Enter one target using a grid reference. |
+| QUEUE MAP | Program a sequence of targets by clicking the map. |
+| QUEUE GRID | Program a sequence of grid targets manually. |
+| CLEAR TARGETS | Remove the stored GPS target/queue. |
+| BACK | Return to the weapon list. |
+===== 5. Programming a single map target =====
+To program one target:
+  - Open **RKSL GPS**.
+  - Select the weapon you intend to release.
+  - Select **MAP TARGET**.
+  - The GPS panel closes and the Arma map opens.
+  - Click once on the required target position.
+  - The map closes and the target is stored for that weapon type.
+The target cue should then appear on the aircraft's supported HUD/HMD/UAV display.
+==== Important: targets are weapon-bound ====
+GPS targets are bound to the ammunition type selected when the target is programmed.
+For example:
+  - program a target while GBU-32 is selected;
+  - change to another weapon;
+  - the GBU-32 target remains stored, but the other weapon does not automatically inherit it;
+  - reselect the GBU-32 and its target becomes active again.
+This prevents one weapon type from accidentally consuming another weapon's GPS target.
+On displays that show weapon-selection diagnostics, you may see a difference between the weapon that is **CUED** and the weapon currently **SELECTED**.
+===== 6. Programming a target by grid =====
+Select:
+<code ->
+MANUAL GRID
 </code>
-Guided-ballistic and glide weapons require the appropriate additional CVWP guidance profile; do not invent those values in the aircraft HUD patch.
+The GPS panel accepts:
-===== 3. Public display API =====
+  * 4-digit grids;
+  * 6-digit grids;
+  * 8-digit grids;
+  * 10-digit grids.
-For bespoke HUD/HMD integrations, use:
+Enter the grid using the panel keypad and press:
-<code sqf>
+<code ->
-private _solution = [_vehicle] call RKSLA3_CVWP_fnc_targetCueGetSolution;
+ENT
 </code>
-''targetCueGetSolution'' is the canonical display source. Treat it as an append-only array and read fields with ''param'' defaults rather than assuming every older CVWP build has every extension.
+to store the target.
-^ Index ^ Field ^ Type ^ Notes ^
+In single-grid entry mode:
-| 0 | active | BOOL | Valid selected weapon + active target |
-| 1 | source | STRING | Currently ''GPS'' or ''NONE'' for this use |
-| 2 | targetASL | ARRAY | World target position ASL |
-| 3 | range | NUMBER | Slant range in metres |
-| 4 | offBore | NUMBER | Release/off-boresight angle in degrees |
-| 5 | releaseReady | BOOL | CVWP release decision |
-| 6 | constraint | STRING | ''OK'', ''RNG'', ''ANG'', ''ALT'', etc. |
-| 7 | queueIndex | NUMBER | Current queue item |
-| 8 | queueCount | NUMBER | Original queue count |
-| 9 | queueText | STRING | e.g. ''Q 2/4'' |
-| 10 | weapon | STRING | Selected weapon class |
-| 11 | magazine | STRING | Selected magazine class |
-| 12 | ammo | STRING | Resolved ammunition class |
-| 13 | tof | NUMBER | Predicted time of flight, when available |
-| 14 | predictedMiss | NUMBER | Predictor output |
-| 15 | allowedMiss | NUMBER | Allowed predictor miss |
-| 16 | predictedCorrectionDemand | NUMBER | Normalised pre-release correction demand |
-| 17 | requiredAlongCorrection | NUMBER | Metres |
-| 18 | requiredCrossCorrection | NUMBER | Metres |
-| 19 | naturalImpactASL | ARRAY | Predicted unguided impact point |
-| 20 | dynamicRMin | NUMBER | Current shared near release boundary |
-| 21 | dynamicRMax | NUMBER | Current shared far release boundary |
-| 22 | usableAuthority | NUMBER | Usable guidance authority fraction |
-| 23 | longitudinalDemandSigned | NUMBER | Signed normalised demand |
-| 24 | lateralDemandSigned | NUMBER | Signed normalised demand |
-For normal production presentation, most integrations only need indices **0-6, 10-13, 20 and 21**.
+  * **ENT** stores the target;
+  * **CLR** clears the current grid-entry box;
+  * **SEL** returns to the previous menu.
-===== 4. Common release symbology =====
+===== 7. Target queues =====
-The validated aircraft displays use the same basic information even though they project it differently:
+A queue allows several GPS weapons of the same ammunition type to be programmed against a sequence of target points before the attack.
-  * **GPS target gate** — world target cue.
+Targets are used in the order in which they were entered.
-  * **LAR/DLZ rail** — short upper/far tick, vertical rail, short lower/near tick, moving current-range marker.
-  * **XTRK rail/cursor** — cross-track steering/alignment cue.
-  * **RDY / INH** — use CVWP's ''releaseReady'' and ''constraint'' directly.
-  * **RNG** — current target range.
-The display rail does not make the release decision. ''releaseReady'' remains authoritative.
+After a weapon consumes the current queued point, the GPS system advances to the next point.
-For ballistic/glide stores, prefer CVWP's ''dynamicRMin'' / ''dynamicRMax''. For powered/native GPS stores that do not publish a dynamic ballistic envelope, an aircraft adapter may use the configured release min/max as a **presentation-only fallback** by calling:
+Where the aircraft display supports queue information, the cue may show progression such as:
-<code sqf>
+<code ->
-private _release = [_weapon,"","",_ammo,_magazine] call RKSLA3_CVWP_fnc_gpsReleaseSettings;
+Q 1/4
+Q 2/4
+Q 3/4
+Q 4/4
 </code>
-Do not use the fallback to override a CVWP release inhibit.
+==== 7.1 Queue Map ====
-===== 5. Static HUD integration =====
+Select:
-A static HUD is physically attached to the aircraft. The GPS cue must move when the **aircraft** moves, not when the pilot free-looks.
+<code ->
+QUEUE MAP
+</code>
-The tested reference is the Gripen C implementation.
+The map opens and asks you to click target points.
-==== 5.1 Confirm the HUD is static ====
+**Important quirk:** Map queue mode is based on the number of remaining rounds of the selected GPS ammunition.
-The active HUD class should use the model's combiner memory points and should not be configured as an HMD:
+If you have six suitable weapons loaded, the system can ask for six map clicks.
-<code cpp>
+The map queue is committed when the requested number of points has been entered.
-topLeft = "hud_tl";
-topRight = "hud_tr";
-bottomLeft = "hud_ll";
-enableParallax = 0;
-helmetMountedDisplay = 0;
-</code>
-Use the actual memory-point names from your model.
+If you only want a shorter queue, **QUEUE GRID** is usually the more convenient method because it can be committed after entering fewer targets.
-==== 5.2 Register a local adapter ====
+==== 7.2 Queue Grid ====
-The example package contains:
+Select:
 <code ->
-cvwp_gps_static_hud_example/
+QUEUE GRID
-  config.cpp.example
-  functions/fn_staticHudInit.sqf
-  functions/fn_staticHudUpdate.sqf
-  includes/cvwp_gps_static_bones.hpp
-  includes/cvwp_gps_static_draw.hpp
 </code>
-The adapter reads ''targetCueGetSolution'' and publishes local ''user'' / ''userText'' values. It does not modify CVWP.
+Enter each grid and press **ENT**.
-==== 5.3 Merge the MFD bones and draw group ====
+The panel advances to the next queue position after each valid entry.
-Inside the **existing static HUD MFD class**, merge the supplied bones into ''class Bones'' and the supplied draw group into ''class Draw''.
+When you have entered the targets you want, press:
-Do not replace the aircraft's whole ''class MFD'' just to add CVWP symbology.
+<code ->
+SEL
+</code>
-==== 5.4 Use airframe-relative projection ====
+to commit the queue.
-The critical rule is: **do not use ''worldToScreen'' for a fixed HUD target gate**.
+You do not have to fill every available weapon slot before committing a grid queue.
-The example converts the target line-of-sight into the aircraft's forward/right/up frame:
+**CLR** clears the currently selected queue entry rather than deleting the entire queue while you are still editing it.
-<code sqf>
+===== 8. Clearing targets =====
-private _los = vectorNormalized (_targetASL vectorDiff (getPosASL _veh));
-private _forward = vectorNormalized (vectorDir _veh);
-private _up = vectorNormalized (vectorUp _veh);
-private _right = vectorNormalized (_forward vectorCrossProduct _up);
-private _f = _los vectorDotProduct _forward;
+From the targeting menu select:
-private _r = _los vectorDotProduct _right;
-private _u = _los vectorDotProduct _up;
+<code ->
+CLEAR TARGETS
 </code>
-It then converts horizontal/vertical angles to local HUD coordinates.
+or use **CLR** when you are not inside a grid-entry field.
-==== 5.5 Calibrate the HUD angular scale ====
+This removes the active GPS target/queue.
-If your existing HUD has a known angular bone such as a ''Pos10Vector'', measure the local coordinate displacement for 10 degrees and divide by 10.
+The **PWR** button only closes the GPS panel. It does **not** clear the stored GPS target.
-Example vehicle hooks supplied by the plugin:
+This distinction matters with dual-mode weapons: clearing the GPS target may allow the weapon to return to its normal non-GPS seeker mode.
-<code cpp>
+===== 9. Dual-mode weapons =====
-CVWPGPS_StaticHUD_XPerDegree = 0.0725;
-CVWPGPS_StaticHUD_YPerDegree = 0.0600;
-CVWPGPS_StaticHUD_EdgeMargin = 0.045;
-</code>
-These are **display calibration values**, not weapon physics.
+Some weapons can use more than one guidance mode.
-==== 5.6 Static HUD acceptance test ====
+The GBU-54/B is an example of a weapon that can retain native laser capability while also supporting the RKSL GPS system.
-  - Hold the aircraft steady and free-look left/right/up/down: the GPS gate must remain fixed to the aircraft HUD.
+When a valid GPS target is programmed for the selected ammunition, GPS has priority for that release.
-  - Turn the aircraft: the gate must move across the HUD.
-  - Roll/pitch the aircraft: the cue must remain registered to the target through the HUD geometry.
-  - Fly through the LAR: range marker should cross FAR, move through the valid zone, then cross NEAR.
-  - Release a GPS weapon: guidance behaviour must be unchanged.
-If the cue follows the pilot's head, you have accidentally implemented HMD/screen-space projection rather than a static HUD.
+If you want to use the weapon's non-GPS mode instead:
-===== 6. Helmet-Mounted Display (HMD) integration =====
+  - clear the GPS target for that weapon;
+  - establish the required native/laser target;
+  - release using the normal weapon procedure.
-An HMD is different: the target cue is world-registered to the pilot's current view. The tested reference is the StavJet implementation.
+Changing weapon selection is not the same as clearing a stored GPS target.
-The clean separation is:
+===== 10. Reading the GPS release symbology =====
-  * **world-locked:** GPS target gate;
+Exact layout depends on the aircraft, but the production system uses the same basic information.
-  * **helmet-fixed:** LAR, XTRK, RDY/INH and RNG;
-  * **aircraft-derived:** XTRK/release geometry values, even though their symbols are drawn in helmet space.
-==== 6.1 Confirm the target display really is an HMD ====
+==== 10.1 GPS target gate ====
-Use the aircraft's existing helmet-mounted MFD/HMD class. Do not convert a static HUD into an HMD just to make the GPS cue easy to draw.
+The target gate marks the programmed GPS coordinate.
-==== 6.2 Register the HMD adapter ====
+It is a **point-designation cue**, not a moving-target tracker.
-The example package contains:
+Its presentation depends on the display type:
-<code ->
+  * **Static HUD:** the gate is projected relative to the aircraft and physical HUD. Free-look does not steer it around the HUD.
-cvwp_gps_hmd_example/
+  * **HMD:** the gate is world-locked. As you turn your head, the gate moves through the helmet display according to where the target is in the world.
-  config.cpp.example
+  * **UAV turret:** the gate is presented in the sensor/turret display according to the turret optics implementation.
-  functions/fn_hmdInit.sqf
-  functions/fn_hmdUpdate.sqf
-  includes/cvwp_gps_hmd_bones.hpp
-  includes/cvwp_gps_hmd_draw.hpp
-</code>
-==== 6.3 Project the world target every rendered frame ====
+==== 10.2 LAR / DLZ ====
-For an HMD, ''worldToScreen'' is appropriate because the pilot's view direction is part of the display geometry:
+The LAR/DLZ is the weapon's **Launch/Release Acceptability Region**.
-<code sqf>
+In the current aircraft implementations it is shown as a vertical release-range rail.
-private _screen = worldToScreen (ASLToAGL _targetASL);
-</code>
-The example updates target X/Y every frame but throttles the heavier CVWP release solution refresh. This avoids visible stepping without running the full solver unnecessarily at render rate.
+The upper and lower boundaries represent the usable release-range window for the current weapon and flight condition.
-==== 6.4 Keep release symbology helmet-fixed ====
+A moving marker represents the aircraft's current range position within or around that window.
-Do not parent the LAR and status block to the moving target gate. LAR/XTRK/status should remain at fixed HMD coordinates while the world target gate moves as the pilot turns their head.
+The LAR can change as:
-==== 6.5 HMD acceptance test ====
+  * speed changes;
+  * altitude changes;
+  * heading/geometry changes;
+  * the selected weapon changes.
-  - Keep aircraft attitude constant and move the pilot's head: the GPS gate must track the world target.
+For guided ballistic and glide weapons, the system calculates the release envelope from the weapon's predicted flight and available guidance authority rather than relying on one fixed range value.
-  - LAR/XTRK/status must stay in the same helmet position.
-  - Look away far enough: the target gate should clip/hide cleanly at the useful HMD boundary.
-  - Re-centre the view: the gate should return to the correct target position.
-  - Aircraft manoeuvre must still change XTRK and release state because those values are aircraft-relative.
-===== 7. UAV / turret optics integration =====
+**Being visually inside the LAR does not override another active constraint. Always confirm ''RDY''.**
-For a UAV sensor turret, do **not** build another copy of the MQ-9 HUD scripts. CVWP owns a reusable sensor-operator optics resource.
+==== 10.3 XTRK ====
-CVWP provides:
+XTRK is the cross-track steering cue.
-<code cpp>
+It shows whether the target lies left or right of the current attack/release path.
-RKSLA3_CVWP_UAVHUD_GunnerOptics
-RKSLA3_CVWP_UAVHUD_PilotReleaseOverlay
-</code>
-and the function/runtime namespace:
+For the best release:
+  * fly the XTRK cursor towards the centre of its rail;
+  * avoid making large last-second heading changes;
+  * then confirm the release state.
+The production displays deliberately omit an ''XTRK'' text label on some aircraft; the horizontal rail/cursor itself is the cue.
+==== 10.4 RNG ====
+''RNG'' is the current range to the active GPS target.
+Depending on the aircraft it may be shown in metres or kilometres.
+==== 10.5 TOF ====
+Where fitted, ''TOF'' is the estimated weapon time of flight from a release made at the current condition.
+Not every aircraft display shows TOF.
+==== 10.6 RDY and INH / INHIBIT ====
+''RDY'' means the CVWP release solver considers the current weapon/target geometry valid for release.
+''INH'' or ''INHIBIT'' means one or more release conditions are not currently satisfied.
+**Important:** INHIBIT is a release advisory, not necessarily a physical trigger lock. Arma may still allow you to drop or fire the weapon. Releasing while inhibited can result in a miss.
+===== 11. Common inhibit reasons =====
+Some aircraft show a short constraint code beside the release state.
+^ Code ^ Meaning ^ What to do ^
+| OK | Current GPS release solution is acceptable. | Release when required. |
+| NO TGT | No valid target is available for the selected weapon. | Program a target or select the weapon for which a target is already stored. |
+| RNG | Target is outside the current usable release range. | Continue the approach or reposition until the LAR/release state becomes valid. |
+| ANG | Target is outside the permitted off-boresight geometry. | Turn/reposition the aircraft towards the target. |
+| ALT | Release altitude/height condition is not valid. | Gain altitude or change the attack profile. |
+| SPD | Aircraft speed is too low for the current release solution. | Increase speed or change the attack profile. |
+| TOF | Predicted flight time is outside the allowed solution. | Reposition and establish a more suitable release. |
+| MISS | Predicted weapon correction/miss requirement is outside the accepted envelope. | Improve alignment/range rather than forcing the release. |
+| SAFE | Weapon/system state is not armed/available where the aircraft integration uses this status. | Arm/select the required weapon state. |
+| LOCK | A weapon requiring lock/seeker confirmation has not reached a valid lock state. | Maintain the designation/geometry and wait for confirmation. |
+| GMBL | UAV/sensor gimbal geometry is at or beyond a usable limit. | Re-slew or reposition the aircraft. |
+| STALE | Stored targeting information is no longer considered current where this state is used. | Re-program or refresh the target. |
+| QUEUE | A queue exists but there is no usable current queued target. | Check the queue/weapon selection. |
+Not every weapon or aircraft uses every code.
+===== 12. Recommended attack technique =====
+For GPS bombs and glide weapons:
+  - Program the target before the final attack run.
+  - Select the same weapon type used when the target was programmed.
+  - Approach with the target generally ahead of the aircraft.
+  - Use XTRK to reduce lateral error.
+  - Watch the LAR as you approach.
+  - Wait for **RDY**.
+  - Release without a large abrupt manoeuvre at the moment of release.
+  - Allow the weapon to fly; do not expect the GPS point to follow a moving target.
+For powered GPS weapons, the exact appearance of the release cue may differ, but the same rule applies: use **RDY** and the displayed constraint rather than range alone.
+===== 13. Static HUD operation =====
+On a conventional fixed HUD, such as the Gripen C:
+  * the GPS target gate is calculated relative to the aircraft;
+  * the gate stays attached to the physical HUD presentation during free-look;
+  * aircraft manoeuvre moves the target cue;
+  * the LAR, XTRK, release state and range are fixed HUD symbology.
+If you free-look and the GPS symbology follows your head like a helmet display, that is an aircraft-integration fault rather than normal GPS behaviour.
+===== 14. HMD operation =====
+On an HMD-equipped aircraft, such as the StavJet:
+  * the GPS target gate is world-locked;
+  * turning your head moves the target through the HMD field of view;
+  * the gate may disappear when the target is outside the useful HMD field;
+  * the LAR, XTRK and status information remain helmet-fixed rather than being attached to the target.
+This is intentional.
+The target cue tells you **where the programmed point is**. The fixed release cues tell you **whether the aircraft/weapon can usefully release against it**.
+===== 15. UAV / sensor-turret operation =====
+A UAV may present more information than a fighter HUD, including target data, sensor state, gimbal state, FOV and release information.
+The full turret/sensor display is intended for the UAV sensor operator view.
+A separate pilot/driver display may contain a reduced set of release information depending on the aircraft.
+==== 15.1 Opening GPS while remotely controlling a UAV ====
+The most important UAV-specific quirk is the GPS-panel access method.
+Do not rely on the normal action/scroll menu while remotely controlling a UAV.
+Use:
 <code ->
-RKSLA3_CVWP_fnc_uavHud*
+> 8 > RKSL GPS Panel
-RKSLA3_CVWP_UAVHUD_*
 </code>
-==== 7.1 Create a thin optics wrapper ====
+This opens the same GPS panel against the active UAV platform.
-<code cpp>
+==== 15.2 Gimbal limits ====
-class RscInGameUI
-{
-    class RKSLA3_CVWP_UAVHUD_GunnerOptics;
-    class MyUAV_GunnerOptics: RKSLA3_CVWP_UAVHUD_GunnerOptics
+In a UAV turret, a target can be valid as a GPS coordinate while the sensor itself is reaching a gimbal limit.
-    {
-        // Vehicle-specific visual overrides only.
-    };
-};
-</code>
-==== 7.2 Assign the wrapper to the actual sensor turret ====
+Typical states include:
-Merge into the target addon's real resolved turret hierarchy:
+^ State ^ Meaning ^
+| GMBL OK | Sensor geometry is normal. |
+| GMBL WARN | Sensor is approaching a gimbal limit. |
+| GMBL LIM | Sensor is at/near a hard limit and aircraft repositioning may be required. |
-<code cpp>
+Reposition the UAV rather than forcing the turret against its limits.
-turretInfoType = "MyUAV_GunnerOptics";
-</code>
-Do not blindly replace the entire ''Turrets'' block; preserve inherited weapons, optics, stabilisation, animation sources and sensors.
+===== 16. Map-input conflicts =====
-==== 7.3 Opt in to the CVWP UAV HUD API ====
+The GPS system shares Arma's map with other RKSL systems.
-<code cpp>
+Only one RKSL system can own map-click input at a time.
-RKSLA3_CVWP_UAVHUD_APIRequired = 1;
-</code>
-Optional pilot overlay:
+For example, on the StavJet, the NAV system and GPS targeting can both request a map click.
-<code cpp>
+If the GPS panel reports:
-RKSLA3_CVWP_UAVHUD_EnablePilotOverlay = 1;
-RKSLA3_CVWP_UAVHUD_PilotOverlayClass = "MyUAV_PilotReleaseOverlay";
+<code ->
+Map input busy.
 </code>
-If you only need the turret/sensor HUD, leave the pilot overlay disabled.
+finish or cancel the other map operation first, then reopen GPS targeting.
-==== 7.4 Platform tuning ====
+Closing the map without selecting a point cancels the current GPS map-capture operation and releases the map for later use.
-The UAV framework supports platform-local projected-gate tuning. Start with the reference values only if needed:
+===== 17. Map-marker fallback =====
-<code cpp>
+The GPS system also supports map-marker targeting as a fallback.
-RKSLHudProjectedGateTransformMode = 4;
-RKSLHudProjectedGateSmoothing = 0.18;
+This is particularly useful when the normal panel/action path is awkward.
-RKSLHudProjectedGateDeadzone = 0.003;
-RKSLHudProjectedGateMaxStep = 0.08;
+==== 17.1 Single target marker ====
-RKSLHudProjectedGateResetDistance = 15;
+Create or move a map marker named:
+<code ->
+rkslgps
 </code>
-Keep platform tuning in the UAV addon. Do not fork ''fn_uavHud*.sqf''.
+or:
-==== 7.5 UAV acceptance test ====
+<code ->
+rksl_gps
+</code>
-  - Enter the sensor turret and verify the CVWP optics load without RPT errors.
+The marker position becomes the active GPS target for the current GPS weapon/platform.
-  - Select a CVWP GPS weapon and create a GPS target.
-  - Verify target/release cueing, range and release state.
-  - Cycle FOV and vision modes.
-  - Exit/re-enter optics and switch between two UAVs; no stale display state should remain.
-  - If pilot overlay is enabled, confirm it appears only for the locally controlled pilot/driver.
-===== 8. Debugging =====
+Select the intended GPS weapon before using this method.
-Production CVWP ships with heavy GPS diagnostics disabled:
+==== 17.2 Queue markers ====
-<code cpp>
+Numbered markers can be used to build a queue, for example:
-class RKSLA3_CVWP_GPS
-{
+<code ->
-    debug = 0;
+rkslgps1
-};
+rkslgps2
+rkslgps3
 </code>
-When deliberately diagnosing release/guidance behaviour, enable the master debug switch for the test build/mission:
+The underscore forms are also accepted, for example:
-<code cpp>
+<code ->
-class RKSLA3_CVWP_GPS
+rksl_gps_1
-{
+rksl_gps_2
-    debug = 1;
+rksl_gps_3
-};
 </code>
-This restores the V19D/V19E release correlation, ballistic path diagnostics, 3D markers and development hints. Do not leave it enabled in a normal release build.
+Numbering should start at **1** and remain sequential. The system stops looking for additional queue markers when it reaches the first missing number.
-===== 9. Common mistakes =====
+The queue is limited by the number of suitable GPS weapons currently available.
-^ Symptom ^ Cause ^ Fix ^
+===== 18. Useful quirks to remember =====
-| Fixed HUD follows free-look | Camera / ''worldToScreen'' projection used on static HUD | Use aircraft forward/right/up projection |
-| HMD target gate stays glued to helmet centre | Aircraft-relative projection used for world cue | Use per-frame ''worldToScreen'' for the gate |
-| LAR disappears intermittently despite valid solution | Display cache being treated as authority | Use shared dynamic RMIN/RMAX as authoritative display fallback |
-| RDY differs from CVWP | Aircraft addon re-derived release logic | Display ''releaseReady'' / ''constraint'' directly |
-| Existing HUD symbology disappears | Whole ''class MFD'' was replaced | Merge into resolved inherited MFD hierarchy |
-| Existing UAV turret breaks | Whole ''Turrets'' block was replaced | Patch the exact nested turret class only |
-| ''No entry ... sourceScale'' | Text MFD class omitted required source field | Use ''sourceScale = 1'' for userText classes |
-| Cue judders | Projection updated only at slow solver rate | Split solver refresh from render-frame projection |
-| User channels collide | Existing avionics already uses selected values | Allocate unused user/userText channels and adjust both SQF and MFD fragment |
-===== 10. Example package contents =====
+  * GPS targets are **weapon/ammo-specific**.
+  * A stored target can remain in memory when you select another weapon.
+  * Reselecting the matching weapon restores its active cue.
+  * A GPS point is fixed; it does not chase a moving object.
+  * **PWR** closes the panel but does not clear the target.
+  * **CLR** behaves differently while entering grids: it clears the current edit box instead of the whole target set.
+  * **QUEUE MAP** normally expects as many clicks as there are remaining rounds of that selected GPS ammo.
+  * **QUEUE GRID** can be committed early with **SEL** and is therefore better for a short queue.
+  * The LAR is dynamic. Do not memorise one fixed release distance for a GPS bomb.
+  * Being inside the displayed range window is not enough if another constraint is active.
+  * ''INHIBIT'' is advisory; manually forcing a release outside the accepted envelope can miss.
+  * Dual-mode weapons can remain bound to a GPS target until you explicitly clear it.
+  * UAV remote control may hide the scroll/action-menu entry; use **0 > 8 > RKSL GPS Panel**.
+  * If another RKSL system is using map-click input, finish/cancel it before programming GPS.
-The companion ZIP contains three source templates:
+===== 19. Troubleshooting =====
+^ Symptom ^ Likely cause ^ Action ^
+| RKSL GPS is missing from the UAV action menu | Remote UAV control is using the player's normal action context. | Use ''0 > 8 > RKSL GPS Panel''. |
+| GPS panel says NO GPS WEAPONS | No supported GPS-enabled weapon is currently loaded/available. | Check the aircraft loadout. |
+| No GPS cue after programming a target | A different weapon/ammo type is selected. | Reselect the weapon used when the target was programmed. |
+| Target is stored but weapon does not use it | Target is bound to another ammo type. | Program a target for the currently selected weapon. |
+| INH RNG | Outside current release range. | Continue/reposition and watch the LAR. |
+| INH ANG | Poor off-boresight geometry. | Turn towards the target/reposition. |
+| INH ALT | Altitude/height is unsuitable. | Increase altitude or change the attack profile. |
+| INH SPD | Speed is too low. | Increase speed. |
+| INH MISS | Required correction is outside the usable guidance envelope. | Improve range/alignment; do not force the drop. |
+| XTRK is displaced | Target is laterally off the current release path. | Steer to centre the XTRK cue. |
+| MAP TARGET reports Map input busy | Another RKSL system owns the map click. | Finish/cancel the other map operation and retry. |
+| GBU-54/B continues using GPS when you want laser | A valid GPS target remains stored for that ammo. | Clear GPS targets, then establish the laser/native target. |
+| Queue does not advance to a different weapon type | Queue is bound to the programmed ammo type. | Use the same ammo type or create a separate target/queue for the other weapon. |
+===== 20. Quick-reference attack card =====
 <code ->
-examples/
+. SELECT GPS WEAPON
-  cvwp_gps_static_hud_example/
+. OPEN RKSL GPS
-  cvwp_gps_hmd_example/
+   - MANNED: Action menu > RKSL GPS
-  cvwp_gps_uav_turret_example/
+   - UAV:    0 > 8 > RKSL GPS Panel
+. SELECT WEAPON IN PANEL
+. PROGRAM:
+   - MAP TARGET
+   - MANUAL GRID
+   - QUEUE MAP
+   - QUEUE GRID
+. RETURN TO FLIGHT
+. FIND GPS TARGET GATE
+. CENTRE / REDUCE XTRK
+. ENTER LAR
+. CHECK RNG + CONSTRAINT
+. WAIT FOR RDY
+. RELEASE
 </code>
-They are intentionally source templates rather than universal pre-packed PBOs, because third-party addons have different base class names, nested ''MFD''/''Turrets'' hierarchies and user-channel allocations.
+===== 21. Display quick reference =====
-For each template:
+^ Display type ^ Target gate ^ Release cues ^
+| Static HUD | Aircraft/HUD-relative projection. Free-look does not steer the cue. | Fixed to HUD. |
+| HMD | World-locked; follows the target as the pilot moves their head. | Helmet-fixed LAR/XTRK/status. |
+| UAV turret | Presented in the sensor/turret optics. | Sensor/weapon state plus GPS release information; exact layout depends on platform. |
-  - read ''README.txt'';
+===== 22. Final rule =====
-  - replace the clearly marked ''MY_*'' class/addon/path placeholders;
-  - inspect the target addon's resolved config before merging nested classes;
-  - pack as a small compatibility/profile PBO that depends on both the target addon and ''rksla3_cvwp''.
-===== 11. Production checklist =====
+For normal employment, the player does not need to understand the underlying guidance model.
+Use the system in this order:
+<code ->
+PROGRAM TARGET
+    -> ALIGN
+    -> ENTER LAR
+    -> CHECK CONSTRAINT
+    -> RDY
+    -> RELEASE
+</code>
-  - CVWP dependency declared.
+If the display says **INHIBIT**, correct the reason shown rather than treating the range marker alone as permission to release.
-  - No copied CVWP GPS, release, queue or guidance SQF.
-  - Correct display projection model selected: static HUD / HMD / UAV turret.
-  - No user/userText channel collisions.
-  - Existing MFD and turret children preserved.
-  - ''RDY/INH'' comes from CVWP, not local physics.
-  - Dynamic RMIN/RMAX used where available.
-  - Free-look test passed for static HUD.
-  - Head-tracking test passed for HMD.
-  - FOV/vision/re-entry test passed for UAV turret.
-  - RPT clean with ''-showScriptErrors''.
-  - CVWP master debug disabled for production.

Knowledgebase

User Tools

Site Tools

Differences

Page Tools