diff --git a/.backlog/DOC-README-CLEANUP/PRD.md b/.backlog/DOC-README-CLEANUP/PRD.md new file mode 100644 index 0000000..e9bbe57 --- /dev/null +++ b/.backlog/DOC-README-CLEANUP/PRD.md @@ -0,0 +1,89 @@ +Status: waiting-human + +# PRD — DOC-README-CLEANUP + +## Problem Statement + +The project README.md has accumulated several structural and naming issues since the codebase moved +from the temporary `DCS-CTLD Next` repository to the definitive `CTLD` repository: + +1. The document title still reads `DCS-CTLD Next`, the old temporary repo name. +2. Two sections (`Pack Equipt` and `Virtual Slingload`) are presented at the same hierarchy level + as `Crate Operations`, even though both are crate sub-operations and already appear under + **Crate Commands** in the F10 menu description. +3. `AA System Construction` is placed far from `Crate Operations` despite being a multi-crate + assembly workflow. +4. The `Developer Guide` section is a self-contained prose block that duplicates content now + published on the documentation site, with no links to the live guides. + +## Solution + +Apply six targeted edits to `README.md`: + +1. Rename the H1 title from `DCS-CTLD Next` to `CTLD`. +2. Demote `## Pack Equipt` to `### Pack Equipt` and move it inside `## Crate Operations` + (after the Unpack paragraph), reflecting its position under Crate Commands in the F10 menu. +3. Demote `## Virtual Slingload` to `### Virtual Slingload` and move it inside + `## Crate Operations` (after the Drop paragraph, before Pack Equipt), for the same reason. +4. Keep `## AA System Construction` at `##` level but relocate it to immediately after + `## Crate Operations` to signal the logical proximity. +5. Update the Table of Contents to reflect changes 1–4. +6. Replace `## Developer Guide` with a `## Documentation` section containing three quick links + to the live documentation site (pilot guide, mission maker guide, developer documentation). + +## User Stories + +1. As a new user landing on the GitHub repository page, I want the README title to say `CTLD` so + that I immediately know I am in the right repository and not a stale fork. +2. As a mission maker reading the README, I want `Pack Equipt` to appear inside `Crate Operations` + so that I understand packing is part of the crate lifecycle, not a standalone concept. +3. As a mission maker reading the README, I want `Virtual Slingload` to appear inside + `Crate Operations` so that I find slingload documentation in the same place as crate loading + and dropping. +4. As a mission maker reading the README, I want `AA System Construction` to appear immediately + after `Crate Operations` so that the connection between crate assembly and AA system build + is obvious without scrolling far. +5. As a developer consulting the README, I want the Table of Contents to accurately reflect the + section hierarchy so that anchor links work and navigation is predictable. +6. As any reader consulting the README, I want a `Documentation` section with direct links to + the pilot guide, mission maker guide, and developer documentation site so that I can reach + the full reference without searching. + +## Implementation Decisions + +- All changes are confined to `README.md`. No source file, test, or build artifact is modified. +- The three subsections of `## Crate Operations` after the edit will be, in order: + `### Virtual Slingload`, then `### Pack Equipt`. The existing `### Pack Vehicle` and + `### Pack FARP` headings inside Pack Equipt become `####`. +- `## Virtual Parachute Drop` and `## FARP Deployment` are left at `##` level in their current + positions: both are cross-cutting (Troop / Vehicle / Crate Commands) and their standalone + status is justified. +- The `## Documentation` quick-link section uses the production URLs below (English, consistent + with the rest of the README): + - Pilot guide: `https://veaf.github.io/CTLD/dev/pilot/` + - Mission maker guide: `https://veaf.github.io/CTLD/dev/mission-maker/` + - Developer documentation: `https://veaf.github.io/CTLD/dev/developer/` + +## Testing Decisions + +This lot contains no logic changes. There is nothing to unit-test or integration-test. + +Acceptance criteria (manual review checklist): +- [ ] H1 reads `# CTLD`. +- [ ] Table of Contents reflects the new hierarchy (no broken anchor links). +- [ ] `Crate Operations` section contains `Virtual Slingload` and `Pack Equipt` as `###` children. +- [ ] `AA System Construction` immediately follows `Crate Operations` in the rendered document. +- [ ] `Developer Guide` section is gone; `Documentation` section is present with the three links. +- [ ] No other section has been moved, renamed, or reformatted. + +## Out of Scope + +- Content edits inside any section (wording, examples, parameters). +- Restructuring sections other than those listed above. +- Adding new documentation pages or updating the docs site itself. +- Any `src/` or `tests/` changes. + +## Further Notes + +The URLs supplied for the `## Documentation` section point to the `dev/` subdirectory of the +GitHub Pages site deployed by `DOC-MKDOCS`. Verify the links resolve correctly before merging. diff --git a/.backlog/DOC-README-CLEANUP/tickets/01-rename-h1-title.md b/.backlog/DOC-README-CLEANUP/tickets/01-rename-h1-title.md new file mode 100644 index 0000000..0f2febf --- /dev/null +++ b/.backlog/DOC-README-CLEANUP/tickets/01-rename-h1-title.md @@ -0,0 +1,23 @@ +# 01 — Rename the README title from `DCS-CTLD Next` to `CTLD` + +Status: done +Type: AFK + +## What to build + +Rename the H1 title in `README.md` from `# DCS-CTLD Next` to `# CTLD`, the old temporary repo +name left over from the `DCS-CTLD Next` repository. Self-contained: the H1 is not referenced from +the Table of Contents, so this slice has no knock-on effect elsewhere in the document. + +## Acceptance criteria + +- [x] `README.md` line 1 reads `# CTLD`. +- [x] No other text on that line or the subtitle below it is changed. + +## Blocked by + +None - can start immediately. + +## Implementation + +Done in commit `1d528dd` on `fix/doc-readme-cleanup`. diff --git a/.backlog/DOC-README-CLEANUP/tickets/02-replace-developer-guide-with-documentation-links.md b/.backlog/DOC-README-CLEANUP/tickets/02-replace-developer-guide-with-documentation-links.md new file mode 100644 index 0000000..1f43792 --- /dev/null +++ b/.backlog/DOC-README-CLEANUP/tickets/02-replace-developer-guide-with-documentation-links.md @@ -0,0 +1,34 @@ +# 02 — Replace `Developer Guide` with a `Documentation` quick-links section + +Status: done +Type: AFK + +## What to build + +Replace the `## Developer Guide` prose block (which duplicates content already published on the +documentation site) with a `## Documentation` section containing three quick links: + +- Pilot guide: `https://veaf.github.io/CTLD/dev/pilot/` +- Mission maker guide: `https://veaf.github.io/CTLD/dev/mission-maker/` +- Developer documentation: `https://veaf.github.io/CTLD/dev/developer/` + +Self-contained: this only touches the last `## Developer Guide` / `## Documentation` heading and +its own single line in the Table of Contents — independent of the Crate Operations cluster +restructured in ticket 03. + +## Acceptance criteria + +- [x] `## Developer Guide` no longer exists in `README.md`. +- [x] `## Documentation` exists in its place with the three links above. +- [x] All three links resolve correctly (verified live — pilot/mission-maker/developer guide pages + load with the expected headings). +- [x] The Table of Contents entry for this section is updated accordingly. + +## Blocked by + +None - can start immediately. + +## Implementation + +Done in commit `1d528dd` on `fix/doc-readme-cleanup`. Links verified live via WebFetch before +merging (all three resolve to their respective guide pages). diff --git a/.backlog/DOC-README-CLEANUP/tickets/03-restructure-crate-operations-cluster.md b/.backlog/DOC-README-CLEANUP/tickets/03-restructure-crate-operations-cluster.md new file mode 100644 index 0000000..c2abdef --- /dev/null +++ b/.backlog/DOC-README-CLEANUP/tickets/03-restructure-crate-operations-cluster.md @@ -0,0 +1,49 @@ +# 03 — Restructure the Crate Operations cluster + +Status: done +Type: AFK + +## What to build + +Nest `Virtual Slingload` and `Pack Equipt` inside `Crate Operations` as `###` children, relocate +`AA System Construction` to immediately follow `Crate Operations`, and update every Table of +Contents entry touched by this move — all in the same change. This is kept as a single vertical +slice rather than split by heading: moving one section without updating the ToC and the sibling +moves in the same commit would leave the document's navigation temporarily inconsistent, which +fails the "no broken anchor links" / "ToC reflects the new hierarchy" acceptance bar. The slice is +independent of tickets 01 and 02. + +Resulting structure: + +- `## Crate Operations` + - Spawn / Load / Drop paragraphs (unchanged) + - `### Virtual Slingload` (demoted from `##`, moved here after the Drop paragraph) + - Unpack paragraph (unchanged) + - `### Pack Equipt` (demoted from `##`, moved here after the Unpack paragraph) + - `#### Pack Vehicle` (demoted from `###`) + - `#### Pack FARP` (demoted from `###`) +- `## AA System Construction` (kept at `##`, relocated to immediately follow `Crate Operations`) + +`## Virtual Parachute Drop` and `## FARP Deployment` are left in place — both are cross-cutting +(Troop / Vehicle / Crate Commands) and out of scope for this move. + +## Acceptance criteria + +- [x] `## Virtual Slingload` and `## Pack Equipt` no longer exist as standalone `##` sections. +- [x] `### Virtual Slingload` then `### Pack Equipt` appear inside `## Crate Operations`, in that + order. +- [x] `#### Pack Vehicle` and `#### Pack FARP` are nested under `### Pack Equipt`. +- [x] `## AA System Construction` immediately follows `## Crate Operations` in the rendered + document, and remains at `##` level with its content unchanged. +- [x] `## Virtual Parachute Drop` and `## FARP Deployment` stay at `##` level, untouched. +- [x] Table of Contents entries and nesting match the rendered hierarchy exactly; no broken anchor + links. +- [x] No section body text is changed (only heading levels and position move). + +## Blocked by + +None - can start immediately. + +## Implementation + +Done in commit `1d528dd` on `fix/doc-readme-cleanup`. diff --git a/.backlog/README.md b/.backlog/README.md index 9657c82..8f9e68a 100644 --- a/.backlog/README.md +++ b/.backlog/README.md @@ -14,7 +14,7 @@ authored **per lot, when the lot is started** (not in batch). | Lot | Status | Description | Branch | |-----|--------|-------------|--------| -| _(none)_ | | | | +| `DOC-README-CLEANUP` | 🧑 waiting-human | Fix README title, restructure Crate Operations sub-sections, relocate AA System Construction, replace Developer Guide with Documentation links — implemented, pending PR review/merge | `fix/doc-readme-cleanup` | ### Planned lots diff --git a/CHANGELOG.md b/CHANGELOG.md index 64ad777..c134372 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -8,6 +8,16 @@ Versioning follows [Semantic Versioning](https://semver.org/). ## [Unreleased] +### Docs — README cleanup + +- **Fix**: README H1 renamed from the stale `DCS-CTLD Next` temporary-repo title to `CTLD`. +- **Restructure**: `Pack Equipt` and `Virtual Slingload` demoted from `##` to `###` and moved + inside `Crate Operations` (their parent workflow, and already grouped under **Crate Commands** + in the F10 menu); `AA System Construction` relocated to immediately follow `Crate Operations`. +- **Restructure**: `Developer Guide` (a prose block duplicating the published docs site) replaced + by a `Documentation` section linking directly to the pilot, mission maker and developer guides. +- Table of Contents updated to match the new section hierarchy. + ### DCS integration testing — first live validation - **Fix**: `missions/Test_CTLDNEXT_01.miz`'s embedded `beacon.ogg` (420KB) broke the DCS Mission diff --git a/README.md b/README.md index fa22761..b201045 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# DCS-CTLD Next +# CTLD Complete Troops and Logistics Deployment for DCS World — **v2 modular rewrite** @@ -50,8 +50,10 @@ Reach out to [Zip on Discord](https://discordapp.com/users/421317390807203850) t - [In-Game F10 Menu](#in-game-f10-menu) - [Troop Operations](#troop-operations) - [Crate Operations](#crate-operations) + - [Virtual Slingload](#virtual-slingload) + - [Pack Equipt](#pack-equipt) +- [AA System Construction](#aa-system-construction) - [Virtual Parachute Drop](#virtual-parachute-drop) -- [Virtual Slingload](#virtual-slingload) - [Forward Operating Base (FOB)](#forward-operating-base-fob) - [FARP Deployment](#farp-deployment) - [Radio Beacons](#radio-beacons) @@ -59,10 +61,8 @@ Reach out to [Zip on Discord](https://discordapp.com/users/421317390807203850) t - [Smoke Drop](#smoke-drop) - [Recon and Target Marking](#recon-and-target-marking) - [Minefield Deployment](#minefield-deployment) -- [AA System Construction](#aa-system-construction) -- [Pack Equipt](#pack-equipt) - [Migration from v1](#migration-from-v1) -- [Developer Guide](#developer-guide) +- [Documentation](#documentation) --- @@ -839,23 +839,7 @@ F10 Other / [Transport Name] **Drop** — select **Drop Crate** in flight. With virtual slingload active, the crate drifts from the drop point based on speed and altitude. -**Unpack** — land near a dropped crate. Select **Unpack Crate** — the crate is replaced by the corresponding unit. Multi-crate items (e.g. SPH requiring 3 crates) require all crates within 100 m before unpacking. - ---- - -## Virtual Parachute Drop - -When `canParachuteDrop = true` on the aircraft type and the unit is airborne above the minimum altitude: - -- The menu shows **Parachute [Troops / Crate / Vehicle]**. -- Each item has independent forward inertia (`ctld.parachuteInertiaFactor` × transport speed) plus random lateral drift (`ctld.parachuteLateralDriftMin`–`ctld.parachuteLateralDriftMax`). -- Troops land dispersed; parachuted crates auto-unpack on landing if the target area is clear within `ctld.autoUnpackRadiusParachute`. - -> **Crate parachute limitation:** only crates loaded via the **CTLD F10 menu** (Load Crate / hover-load / virtual slingload) are eligible for parachute drop. Crates loaded through the DCS native cargo system (`useNativeDcsCargoSystem = true`) are managed by DCS and cannot be released via CTLD's parachute menu. - ---- - -## Virtual Slingload +### Virtual Slingload When `ctld.slingLoad = false` (default): @@ -866,98 +850,46 @@ When `ctld.slingLoad = false` (default): When `ctld.slingLoad = true`: DCS native sling physics are used (may cause crashes on some versions). ---- - -## Forward Operating Base (FOB) - -A FOB provides a new crate spawn point and optionally a troop pickup point anywhere on the map. - -1. Load FOB crates at a logistic zone (large crates require large aircraft; small crates count as 1/3). -2. Drop `ctld.cratesRequiredForFOB` large crates (or equivalent in small) within 100 m of each other. -3. Select **Build FOB** — the FOB spawns with a radio beacon. -4. The built FOB appears in F10 as a new logistic point for crate spawning. -5. If `ctld.troopPickupAtFOB = true`, troops can also be loaded there. - -Event `OnFOBDeployed` fires when construction completes. - ---- - -## FARP Deployment - -A FARP (Forward Arming and Refuelling Point) is deployed as a scene: a sequence of static objects (helipads, fuel trucks, shelters) spawn around the helicopter. - -1. At a logistic zone, spawn and load a FARP crate. -2. Fly to the desired deployment site and land. -3. Select **Deploy FARP** — the scene executes step-by-step over several seconds. -4. The deployed FARP becomes active in DCS for rearming and refuelling. - ---- - -## Radio Beacons - -Beacons broadcast on HF/FM, UHF and VHF simultaneously. Frequencies are drawn from coalition pools to avoid conflicts. - -**Deploying via F10** — land (or hover), select **Drop Beacon** from the menu. The beacon appears on the F10 map. - -**Deploying via script** — `ctld.createRadioBeaconAtZone("zone", "blue", 30, "Waypoint Alpha")` - -**Battery life** — configured by `ctld.deployedBeaconBattery` (minutes). After expiry the beacon stops transmitting. - -**ADF tuning by aircraft:** - -| Aircraft | Band | Notes | -|----------|------|-------| -| A-10C/II | UHF | ADF page in EHSI | -| Ka-50 | UHF | ARK-22 | -| Mi-8 / Mi-24 | VHF/FM | ARC-9 | -| UH-1H | VHF | ADF | -| All others | FM | Tune to displayed frequency | - ---- - -## JTAC Auto-Lase - -**Mission-editor JTACs** — place the JTAC unit in a dedicated single-unit group. Activate via `ctld.JTACAutoLase("GroupName", laserCode)`. See full syntax in [Mission Editor Script Functions → JTAC](#jtac). - -**Crate-deployed JTACs** — spawn a JTAC crate (`Hummer - JTAC` or `SKP-11 - JTAC`), drop it, and unpack it. The JTAC auto-activates immediately. - -**Target priority** — include `hpriority` or `priority` in the unit name (Mission Editor) to control lasing order. +**Unpack** — land near a dropped crate. Select **Unpack Crate** — the crate is replaced by the corresponding unit. Multi-crate items (e.g. SPH requiring 3 crates) require all crates within 100 m before unpacking. -**F10 menu** — if `ctld.JTAC_jtacStatusF10 = true`, a **JTAC Status** entry lists all active JTACs, their target, laser code and options (toggle lasing, request smoke, request 9-line). +### Pack Equipt -**Drone orbit** — if `ctld.enableAutoOrbitingFlyingJtacOnTarget = true`, flying JTAC units (drones) orbit above their lased target; they return to their flight plan when no target is visible. +The **Pack Equipt** submenu under **Crate Commands** lets players pack deployed equipment back into crates for relocation. It appears only when the helicopter is on the ground and at least one packable item is nearby. It is absent in flight. ---- +#### Pack Vehicle -## Smoke Drop +Pack a ground vehicle into crates for air transport, then reassemble it on the other side. -Transport units can drop coloured smoke grenades from the **Smoke Commands** F10 menu. +**Packing:** +1. Land near a packable vehicle (within `ctld.maximumDistancePackableUnitsSearch` meters). +2. The F10 menu shows **Pack Equipt → [vehicle name]** under Crate Commands. +3. Selecting it destroys the vehicle and spawns the required number of crates around the helicopter. -**Colours available:** Red, Blue, Orange, Green (colours hard-coded; the four entries are always present when `ctld.enableSmokeDrop = true`). +**Unpacking:** +1. Drop the crates at the destination. +2. Land near them and select **Unpack Crate** — the vehicle reassembles. -**Auto-Resume** — select **Toggle Smoke Auto-Resume** from the menu to keep smoke continuously active. When enabled, CTLD re-triggers smoke automatically every `ctld.smokeAutoResumeInterval` seconds (default 270 s — just before DCS smoke dissipates at ~300 s). The toggle is per-player; it can be enabled at any time and persists until the player toggles it off or disconnects. +Event `OnVehiclePacked` fires on successful pack. -**Disable globally:** set `ctld.enableSmokeDrop = false` in the YAML block. +**Enable:** `_cfg.settings["enablePackingVehicles"] = true` ---- +#### Pack FARP -## Recon and Target Marking +Pack a deployed FARP scene back into crates to redeploy it elsewhere. The FARP warehouse fuel levels are snapshotted and restored when the crates are unpacked at the new location. -CTLD includes a recon layer that places enemy contacts as F10 map markers. +**Packing:** -**Activate via F10** — select **Recon Scan** from the transport menu. Contacts within `ctld.reconSearchRadius` appear as icons on the F10 map (unit must be at or above `ctld.reconMinAltitude`). +1. Land near a deployed FARP (within 300 m). +2. The F10 menu shows **Pack Equipt → Pack [FARP name]** under Crate Commands. +3. Selecting it captures the current fuel levels, destroys the scene, and spawns crates around the helicopter carrying the fuel snapshot. -**Auto-refresh** — enable periodic re-scan via **Toggle Auto-Refresh** in the F10 menu (interval: `ctld.reconRefreshInterval`). +**Redeploying:** -**Icon scale** — `ctld.reconIconScale` multiplier applied to all RECON markers (default 1.0). +1. Fly to the new site, land, and unpack the crates — the FARP respawns with its fuel levels restored. -**Events fired:** +**Enable:** `_cfg.settings["enableFARPRepack"] = true` (default: `true`) -| Event | When | -|-------|------| -| `OnReconScan` | Manual scan triggered | -| `OnReconScanRefresh` | Auto-refresh cycle | -| `OnReconLayerToggled` | Map layer shown/hidden | +**Supported scenes:** `Countryside FARP`, `Metal FARP`. Custom scenes can support packing by implementing an `onRepack(scene, repackData)` hook — see the [Scenes & FOB guide](docs/mission-maker/scenes-fob.md). --- @@ -1024,44 +956,108 @@ CTLDCrateAssemblyManager.TEMPLATES = { --- -## Pack Equipt +## Virtual Parachute Drop -The **Pack Equipt** submenu under **Crate Commands** lets players pack deployed equipment back into crates for relocation. It appears only when the helicopter is on the ground and at least one packable item is nearby. It is absent in flight. +When `canParachuteDrop = true` on the aircraft type and the unit is airborne above the minimum altitude: -### Pack Vehicle +- The menu shows **Parachute [Troops / Crate / Vehicle]**. +- Each item has independent forward inertia (`ctld.parachuteInertiaFactor` × transport speed) plus random lateral drift (`ctld.parachuteLateralDriftMin`–`ctld.parachuteLateralDriftMax`). +- Troops land dispersed; parachuted crates auto-unpack on landing if the target area is clear within `ctld.autoUnpackRadiusParachute`. -Pack a ground vehicle into crates for air transport, then reassemble it on the other side. +> **Crate parachute limitation:** only crates loaded via the **CTLD F10 menu** (Load Crate / hover-load / virtual slingload) are eligible for parachute drop. Crates loaded through the DCS native cargo system (`useNativeDcsCargoSystem = true`) are managed by DCS and cannot be released via CTLD's parachute menu. -**Packing:** -1. Land near a packable vehicle (within `ctld.maximumDistancePackableUnitsSearch` meters). -2. The F10 menu shows **Pack Equipt → [vehicle name]** under Crate Commands. -3. Selecting it destroys the vehicle and spawns the required number of crates around the helicopter. +--- -**Unpacking:** -1. Drop the crates at the destination. -2. Land near them and select **Unpack Crate** — the vehicle reassembles. +## Forward Operating Base (FOB) -Event `OnVehiclePacked` fires on successful pack. +A FOB provides a new crate spawn point and optionally a troop pickup point anywhere on the map. -**Enable:** `_cfg.settings["enablePackingVehicles"] = true` +1. Load FOB crates at a logistic zone (large crates require large aircraft; small crates count as 1/3). +2. Drop `ctld.cratesRequiredForFOB` large crates (or equivalent in small) within 100 m of each other. +3. Select **Build FOB** — the FOB spawns with a radio beacon. +4. The built FOB appears in F10 as a new logistic point for crate spawning. +5. If `ctld.troopPickupAtFOB = true`, troops can also be loaded there. -### Pack FARP +Event `OnFOBDeployed` fires when construction completes. -Pack a deployed FARP scene back into crates to redeploy it elsewhere. The FARP warehouse fuel levels are snapshotted and restored when the crates are unpacked at the new location. +--- -**Packing:** +## FARP Deployment -1. Land near a deployed FARP (within 300 m). -2. The F10 menu shows **Pack Equipt → Pack [FARP name]** under Crate Commands. -3. Selecting it captures the current fuel levels, destroys the scene, and spawns crates around the helicopter carrying the fuel snapshot. +A FARP (Forward Arming and Refuelling Point) is deployed as a scene: a sequence of static objects (helipads, fuel trucks, shelters) spawn around the helicopter. -**Redeploying:** +1. At a logistic zone, spawn and load a FARP crate. +2. Fly to the desired deployment site and land. +3. Select **Deploy FARP** — the scene executes step-by-step over several seconds. +4. The deployed FARP becomes active in DCS for rearming and refuelling. -1. Fly to the new site, land, and unpack the crates — the FARP respawns with its fuel levels restored. +--- -**Enable:** `_cfg.settings["enableFARPRepack"] = true` (default: `true`) +## Radio Beacons -**Supported scenes:** `Countryside FARP`, `Metal FARP`. Custom scenes can support packing by implementing an `onRepack(scene, repackData)` hook — see the [Scenes & FOB guide](docs/mission-maker/scenes-fob.md). +Beacons broadcast on HF/FM, UHF and VHF simultaneously. Frequencies are drawn from coalition pools to avoid conflicts. + +**Deploying via F10** — land (or hover), select **Drop Beacon** from the menu. The beacon appears on the F10 map. + +**Deploying via script** — `ctld.createRadioBeaconAtZone("zone", "blue", 30, "Waypoint Alpha")` + +**Battery life** — configured by `ctld.deployedBeaconBattery` (minutes). After expiry the beacon stops transmitting. + +**ADF tuning by aircraft:** + +| Aircraft | Band | Notes | +|----------|------|-------| +| A-10C/II | UHF | ADF page in EHSI | +| Ka-50 | UHF | ARK-22 | +| Mi-8 / Mi-24 | VHF/FM | ARC-9 | +| UH-1H | VHF | ADF | +| All others | FM | Tune to displayed frequency | + +--- + +## JTAC Auto-Lase + +**Mission-editor JTACs** — place the JTAC unit in a dedicated single-unit group. Activate via `ctld.JTACAutoLase("GroupName", laserCode)`. See full syntax in [Mission Editor Script Functions → JTAC](#jtac). + +**Crate-deployed JTACs** — spawn a JTAC crate (`Hummer - JTAC` or `SKP-11 - JTAC`), drop it, and unpack it. The JTAC auto-activates immediately. + +**Target priority** — include `hpriority` or `priority` in the unit name (Mission Editor) to control lasing order. + +**F10 menu** — if `ctld.JTAC_jtacStatusF10 = true`, a **JTAC Status** entry lists all active JTACs, their target, laser code and options (toggle lasing, request smoke, request 9-line). + +**Drone orbit** — if `ctld.enableAutoOrbitingFlyingJtacOnTarget = true`, flying JTAC units (drones) orbit above their lased target; they return to their flight plan when no target is visible. + +--- + +## Smoke Drop + +Transport units can drop coloured smoke grenades from the **Smoke Commands** F10 menu. + +**Colours available:** Red, Blue, Orange, Green (colours hard-coded; the four entries are always present when `ctld.enableSmokeDrop = true`). + +**Auto-Resume** — select **Toggle Smoke Auto-Resume** from the menu to keep smoke continuously active. When enabled, CTLD re-triggers smoke automatically every `ctld.smokeAutoResumeInterval` seconds (default 270 s — just before DCS smoke dissipates at ~300 s). The toggle is per-player; it can be enabled at any time and persists until the player toggles it off or disconnects. + +**Disable globally:** set `ctld.enableSmokeDrop = false` in the YAML block. + +--- + +## Recon and Target Marking + +CTLD includes a recon layer that places enemy contacts as F10 map markers. + +**Activate via F10** — select **Recon Scan** from the transport menu. Contacts within `ctld.reconSearchRadius` appear as icons on the F10 map (unit must be at or above `ctld.reconMinAltitude`). + +**Auto-refresh** — enable periodic re-scan via **Toggle Auto-Refresh** in the F10 menu (interval: `ctld.reconRefreshInterval`). + +**Icon scale** — `ctld.reconIconScale` multiplier applied to all RECON markers (default 1.0). + +**Events fired:** + +| Event | When | +|-------|------| +| `OnReconScan` | Manual scan triggered | +| `OnReconScanRefresh` | Auto-refresh cycle | +| `OnReconLayerToggled` | Map layer shown/hidden | --- @@ -1111,37 +1107,8 @@ For the full migration guide including the v1 `addCallback` → typed events tra --- -## Developer Guide - -See the [Developer documentation](docs/developer/index.md) for: - -- Repository structure (`src/`, `tests/`, `tools/`, `docs/`, `source/`) -- Architecture overview (singleton managers, EventDispatcher) -- How to add a new module -- Event pub/sub patterns -- Build instructions (local `merge_CTLD.ps1`, CI via GitHub Actions) -- Unit testing with busted (no DCS required) -- Full v1 → v2 migration guide - -**Build locally:** - -``` -cd tools/build -powershell -ExecutionPolicy Bypass -File tools/build/merge_CTLD.ps1 -``` - -Output: `CTLD.lua` at repo root. - -**Testing:** - -``` -# Install busted once (requires lua5.1 + luarocks) -luarocks install busted - -# Run all tests (929 specs, no DCS required) -busted tests/ -``` - -Tests live in `tests/ci/unit/` (L1 — unit) and `tests/ci/functional/` (L2 — functional). DCS stubs and module loaders are in `tests/ci/helpers/`. See [`docs/developer/building-and-testing.md`](docs/developer/building-and-testing.md) for the full build and testing guide. +## Documentation -**CI:** every push to `master` or `feature_*` branches runs Lua lint, merge build, and busted tests automatically. Every `v*` tag creates a GitHub Release with `CTLD.lua` attached. +- [Pilot guide](https://veaf.github.io/CTLD/dev/pilot/) +- [Mission maker guide](https://veaf.github.io/CTLD/dev/mission-maker/) +- [Developer documentation](https://veaf.github.io/CTLD/dev/developer/)