RCD X Laser Code

0.0.3

# Drone Laser Code Addon — Changelog

## IMPORTANT — THIS VERSION NEEDS A DIFFERENT DEPENDENCY

RVX Core is no longer required. This addon now needs **SOFLAM Integration Core**
instead. Please subscribe to it before updating, or the addon will not load.

**WCS_Armaments is no longer a dependency of this addon.** It still ships with
the aircraft mods that need it.

### Why

RVX Core stopped compiling with current WCS Armaments. One call in
`RVX_WCS_LoadoutOverrides.c` still uses the old signature of
`CreateWeaponQueueClient`. In Reforger every loaded mod is compiled into one
shared script module, so that single error takes the whole module down - your
server starts, but the game logic is gone. It cannot be patched from another
mod either, because patch code only becomes active after a successful compile,
and the compile is what fails.

This addon was hit directly: it registered its laser targets through three
methods RVX hangs on the player character
(`SpawnLaserTarget` / `UpdateLaserTargetPosAndCode` / `DeleteLaserTarget`).
Without RVX loaded the compiler does not know them, and the addon stops
building.

## What changed

Only the registration path. Everything you actually touch is unchanged.

- **Same button.** Still the camera laser / rangefinder button, left mouse
  button by default. A separate key was tried during development and dropped
  again - the shared button had never been the problem.
- **Same behaviour.** One press on, one press off, red diamond while running,
  the mark held when you look away, cleared automatically when you leave the
  drone.
- **Same laser code**, 1111.

Under the hood the three RVX calls were replaced by our own relay into the
Core's target registry. The network path is the same one the handheld SOFLAM
uses: the client asks the server, the server writes the target and broadcasts
it to everyone. The message travels on the operator's own character, because
the drone belongs to the server and a client can only send from something it
owns.

## Verified in a test flight

- Target registered and removed cleanly across three on/off cycles.
- Marked point landed on the aimed geometry: a shed wall 828 m out, reported
  position matching the building to within centimetres, stable over minutes.
- The mark showed up in the AH-64 gunner's sight, and missiles hit it.

## Also in this build

- Debug logging off. Only two messages remain, both real failures: the HUD
  layout failing to load, and the marker widget missing from it. A missing
  layout leaves no other clue.

0.0.2

# Drone Laser Code Addon — Changelog

## Fixed: laser marker did not land on the aimed point

### For players

- **The marker now appears where you aimed it.** Previously it hung in mid-air far
  beyond the target, roughly at the drone's flight altitude.
- **The marker now stays put when you leave the drone view.** Previously it drifted
  off the moment nobody was looking through the drone camera — which is exactly when
  the gunship crew needs it. Designation is now held on the marked point.
- **Terrain and buildings can be designated.** Previously only vehicles and characters
  were marked reliably; a ruin, a wall or bare ground silently failed.
- Console logging removed.

### For developers

1. **Trace flags.** `TraceFlags.DEFAULT | ANY_CONTACT` → `ENTS | VISIBILITY | WORLD | OCEAN`.
   Without `WORLD` the ray passes straight through terrain and static geometry. Now
   matches RVX's own `RVX_LaserDesignatorComponent.RayCastFromCamera`.
2. **Trace return value.** Dropped `if (!p.TraceEnt) return 0;` from the trace helper.
   World-geometry hits do not set `TraceEnt`, so clean ground hits came back as 0 and
   the caller placed the marker at full range.
3. **Caller.** Dropped the `hitFraction > 0` special case. `TraceMove` already returns
   1.0 for "nothing hit", which yields the ray end on its own.
4. **Aim source (the actual root cause).** Removed the drone-body fallback
   (`owner.GetWorldTransform()`). That is the hull attitude — near level in a hover,
   while the camera looks down — so the ray flew off horizontally and hit nothing.
   The last valid position is now held instead of recomputed.
   *The drone's gimbal camera entity was evaluated as a replacement source and rejected:
   its world orientation is not the view direction either (same horizontal signature).*
5. **Replication.** While held, the position is still sent every frame rather than
   skipped, so clients entering relevance later still receive one.
6. **Logging** is behind `GTG_DIAG` (off by default). Only the two HUD layout-failure
   messages remain, since a missing layout leaves no other clue.

### Compatibility

No changes needed in the AH-64 or AH-1Z SOFLAM mods. The fault was entirely on the
drone side — both gunships render whatever position reaches them, so both are fixed
by updating this addon alone.

0.0.1