docs(roadmap): mobile pickup zone on a transport truck + FARP correction

[FullGas1]

Summary

• Adds a roadmap idea: attaching a TRZ_ to a transport truck as a mobile troop pickup point that follows the truck — requested by the user.
• Notes that createTroopZoneAtObject already resolves any unit/static via _linkedUnit (the same anchor mechanism already proven for a ship-anchored zone), so the position-following half may already work today with zero new code — flagged as needing live verification, not assumed.
• Corrects a stale claim in the existing "Lien générique zone ↔ objet de référence" entry: it assumed FARP would need the same composite integrity model as FOB. FEAT-FARP-TROOP-PICKUP (PR feat(farp): register a troop pickup zone when a FARP scene completes #137) showed FARP is a real DCS Airbase (binary isExist()), reusing CTLDStaticWatcher instead — corrected inline.

Test plan

• Docs-only change, no code/tests affected.

Summary by Sourcery

Document mobile troop pickup zones on transport trucks and correct the roadmap’s FARP lifecycle assumptions.

Enhancements:

• Document a roadmap proposal for mobile troop pickup zones anchored to transport trucks, noting that existing object-linked zones may already support position tracking and identifying automation and cleanup decisions for future work.
• Clarify that FARP lifecycle handling differs from FOB handling because FARPs are native DCS airbases with binary existence checks.

Documentation:

• Update the roadmap with the transport-truck mobile pickup-zone use case and correct the FARP lifecycle explanation.

[sourcery-ai]

Reviewer's Guide

Updates the roadmap with a transport-truck mobile TRZ_ concept and its unresolved automation/cleanup decisions, while correcting the FARP lifecycle documentation to reflect native Airbase existence and CTLDStaticWatcher-based polling.

Sequence diagram for a mobile troop pickup zone anchored to a transport truck

sequenceDiagram
    participant MM as MissionManager
    participant ZM as CTLDZoneManager
    participant Resolver as _resolveTroopZoneObject
    participant Zone as CTLDTroopZone
    participant Truck as TransportTruck

    MM->>ZM: createTroopZoneAtObject(MonCamion, TRZ_...)
    ZM->>Resolver: _resolveTroopZoneObject(MonCamion)
    Resolver-->>ZM: Truck Unit
    ZM->>Zone: Create zone with linkedUnit
    loop While truck exists
        Zone->>Truck: isAlive()
        Zone->>Truck: getCenter()
        Truck-->>Zone: Current position
        Zone->>Zone: Update pickup zone position
    end
    alt Truck destroyed
        Zone-->>Zone: Freeze at last known position
    end

Loading

File-Level Changes

Change	Details	Files
Documents a proposed mobile troop pickup zone anchored to a transport truck, while identifying that position following may already be supported by the existing linked-object mechanism.	Adds the transport-truck use case and expected TRZ_ behavior. Connects the proposal to createTroopZoneAtObject, _linkedUnit, and existing ship-anchor behavior. Separates remaining decisions around automatic creation and anchor-destruction cleanup. Marks live verification as required before treating this as a code gap.	dev/roadmap.md
Corrects the roadmap’s FARP lifecycle assumptions based on the implemented FARP pickup work.	Removes the claim that FARP requires FOB-style composite integrity tracking. Documents FARP as a native DCS Airbase with binary isExist() semantics. Records reuse of CTLDStaticWatcher for FARP lifecycle polling.	dev/roadmap.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="dev/roadmap.md" line_range="304-313" />
<code_context>
+
+Constat en explorant le code existant : **la moitié "suivi de position" de cette idée est déjà
+livrée, sans code nouveau.** `createTroopZoneAtObject` résout déjà un `objectName` quelconque —
+zone éditeur, **unité ou statique**, groupe, ou airbase (`_resolveTroopZoneObject`,
+`CTLD_zone.lua:1615`) — et pour une unité/statique/groupe, pose `linkedUnit` sur la
+`CTLDTroopZone` créée, exactement le même mécanisme déjà utilisé pour une TRZ_ ancrée sur un
+navire (`FIX-SHIP-ZONE-ANCHOR-PARITY`). Rien n'y limite le type d'unité à un navire — un camion
+DCS ordinaire (`Unit`) fonctionne déjà de la même façon. Concrètement : un MM peut probablement
+déjà appeler `CTLDZoneManager:createTroopZoneAtObject("MonCamion", "TRZ_...")` aujourd'hui et
+obtenir une zone de pickup qui suit le camion — **à vérifier en test live avant de considérer que
+c'est un vrai gap**, mais rien dans le code lu ne l'empêche.
+
</code_context>
<issue_to_address>
**issue (bug_risk):** The roadmap presents `createTroopZoneAtObject("MonCamion", ...)` as resolving the truck, but `_resolveTroopZoneObject` checks `trigger.misc.getZone(objectName)` before `Unit.getByName(objectName)`. When a Mission Editor trigger zone has the same name as the truck, the function creates a fixed trigger-zone-backed TRZ instead of a truck-linked zone, so the pickup zone does not follow the truck.

**Triggers:** When the transport truck shares its name with a Mission Editor trigger zone.

**Suggested fix:** Document the trigger-zone precedence and require unique truck names, or change the resolver to disambiguate the requested object type.

```suggestion
Constat en explorant le code existant : **la moitié "suivi de position" de cette idée est déjà
livrée, sans code nouveau, sous réserve d'une résolution de nom sans collision.**
`createTroopZoneAtObject` résout un `objectName` quelconque — zone éditeur, **unité ou statique**,
groupe, ou airbase (`_resolveTroopZoneObject`, `CTLD_zone.lua:1615`) — mais `_resolveTroopZoneObject`
consulte d'abord `trigger.misc.getZone(objectName)`, avant `Unit.getByName(objectName)`. Une zone
éditeur portant le même nom qu'un camion prend donc la priorité et produit une TRZ fixe, au lieu
d'une zone liée au camion. Les noms des camions doivent par conséquent être uniques vis-à-vis des
zones trigger de la mission. Pour une unité/statique/groupe effectivement résolu, la fonction pose
`linkedUnit` sur la `CTLDTroopZone` créée, exactement le même mécanisme déjà utilisé pour une TRZ_
ancrée sur un navire (`FIX-SHIP-ZONE-ANCHOR-PARITY`). Rien n'y limite le type d'unité à un navire —
un camion DCS ordinaire (`Unit`) fonctionne déjà de la même façon. Concrètement : un MM peut
appeler `CTLDZoneManager:createTroopZoneAtObject("MonCamion", "TRZ_...")` aujourd'hui si
`MonCamion` est unique par rapport aux zones trigger, et obtenir une zone de pickup qui suit le
camion — **à vérifier en test live avant de considérer que c'est un vrai gap**.
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): The roadmap presents createTroopZoneAtObject("MonCamion", ...) as resolving the truck, but _resolveTroopZoneObject checks trigger.misc.getZone(objectName) before Unit.getByName(objectName). When a Mission Editor trigger zone has the same name as the truck, the function creates a fixed trigger-zone-backed TRZ instead of a truck-linked zone, so the pickup zone does not follow the truck.

Triggers: When the transport truck shares its name with a Mission Editor trigger zone.

Suggested fix: Document the trigger-zone precedence and require unique truck names, or change the resolver to disambiguate the requested object type.

Suggested change

	Constat en explorant le code existant : **la moitié "suivi de position" de cette idée est déjà
	livrée, sans code nouveau.** `createTroopZoneAtObject` résout déjà un `objectName` quelconque —
	zone éditeur, **unité ou statique**, groupe, ou airbase (`_resolveTroopZoneObject`,
	`CTLD_zone.lua:1615`) — et pour une unité/statique/groupe, pose `linkedUnit` sur la
	`CTLDTroopZone` créée, exactement le même mécanisme déjà utilisé pour une TRZ_ ancrée sur un
	navire (`FIX-SHIP-ZONE-ANCHOR-PARITY`). Rien n'y limite le type d'unité à un navire — un camion
	DCS ordinaire (`Unit`) fonctionne déjà de la même façon. Concrètement : un MM peut probablement
	déjà appeler `CTLDZoneManager:createTroopZoneAtObject("MonCamion", "TRZ_...")` aujourd'hui et
	obtenir une zone de pickup qui suit le camion — **à vérifier en test live avant de considérer que
	c'est un vrai gap**, mais rien dans le code lu ne l'empêche.
	Constat en explorant le code existant : **la moitié "suivi de position" de cette idée est déjà
	livrée, sans code nouveau, sous réserve d'une résolution de nom sans collision.**
	`createTroopZoneAtObject` résout un `objectName` quelconque — zone éditeur, **unité ou statique**,
	groupe, ou airbase (`_resolveTroopZoneObject`, `CTLD_zone.lua:1615`) — mais `_resolveTroopZoneObject`
	consulte d'abord `trigger.misc.getZone(objectName)`, avant `Unit.getByName(objectName)`. Une zone
	éditeur portant le même nom qu'un camion prend donc la priorité et produit une TRZ fixe, au lieu
	d'une zone liée au camion. Les noms des camions doivent par conséquent être uniques vis-à-vis des
	zones trigger de la mission. Pour une unité/statique/groupe effectivement résolu, la fonction pose
	`linkedUnit` sur la `CTLDTroopZone` créée, exactement le même mécanisme déjà utilisé pour une TRZ_
	ancrée sur un navire (`FIX-SHIP-ZONE-ANCHOR-PARITY`). Rien n'y limite le type d'unité à un navire —
	un camion DCS ordinaire (`Unit`) fonctionne déjà de la même façon. Concrètement : un MM peut
	appeler `CTLDZoneManager:createTroopZoneAtObject("MonCamion", "TRZ_...")` aujourd'hui si
	`MonCamion` est unique par rapport aux zones trigger, et obtenir une zone de pickup qui suit le
	camion — **à vérifier en test live avant de considérer que c'est un vrai gap**.