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.

The GPS/release solver belongs to rksla3-cvwp. Your aircraft addon should only provide a presentation layer.

CVWP
  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)

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.

The aircraft/display addon owns only:

• dependency on rksla3_cvwp;
• display geometry and styling;
• local MFD/HMD user-channel allocation;
• projection appropriate to that display type;
• platform-specific FOV/gimbal tuning where required.

Your addon must load after CVWP:

class CfgPatches
{
    class MyAircraft_CVWP_GPS_Patch
    {
        requiredAddons[] =
        {
            "MyAircraft_Base_Addon",
            "rksla3_cvwp"
        };
        units[] = {};
        weapons[] = {};
    };
};

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:

mfdMaxUserValues = 207;

If the aircraft already has a larger value, do not reduce it.

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:

RKSLGPS = 1;

Guided-ballistic and glide weapons require the appropriate additional CVWP guidance profile; do not invent those values in the aircraft HUD patch.

For bespoke HUD/HMD integrations, use:

private _solution = [_vehicle] call RKSLA3_CVWP_fnc_targetCueGetSolution;

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.

For normal production presentation, most integrations only need indices 0-6, 10-13, 20 and 21.

The validated aircraft displays use the same basic information even though they project it differently:

• GPS target gate — world target cue.
• 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.

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:

private _release = [_weapon,"","",_ammo,_magazine] call RKSLA3_CVWP_fnc_gpsReleaseSettings;

Do not use the fallback to override a CVWP release inhibit.

A static HUD is physically attached to the aircraft. The GPS cue must move when the aircraft moves, not when the pilot free-looks.

The tested reference is the Gripen C implementation.

The active HUD class should use the model's combiner memory points and should not be configured as an HMD:

topLeft = "hud_tl";
topRight = "hud_tr";
bottomLeft = "hud_ll";
enableParallax = 0;
helmetMountedDisplay = 0;

Use the actual memory-point names from your model.

The example package contains:

cvwp_gps_static_hud_example/
  config.cpp.example
  functions/fn_staticHudInit.sqf
  functions/fn_staticHudUpdate.sqf
  includes/cvwp_gps_static_bones.hpp
  includes/cvwp_gps_static_draw.hpp

The adapter reads targetCueGetSolution and publishes local user / userText values. It does not modify CVWP.

Inside the existing static HUD MFD class, merge the supplied bones into class Bones and the supplied draw group into class Draw.

Do not replace the aircraft's whole class MFD just to add CVWP symbology.

The critical rule is: do not use worldToScreen for a fixed HUD target gate.

The example converts the target line-of-sight into the aircraft's forward/right/up frame:

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;
private _r = _los vectorDotProduct _right;
private _u = _los vectorDotProduct _up;

It then converts horizontal/vertical angles to local HUD coordinates.

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.

Example vehicle hooks supplied by the plugin:

CVWPGPS_StaticHUD_XPerDegree = 0.0725;
CVWPGPS_StaticHUD_YPerDegree = 0.0600;
CVWPGPS_StaticHUD_EdgeMargin = 0.045;

These are display calibration values, not weapon physics.

1. Hold the aircraft steady and free-look left/right/up/down: the GPS gate must remain fixed to the aircraft HUD.
2. Turn the aircraft: the gate must move across the HUD.
3. Roll/pitch the aircraft: the cue must remain registered to the target through the HUD geometry.
4. Fly through the LAR: range marker should cross FAR, move through the valid zone, then cross NEAR.
5. 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.

An HMD is different: the target cue is world-registered to the pilot's current view. The tested reference is the StavJet implementation.

The clean separation is:

• world-locked: GPS target gate;
• helmet-fixed: LAR, XTRK, RDY/INH and RNG;
• aircraft-derived: XTRK/release geometry values, even though their symbols are drawn in helmet space.

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 example package contains:

cvwp_gps_hmd_example/
  config.cpp.example
  functions/fn_hmdInit.sqf
  functions/fn_hmdUpdate.sqf
  includes/cvwp_gps_hmd_bones.hpp
  includes/cvwp_gps_hmd_draw.hpp

