Oryginalna logika tworzenia ekranów była sztywna i trudna do rozszerzania. Każdy nowy ekran wymagał modyfikacji głównego pliku. Dodatkowo, system input dla radia był zbyt prosty i nie pozwalał na naturalną pracę z numeryczną klawiaturą.

Nowa architektura ekranów

Przeredagowałem system, aby każdy ekran był autonomicznym komponentem z własnymi metodami renderowania i obsługi inputu. System został uproszezony do przełączania się między ekranami za pomocą prostego mappingu. To umożliwia dodawanie nowych ekranów bez modyfikacji istniejącego kodu.

System Keypad

Zaimplementowałem obsługę numerycznej klawiatury ze standardem T9. Użytkownik może teraz naturalnie wprowadzać częstotliwości radia: naciśnie cyfrę, wynik pojawi się na ekranie, może go edytować (backspace), i zatwierdzić (enter).

Wyzwania

1. Zarządzanie stanem inputu

Keypad musiał pamiętać co użytkownik wpisał, obsługiwać edycję i walidować dane przed wysłaniem do backendu. Potrzebowałem oddzielnego state managementu dla każdego rodzaju inputu.

2. Integracja z Canvas

Keypad wyświetlany jest na Canvas, ale obsługuje rzeczywiste zdarzenia klawiatury. Musiałem mapować zdarzenia klawiatury na wizualne elementy keypad-u i na odwrót.

3. Validacja danych

Częstotliwości radia mają określone zakresy (COM: 118.00-136.975, NAV: 108.00-117.95). Keypad musiał walidować dane przed wysłaniem.

Wynik

System input jest teraz naturalny i intuicyjny. Logika ekranów jest czysta i łatwa do rozszerzania. Dodanie nowego ekranu zajmuje teraz ułamek czasu.

⌨️

MFD musiał działać jak prawdziwy multi-function display w kabinie samolotu - wyświetlać rzeczywiste dane lotu w czasie rzeczywistym, reagować na kliknięcia przycisków OSB (Option Select Buttons) i obsługiwać wprowadzanie danych poprzez keypad. Wszystko musiało działać sprawnie z 60 FPS.

Architektura MFD

Stworzyłem system wieloekranowy, gdzie każdy ekran odpowiada za inną funkcjonalność: autopilot, radio, PFD, radar, plan lotu i systemy. Użytkownik może przełączać się między ekranami za pomocą menu.

Obsługiwane ekrany

• AUTOPILOT - wyświetla i pozwala kontrolować heading, altitude i speed bugi
• RADIO - pełna kontrola COM1/COM2/NAV1/NAV2/XPDR z możliwością wpisywania częstotliwości
• PFD - tradycyjny primary flight display ze wskaźnikami pitch, bank, altitude, vertical speed
• RADAR - wyświetla pobliski ruch w zadanym zakresie
• FPL - planowanie lotów z wyświetlaniem waypoints
• SYSTEMS - parametry systemu: RPM, zużycie paliwa, temperatura

Wyzwania

1. Wydajność - 60 FPS

Canvas miał służyć do efektywnego renderowania. Zwyczajne przerysowywanie całego ekranu co klatkę szybko prowadzi do spadku FPS. Musiałem zaimplementować caching wyrenderowanych elementów, batch rendering updateów i używać RequestAnimationFrame zamiast setInterval.

2. Interaktywność z Canvas

Canvas to bitmap, nie ma wbudowanej obsługi interaktywnych elementów. Musiałem ręcznie mapować kliknięcia myszy na pozycje przycisków OSB. Kliknięcia na lewej krawędzi ekranu to przyciski 1-5, na prawej to 6-10.

3. Real-time data updates

MFD musiał być zawsze zsynchronizowany z rzeczywistymi danymi z symulatora. Zaimplementowałem polling co sekundę, co jest optymalnym balansem między świeżością danych a obciążeniem sieci.

Wynik

Uzyskałem płynny, responsywny interfejs MFD, który odwzorowuje rzeczywiste multi-function displayy. System jest modularny - każdy ekran jest niezależnym komponentem, co ułatwia dodawanie nowych funkcji.

🖥️

Każdy typ samolotu w MSFS potrzebuje innego zestawu poleceń do kontroli radia i autopilota. Stock aircraft (Cessna, Boeing) używają standardowych SimEvents, ale addon aircraft takie jak PMDG lub Fenix używają lokalnych zmiennych (L-Vars). Potrzebowałem elastycznego systemu, który automatycznie rozpozna typ samolotu i wyśle odpowiednie komendy.

Architektura rozwiązania

System oparty jest na fabryce mapperów (Factory Pattern). Najpierw detektor analizuje dane z symulatora, aby określić typ samolotu, a następnie fabryka tworzy odpowiedni mapper, który wie jak komunikować się z tym konkretnym typem.

