np_docs

Operations ​

What the operator can do beyond pointing the camera: read targets, mark points, see friendly units, check plates, track heat, record the sortie and share a lock. Each feature sends its data through the server, which checks the role, the seat, rate limits and every value before passing it on.

Target card & ANPR ​

Lock a vehicle or ped with SPACE. The target card fills from the locked entity: model, plate, colour, speed and direction, range, line of sight and lock quality. Info refreshes at 10 Hz, line of sight at 4 Hz.

ANPR. A vehicle's plate is read after Config.Anpr.readMs (1.5 s) of steady lock while all of these hold:

  • range within Config.Anpr.maxRange (450 m)
  • zoom at least Config.Anpr.minZoomX (4×)
  • line of sight

If any of them drops out, the timer starts over. Until the read, the card shows READING.... After it, the plate shows with ANPR ✓, the read is logged to the mission timeline, and the plate goes to the BOLO check.

Lock quality (0–5) is a score from range, zoom and target speed. Without line of sight it is capped at 1.

Lock transfer. If the driver of a locked vehicle gets out and is on foot within 5 s, the lock moves to that person. The card switches to PED · ON FOOT with LAST VEH <plate>, the PATH keeps going, the timeline gets a FOOT entry, and a red Suspect on foot toast shows.

BOLO ​

A BOLO (be on the lookout) is a plate the server watches for. A plate is a hit when:

  • it is in the server's in-memory registry (added with the exports or /bolo by a player with the bolo role), or
  • Config.Bolo.lookup(plate) returns { reason, code } (for an external MDT, see Configuration → BOLO).

Plates are compared normalised: upper case, letters and digits only, so " 46EEK57 " and 46-EEK-57 match.

The client only sends the network id of the vehicle it read. The server checks that the vehicle exists and is within Config.Anpr.maxRange + 50 m of the operator's heli, and reads the plate itself, so a modified client can't probe arbitrary plates. At most 2 checks per second per operator.

On a hit:

  • the operator gets the red BOLO banner, a toast, and a BOLO row on the target card
  • every ground unit and the rest of the crew get a toast: AIR-1 · BOLO HIT with plate, reason, code and street
  • the timeline gets a BOLO entry

The client caches each plate's result for Config.Bolo.cacheMs (60 s). The server sends at most one alert per plate per heli in that window. The registry lives in memory and is empty after a restart.

PNT markers ​

M drops a marker at the crosshair ground point. The server names it P1, P2, …, syncs the full list to every air and ground player, and toasts the operator with the street.

  • Up to Config.Markers.max (12) air-placed markers on the server. The oldest is dropped.
  • Markers expire after Config.Markers.ttlMin (30) minutes.
  • One marker per Config.Markers.rateMs (750 ms) per player, and only within the camera's probe range of the heli.
  • Rename and delete them in the F9 sheet (air role, no seat needed). Labels are capped at Config.Markers.labelMax (32) characters and cleaned of formatting codes.
  • Ground units see them in the Air Support panel and can set GPS to one.
  • A ground unit's orbit request also creates a marker, ORBIT REQ · <callsign>. These have their own 4 slots (one per requester) and never push out an air marker.
  • Labels are stripped of formatting and markdown characters ([ ] ( ) ! * _ and backticks), so they can't fake links or bold text in someone else's toast.

On the HUD a marker is an amber diamond, or an edge arrow when it is off-screen. On the context map it is an orange blip.

Friendly units ​

While the camera is open (and while a ground unit has the F7 panel open), the client subscribes to the unit stream. Every Config.Units.intervalMs (1 s) the server sends the positions of all players with the air or ground role: callsign, position, heading and whether they are in a helicopter. Positions are read on the server, not reported by clients.

The HUD draws them as blue triangles with callsigns (your own crew left out), and the context map as blue blips. The broadcast stops when nobody is subscribed, and a player who loses the role stops receiving it.

Heat lock ​

In FLIR, warm peds (alive, on foot) and vehicles with the engine running are boxed. The scan is budgeted: Config.Heat.scanPerFrame (24) entities per frame round-robin, at most Config.Heat.max (24) boxes, within Config.Heat.maxRange (900 m). When the list is full, the box farthest from the crosshair makes room.

Q locks a heat signature: the first press takes the one nearest the crosshair, each further press steps outward and wraps. A ped inside a vehicle is represented by the vehicle's engine signature.

PATH ​

While something is locked, its position is sampled every Config.Trail.intervalMs (750 ms) into a trail of up to Config.Trail.max (40) points, skipping points closer than minSpacing (6 m). The HUD draws it as red dots. A new target clears the trail, but a lock transfer keeps it, because it is the same suspect.

Mission recording ​

With Config.Mission.autoRecord, recording starts when the camera opens. R stops it, or starts a new one.

What is recorded:

KindWhen
start / endRecording started / stopped or finalised
lock / unlockEntity locked / released
poslockPosition lock (double-tap SPACE), with street
anprPlate read
boloBOLO hit
footLock moved to a driver on foot
markerPNT marker placed
shareLock shared with K
visionThermal palette changed
bookmarkB pressed, or an evidence screenshot arrived
noteCamera closed / reopened

The server samples the heli's position and speed every Config.Mission.trackIntervalMs (5 s) for the flight track, from the entity itself. The client sends its events in batches every few seconds, and the server keeps at most Config.Mission.maxEvents (200).

Closing the camera pauses the mission. Reopening it within Config.Mission.idleEndMs (2 min) continues the same report. Otherwise the server finalises it. A mission also ends when you press R, start a new one, disconnect, or the resource stops. The server re-checks the air role for every batch of events, so an operator who goes off duty adds nothing more to the log, and the mission idles out. One mission start per 10 s per operator.

Trivial missions are discarded: shorter than 10 s with at most one real event (the start, note and end lines don't count). This happens often with autoRecord and a quick E tap, and produces no report, event or webhook post.

The report. When a mission ends, the server builds a report and:

The plain-text form looks like this:

MISSION 261004-2214-3 · AIR-1 (polmav)
Operator: Officer Doe
Start: 2026-10-04 22:10:02 UTC
Duration: 04:12
Track: 50 samples, 3.4 km
Events: 9
00:00  START    Recording started · AIR-1
01:01  LOCK     Locked BLACK BRAVADO BUFFALO STX
01:03  ANPR     ANPR read 46EEK572
01:04  BOLO     BOLO hit 46EEK572: armed robbery
03:10  FOOT     Suspect on foot, left 46EEK572
...

The F9 sheet's Mission tab shows the live timeline and copies this text to the clipboard.

Evidence screenshots ​

B adds a bookmark. With Config.Mission.screenshots on and screenshot-basic started, it also asks the server for an evidence screenshot of the operator's screen (JPEG, at most one per 5 s per player). The image is not stored by np_helicam and not sent to Discord. It is handed out once as the server event np_helicam:evidence, so your MDT or evidence resource can save or upload it. The report only records that a screenshot was taken and its size.

Crew share ​

K shares the current lock, an entity or a position:

  • Crew: every other player in the heli gets a toast. If their camera is open and has no lock of its own, it locks the shared entity. A share never takes an operator off a target they are already tracking.
  • Ground units: a toast, e.g. AIR-1 tracking BLACK BRAVADO BUFFALO STX 46EEK572 on Alta St.

The client sends the parts (kind, model, colour, whether the plate was read, on foot / last plate, street), and the server builds the sentence from validated parts. For a networked vehicle, the server reads the plate itself.

The operator sees how many crew and ground units it reached, and the share is logged to the timeline. One share per 3 s per player.

np_* FiveM resources