For an HMD, worldToScreen is appropriate because the pilot's view direction is part of the display geometry:

private _screen = worldToScreen (ASLToAGL _targetASL);

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.

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.

1. Keep aircraft attitude constant and move the pilot's head: the GPS gate must track the world target.
2. LAR/XTRK/status must stay in the same helmet position.
3. Look away far enough: the target gate should clip/hide cleanly at the useful HMD boundary.
4. Re-centre the view: the gate should return to the correct target position.
5. Aircraft manoeuvre must still change XTRK and release state because those values are aircraft-relative.

For a UAV sensor turret, do not build another copy of the MQ-9 HUD scripts. CVWP owns a reusable sensor-operator optics resource.

CVWP provides:

RKSLA3_CVWP_UAVHUD_GunnerOptics
RKSLA3_CVWP_UAVHUD_PilotReleaseOverlay

and the function/runtime namespace:

RKSLA3_CVWP_fnc_uavHud*
RKSLA3_CVWP_UAVHUD_*

class RscInGameUI
{
    class RKSLA3_CVWP_UAVHUD_GunnerOptics;
 
    class MyUAV_GunnerOptics: RKSLA3_CVWP_UAVHUD_GunnerOptics
    {
        // Vehicle-specific visual overrides only.
    };
};

Merge into the target addon's real resolved turret hierarchy:

turretInfoType = "MyUAV_GunnerOptics";

Do not blindly replace the entire Turrets block; preserve inherited weapons, optics, stabilisation, animation sources and sensors.

RKSLA3_CVWP_UAVHUD_APIRequired = 1;

Optional pilot overlay:

RKSLA3_CVWP_UAVHUD_EnablePilotOverlay = 1;
RKSLA3_CVWP_UAVHUD_PilotOverlayClass = "MyUAV_PilotReleaseOverlay";

If you only need the turret/sensor HUD, leave the pilot overlay disabled.

The UAV framework supports platform-local projected-gate tuning. Start with the reference values only if needed:

RKSLHudProjectedGateTransformMode = 4;
RKSLHudProjectedGateSmoothing = 0.18;
RKSLHudProjectedGateDeadzone = 0.003;
RKSLHudProjectedGateMaxStep = 0.08;
RKSLHudProjectedGateResetDistance = 15;

Keep platform tuning in the UAV addon. Do not fork fn_uavHud*.sqf.

1. Enter the sensor turret and verify the CVWP optics load without RPT errors.
2. Select a CVWP GPS weapon and create a GPS target.
3. Verify target/release cueing, range and release state.
4. Cycle FOV and vision modes.
5. Exit/re-enter optics and switch between two UAVs; no stale display state should remain.
6. If pilot overlay is enabled, confirm it appears only for the locally controlled pilot/driver.

Production CVWP ships with heavy GPS diagnostics disabled:

class RKSLA3_CVWP_GPS
{
    debug = 0;
};

When deliberately diagnosing release/guidance behaviour, enable the master debug switch for the test build/mission:

class RKSLA3_CVWP_GPS
{
    debug = 1;
};

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.

The companion ZIP contains three source templates:

examples/
  cvwp_gps_static_hud_example/
  cvwp_gps_hmd_example/
  cvwp_gps_uav_turret_example/

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.

For each template:

1. read README.txt;
2. replace the clearly marked MY_* class/addon/path placeholders;
3. inspect the target addon's resolved config before merging nested classes;
4. pack as a small compatibility/profile PBO that depends on both the target addon and rksla3_cvwp.

1. CVWP dependency declared.
2. No copied CVWP GPS, release, queue or guidance SQF.
3. Correct display projection model selected: static HUD / HMD / UAV turret.
4. No user/userText channel collisions.
5. Existing MFD and turret children preserved.
6. RDY/INH comes from CVWP, not local physics.
7. Dynamic RMIN/RMAX used where available.
8. Free-look test passed for static HUD.
9. Head-tracking test passed for HMD.
10. FOV/vision/re-entry test passed for UAV turret.
11. RPT clean with -showScriptErrors.
12. CVWP master debug disabled for production.