Obsługiwane typy

• Stock MSFS - Cessna, Boeing, Airbus - w pełni wspierane poprzez SimEvents
• PMDG 737/777/747 - aktualnie fallback do stock, czeka na implementację L-Vars
• Fenix A320 - aktualnie fallback do stock, czeka na implementację L-Vars
• TBM 930 - w pełni wspierane
• QualityWings 787, Aerosoft CRJ - zaplanowane

Wyzwania

1. Detekcja typu samolotu

Istnieje wiele parametrów, które mogą wskazywać na typ samolotu - numer boczny, typ silnika, typ avioniki (G1000 vs modern glass cockpit), czy konfiguracja z pliku panel.cfg. Musiałem stworzyć heurystykę, która z rozsądnym stopniem pewności określi typ samolotu.

2. L-Vars - Problem bez rozwiązania

Addon aircraft takie jak PMDG czy Fenix przechowują swój stan w lokalnych zmiennych (L-Vars), do których SimConnect nie ma dostępu. Aby w pełni wspierać te samoloty, potrzebowałbym albo:

• Modułu WASM napisanego w C++
• Integracji z FSUIPC
• Dostępu do dokumentacji od producenta

Aktualnie jest to największe ograniczenie projektu.

3. Elastyczność systemu

Każdy nowy samolot wymaga nowego mappera. System musiał być zaprojektowany w taki sposób, aby dodawanie nowych typów było proste i nie wymagało zmiany istniejącego kodu.

Wynik

Wdrożyłem system oparty na interfejsach i polimorfizmie, który pozwala na łatwoe dodawanie nowych typów samolotów. Stock aircraft są w pełni wspierane, a addon aircraft działają w ograniczonym trybie do czasu, aż rozwiążę problem L-Vars.

✈️

Microsoft Flight Simulator ma znane ograniczenie: funkcja SetDataOnSimObject nie działa dla częstotliwości standby radia. Oznacza to, że bezpośrednia zmiana wartości w pamięci symulatora jest niemożliwa. To był główny problem do rozwiązania.

Rozwiązanie: Event Emulation

Zamiast próbować zmienić bezpośrednio wartości, postanowiłem emulować naciskanie przycisków zwiększających/zmniejszających częstotliwość. Simulator przyjmuje rozkazy takie jak “zwiększ COM1” lub “zmniejsz NAV1”, które są wysyłane wielokrotnie.

Wyzwania implementacji

1. Precyzja frecji

Każda zmiana na jednym przycisku to krok o określoną wartość:

• COM radios: 25 kHz
• NAV radios: 50 kHz

Aby zmienić częstotliwość z 120.00 do 127.45 MHz, potrzebuję około 298 pojedynczych kliknięć. Wysłanie ich wszystkich naraz spowodowałoby, że simulator nie zdążyłby przetwarzać zdarzeń.

2. Timing i batch processing

Symulator potrzebuje czasu na przetworzenie każdego zdarzenia. Wysyłanie zdarzeń w zbyt szybkim tempie powoduje ich ignorowanie lub przeskakiwanie. Rozwiązaniem jest wysyłanie zdarzeń w partiach po 10 sztuk z przerwą 50ms między partiami.

3. Transponder BCO16

Transponder używa innego formatu danych - BCO16 (4 bity na cyfrę). Wartość dziesiętna musi być skonwertowana na format heksadecymalny ze specjalnymi ograniczeniami (tylko cyfry oktalne 0-7).

Wynik

Implementacja batch processing pozwala na niezawodną zmianę częstotliwości radia. Choć zajmuje to około 1,5 sekundy dla pełnego zakresu, rezultat jest precyzyjny i nie wymaga dodatkowych modułów czy integracji zewnętrznych bibliotek.

📻

Główne cechy

• SimConnect Integration - bezpośrednie połączenie z MSFS
• X-Plane Support - wsparcie poprzez UDP
• Aircraft Detection - automatyczna detekcja typu samolotu
• Radio Control - zarządzanie częstotliwościami COM/NAV/XPDR
• Autopilot Control - sterowanie bugami HDG/ALT/SPD
• MFD Web Interface - interfejs oparty na Canvas z 60 FPS
• AI Traffic - śledzenie pobliskiego ruchu
• Flight Planning - tworzenie planów lotów dla AI

Architektura

Projekt dzieli się na trzy warstwy:

1. Backend (.NET 8.0) - integracja z SimConnect i X-Plane, obsługa komend
2. API - REST endpoints dla radiów, autopilota, danych lotu
3. Frontend (JavaScript) - Canvas MFD z wieloma ekranami
4. Mockup

Kod dostępny na GitHubie: m-lukaszewski/FSAPI_MFD

Więcej szczegółów w kolejnych wpisach! ✈️