A connection and schedule release.
What's new
-
Sub-Airline Selector On The Timetable
Airline groups that file one schedule under several callsigns, eg: TUI UK, TUI BE, TUI NL, TUI DE, can run to thousands of routes, which made the schedule slow to load and awkward to search. The timetable now opens scoped to a single sub-airline, and an Airline picker in the toolbar switches between them with the flight count shown beside each. "All callsigns" restores the full schedule and "No callsign" shows routes filed under none. Airlines with nothing to choose between draw no picker at all.
-
Live Route Progress On The Booking
Once a flight is started, the plane icon and line between the two airports on the booking card become a progress bar. The plane moves along the route as you fly, with the distance remaining and the estimated time en route shown underneath, both updating live from the simulator. Progress is measured from your actual position relative to both airports rather than from the filed route distance, so holds, vectors, and a diversion around weather cannot push the aircraft past its destination or drag the bar backwards.
What's improved
-
A Connector Per Simulator
Connection settings now ask two questions instead of one: which connector to use for MSFS, FSX and Prepar3D (FSUIPC or SimConnect), and which to use for X-Plane (UDP or XPUIPC). Automatic mode is gone, because it existed only to guess which simulator was running and there is nothing left to guess once each family has its own setting. Pilots who fly both simulators no longer have to change anything when they switch. Your existing choice is carried across on first launch: SimConnect stays SimConnect; FSUIPC becomes FSUIPC for the Microsoft simulators and XPUIPC for X-Plane, which is the pair it always meant; and Automatic maps onto the new defaults of FSUIPC and X-Plane UDP, which is exactly what it already did.
-
FSUIPC No Longer Claims A Simulator You Connect Differently*
FSUIPC answers for both simulator families, and which one is on the other end is only known after it opens. It is now tried after the connectors that can only serve one family, and when it turns out to have answered for a simulator you have set to connect another way — XPUIPC replying when you fly X-Plane over UDP, for instance — the connection is closed again instead of being held open and blocking the connector you chose.
What's fixed
- Any failed read from the simulator was treated as a passing hiccup and the connection was left marked as connected, which stopped the app from ever retrying. Quitting the simulator, restarting FSUIPC, or a WideFS drop therefore left a badge reading connected that never produced another byte of flight data for the rest of the session, with no way back short of restarting vAOMS Connect.
- Any failed read from the simulator was treated as a passing hiccup and the connection was left marked as connected, which stopped the app from ever retrying. Quitting the simulator, restarting FSUIPC, or a WideFS drop therefore left a badge reading connected that never produced another byte of flight data for the rest of the session, with no way back short of restarting vAOMS Connect.
- Any failed read from the simulator was treated as a passing hiccup and the connection was left marked as connected, which stopped the app from ever retrying. Quitting the simulator, restarting FSUIPC, or a WideFS drop therefore left a badge reading connected that never produced another byte of flight data for the rest of the session, with no way back short of restarting vAOMS Connect.