Decide who requests each action
One sector can involve an aircraft, a virtual crew, a ground-service engine, ATC and a company companion. Before adding automation, make the division of work explicit.
Riccardo confirms using Fenix, GSX, FSHud and Animated First Officer in his setup. That confirms the editorial relevance of this desk; it does not establish exact installed versions or certify the full combination.
Our practical recommendation is to choose one initiating route for each service. Several applications can display or coordinate the same task, but an action should be requested deliberately and its result observed.
What we can currently establish
| Layer & task | Evidence state | Your next check |
|---|---|---|
| Fenix A320 + GSXAircraft loading and ground-service integration | Developer documented Fenix publishes an integration workflow; its linked guide was revised in February 2026. | Read the controls present in your build. Choose how service requests are initiated; check actual aircraft loading. |
| FS2Crew + Animated First OfficerCrew actions, checklists and optional GSX requests | Developer documented; V3 combination unverified The product page documents the base-pack requirement and GSX integration. The dated changelog reviewed does not establish Fenix V3 acceptance. | Verify the base pack and expansion. Identify whether crew automation also requests boarding or pushback. |
| GSX / CouatlGround vehicles, services and parking profiles | Product role documented FSDT documents services and configurable airport/aircraft profiles. A profile still needs to match the installed scenery. | Check the selected aircraft and airport profiles, then observe each requested service. |
| FSHud + TashkentATC/traffic context and airport recognition | Owner-confirmed local case The scenery alignment is documented; the owner reports the local issue resolved. The earlier AIG report records offline preparation. | Compare the airport and traffic references. Keep ground-service requests coordinated with the chosen pushback workflow. |
| UZB Ops 0.6.2Sector preparation, arrival context and documents | Public beta; live acceptance incomplete The reviewed package has scoped offline validation. Physical stand fit and aircraft TELEX reception are not certified. | Use a current sector/ETA source. Keep unsupported stand numbers pending and review after connection loss. |
| Pegasus / PhoenixVA booking, PIREP and activity record | Company operating reference Companion debrief notes do not replace the VA’s flight record. | Verify the booked sector and the filed/accepted record in the company system. |
A workable ground-operation plan
- Before loading. Match the VA sector, OFP and aircraft. Record the builds involved when investigating a problem.
- Boarding and fuel. Decide whether the aircraft integration, FS2Crew or a manual GSX action initiates the service. Confirm the resulting load in the aircraft.
- Pushback. Decide how it will be requested. If Fenix auto-pushback is enabled, treat its trigger as part of that plan; avoid an additional simultaneous request through another controller. Read the active FSHud/ATC instructions before movement.
- Arrival. Compare the parking allocation with scenery/profile geometry. Complete the chosen deboarding sequence before setting up the next sector.
- Turnaround. Finish prior companion monitoring, load the new OFP and recheck sector identity. Readiness in one application does not show that all others have reset.
These are coordination recommendations, not a manufacturer-certified preset for the entire stack. Apply the documentation for your actual builds and preserve the previous settings when making a local comparison.
What the official documents add
The Fenix GSX guide describes starting integrated loading from the EFB, optional automatic pushback and waiting for deboarding before importing the next plan. Its February revision predates V3; older limitations in that guide are not treated here as verified current V3 defects.
FS2Crew describes Animated First Officer as an expansion requiring its activated Fenix base pack. The reviewed Animated FO changelog’s newest dated entry is 12 August 2026. That date alone does not demonstrate compatibility with the October Fenix V3 release.
For detailed actions, use the manual matching the installed product. A manager reporting that an update exists does not show that a running application has been updated.
When something happens twice — or never happens
- Repeated service or pushback request: inspect which applications can initiate it and note the event sequence before changing several settings.
- Wrong airport or missing traffic: compare scenery, navigation and traffic-plan references separately. Use the Tashkent case as a documented local example.
- Missing arrival message: inspect sector, current ETA source, connection and dispatch state. Check delivery status separately from a preview.
- Wrong stand or misplaced vehicles: verify scenery identity and the exact ground profile. A real-world parking chart cannot validate simulator geometry.
- Second rotation still shows the first: check for active monitoring and old OFP context; confirm each application has moved to the new sector.
Keep a useful local record
A reproducible note needs the date, simulator/aircraft/app builds, scenery identity, action requested, observed result and the single change being compared. Keep screenshots/logs with that context. This is more useful than a blanket “compatible” badge.
The full toolkit still covers the other applications and controls in the setup. This first desk concentrates on the interfaces most relevant to this sector; it makes no claim that all 47 registry records were tested together.
Explore the complete MSFS toolkit →
Primary references and review date
Reviewed 30 October 2026. This desk separates developer documentation, the owner’s local FSHud outcome and incomplete acceptance checks. It is an editorial guide; no PC settings or installed software were changed for publication.