veafCarrierOperations — Carrier Recovery Management¶
Module ID: CARRIER | File: veafCarrierOperations.lua
See it in game: step 16 “Stennis and Roosevelt carriers” of the demo mission.
Purpose¶
Manages aircraft carrier recovery operations. When players start a recovery, the carrier automatically turns into the wind to achieve the desired wind-over-deck speed, holds that heading for the recovery period, then returns to its original route. Displays BRC, TACAN, ICLS, and radio information.
Dependencies¶
veafRadio— F10 menuveafRemote— exposes acarrierremote command
Enable¶
veafCarrierOperations.initialize()
There is no per-carrier registration API. On initialize(), the module scans every group in the mission and automatically registers any group containing a known carrier unit type (see Supported Carrier Types). Its initial route, side and ATC data (TACAN/ICLS/LINK4/ACLS/tower, read from the carrier's programmed tasks) are captured at that point. Simply place a carrier group in the mission editor — no script call is needed.
The module also manages two optional support groups (a rescue helicopter and a recovery tanker), likewise detected by name — see Pedro and S3B recovery tanker.
Configuration (mission.yaml)¶
Carrier operations are enabled via the CARRIER module ID. Carriers themselves are not declared in mission.yaml: they are auto-discovered from the carrier groups present in the mission (see Enable).
modules:
CARRIER:
enabled: true # default: true
logLevel: info # optional log level override
init:
include_carrier_operations_radio: true # add carrier menu to F10 (default: true)
operations_scheduler: true # run VEAF's operations loop, every 60 s (default: true)
| Field | Type | Default | Required | Description |
|---|---|---|---|---|
enabled |
boolean | true |
No | Enable or disable the module |
logLevel |
string | (global) | No | Per-module log level override |
init.include_carrier_operations_radio |
boolean | true |
No | Add the carrier operations menu to the F10 radio tree |
init.operations_scheduler |
boolean | true |
No | false initializes the carriers and their menu without starting VEAF's loop that restarts their operations every 60 s: for a mission that drives its carriers itself |
Minimal example¶
modules:
CARRIER:
enabled: true
Key Configuration Constants¶
| Constant | Default | Description |
|---|---|---|
veafCarrierOperations.MAX_OPERATIONS_DURATION |
45 |
Auto-stop after N minutes |
veafCarrierOperations.ALIGNMENT_MANOEUVER_SPEED |
20 kts | Carrier speed while turning into wind |
veafCarrierOperations.MIN_WINDSPEED_FOR_CHANGING_HEADING |
4 kts | Minimum wind speed to warrant a turn |
veafCarrierOperations.MIN_CARRIER_SPEED |
4 kts | Minimum carrier steaming speed |
veafCarrierOperations.DisableSecurity |
false |
If true, anyone can start/stop recovery |
Supported Carrier Types¶
The module knows the angled-deck offset for all stock DCS carriers:
| DCS Type | Angled deck offset | Wind over deck |
|---|---|---|
Stennis, CVN_71/72/73/75, Forrestal |
9.05° | 25 kts |
KUZNECOW, CV_1143_5 |
9° | 25 kts |
LHA_Tarawa |
−1° (straight deck) | 20 kts |
Pedro and S3B recovery tanker¶
Beyond the carrier itself, the module automatically manages two support groups, detected by name — no script call, no mission.yaml entry. Just place them in the mission editor following the naming convention.
| Group | Expected name | Role | Automatic positioning |
|---|---|---|---|
| Pedro | <carrier unit name> Pedro |
Rescue helicopter (SH-60B) | 250 ft, 1 nm to starboard, riding along with the carrier at the same speed and heading |
| S3B tanker | <carrier unit name> S3B-Tanker |
Emergency recovery tanker (S-3B Tanker) | 8000 ft, 10 nm aft and 4 nm to starboard, refueling on the BRC |
<carrier unit name> is the name of the carrier unit (identical to the group name for a carrier alone in its group, the common case). Example: for a carrier unit named CVN-73, place the groups CVN-73 Pedro and CVN-73 S3B-Tanker.
Once named correctly, both groups are, on every operations cycle:
- auto-detected;
- respawned when destroyed;
- routed automatically, their path (re)computed to stay in formation with the carrier.
If a group is missing, the module ignores it and logs a warning — No Pedro group named <name> or No Tanker group named <name> — without blocking operations.
Deck lights¶
When air operations start, the module sets the carrier's lights to recovery (the editor's AC RECOVERY); when they stop, it gives them back to DCS (AUTO).
It goes through the editor's trigger action SET CARRIER LIGHTING MODE, which mission scripts do not have: it can only be reached through net.dostring_in.
On a server whose MissionScripting.lua removes net, the lights stay as DCS sets them, a warning in dcs.log says so, and operations run as before.
F10 Radio Menu¶
The top-level CARRIER OPS menu holds a CARRIER OPS - BLUE and a CARRIER OPS - RED submenu, each containing one submenu per carrier (named after the carrier group). When operations are stopped, each carrier submenu offers:
- Start carrier air operations for 45 minutes — turn into the wind and open a 45-minute recovery window
- Start carrier air operations for 90 minutes — same, for 90 minutes (
MAX_OPERATIONS_DURATION× 2) - ATC - Request informations — TACAN, ICLS, LINK 4 / ACLS, tower, BRC and remaining time, plus current navigation and weather
While operations are running, the two Start items are replaced by:
- End air operations — stop recovery and send the carrier back to its initial route
By default the Start/End items are secured: the group acts at the level of its lowest-graded occupant (see veafSecurity). Set
veafCarrierOperations.DisableSecurity = trueto make them open to everyone.
Each side sees only its own submenu. A red pilot does not see CARRIER OPS - BLUE, and the other way round. Before 6.15.10 both submenus were visible to everyone, so a red player could start and stop the blue carrier's operations. The top-level CARRIER OPS menu stays shared, since it carries the help entry.
See Also¶
- Lua API Reference — full
veafCarrierOperationsAPI