Zgadzam się ze wszystkim. Może poza tym, że nie da się skonwertować starych scenerii. Dlaczego ma się nie dać? To nie będzie może proste, ale wykonalne. Masz przykładowo teraz eventy. Wyzwalane przez tor. Wywalasz wyzwalanie z toru, przenosisz do skryptu. Nowy format skryptu scenerii będzie przecież jak najbardziej obsługiwał zdarzenia typu "skład wjechał na tor x w kierunku y". Czyli możesz w tym skrypcie umieścić takie zdarzenie. Sterowanie semaforami i zwrotnicami można przenieść prawie w całości.
Domyślam się w czym jeszcze leży problem: od dawna postulowałeś (z resztą, swojego czasu @Ra chyba też), żeby nie dotykać semaforów bez potrzeby, nie sterować ruchem całkowicie ręcznie. Tzn skrypt ustawia przebieg, ale nie zapala sygnałów, sygnały się zapalają w zależności od przebiegu i ruchu składów. No i większość istniejących scenariuszy by z tym się gryzła. Ale jest na to sposób. Opcja manual i auto przełączana w skrypcie. W manualu wyłączasz całą automatykę sygnalizacji. Semaforki się zapalają tylko jak im każesz skryptem. Może z wyjątkiem SBL-ki. Nie widzę potrzeby sterowania nią ręcznie. A jeśli skrypt próbowałby wysłać coś poza Sz do semafora SBL to powinno być ignorowane, a nawet wylecieć przy konwersji.
W sumie nowy format będzie umożliwiał wszystko to co stary format, poza jedną rzeczą: nie wolno w torach umieszczać zdarzeń sterujących, muszą być w skryptach. Tak samo z resztą najlepiej zrobić z przypisaniami. Ani w torach, ani w skryptach, w osobnych plikach najlepiej. No ale to w zasadzie jest trywialna zmiana i to dałoby się skonwertować w pełni automatycznie. Tzn efektem konwersji automatycznej byłaby sceneria która działa, aczkolwiek nie ma większości rzeczy przypisanych i sterowana jest w pełni manualnie. Przejście na full-auto wymagałoby już w zasadzie napisania scenariusza na nowo - ale byłoby to łatwiejsze mając automatyczną obsługę SRK.
Co do rozkładów i opisów misji - oczywiście, nowy format jest konieczny. Moje narzędzie może produkować z tego PDF-y, nie ma sensu, żeby się bawić z tym w jakiś Wordach i Excelach. Nowy rozkład powinien zawierać wszystko, co jest potrzebne do wygenerowania takiego PDF-a. Do tego być prosty. JSON? A może CSV?
Co do formatu binarnego scenerii - bajer. Może być, może nie być. U mnie i tak przez 99% czasu ładują się tekstury. To jest IMHO trywialny problem.
Ostatnia sprawa: język. C++ to taki język, w którym proste rzeczy są koszmarnie trudne. Ten język ma zastosowanie wszędzie tam, gdzie zasoby sprzętowe są mocno ograniczone, a i można zainwestować dużo czasu i pieniędzy w developerkę. Do tego robi się coś raz "na fest" i nie dotyka przez lata. Ale robienie skomplikowanej logiki w tym języku to jak budowa komputera z wiadra tranzystorów i bramek logicznych. Kiedyś wszystko się robiło z elementów dyskretnych, teraz prawie nikt się w to nie bawi, nawet jeśli jest to prosty sterownik silniczka, to wrzuca się mu jakiś seryjnie produkowany procesor i po krzyku.
Największym deficytem projektu jakim jest MaSzyna nie są zasoby sprzętowe, a czas pracy developerów. Na wagę złota jest nie krzem, a czas wymagany do wprowadzenia jakiejś funkcjonalności a także czas potrzebny na rozwój. C# sprawdziłby się lepiej. No ale przejście nie byłoby łatwe. Baza kodowa jest potężna. Ale szaleć to szaleć ;) Jak dla mnie optymalne byłoby połączenie C# z C++ (a jeszcze lepiej Rustem zamiast C++, tylko kto zna Rusta?). W końcu nie bez powodu pojawił się w MaSzynie Python, problem w tym, że Python jest dość wolny. Ciężko byłoby go używać do dużych obliczeń fizyki w czasie rzeczywistym. Ale C# dałby radę z dużym zapasem. Przy czym ogromny skok kompatybilności, framework oddziela program nie tylko od metalu, ale i od bebechów systemu operacyjnego, które mogą się zmieniać. To mogłoby nawet na upartego stać się realnie wieloplatformowe. No ale wiem, to już czyste fantazje.
Co do "strasznego GC" - to dziś bardziej mit niż fakt. Głównie ze względu na to, że Windows i tak stosuje prawdziwą wielozadaniowość z wywłaszczeniem i to bardzo konkretnym wywłaszczeniem. Nie ma zmiłuj, jak OS postanowi sobie zwolnić trochę pamięci czy wykonać inne "super ważne zadanie", będzie zacinka, chociażby program był pisany w czystym assemblerze. Czas rzeczywisty w systemie takim jak Windows jest raczej nieosiągalny dla user-space. Jedynie na poziomie sterowników i jądra. Owszem, zbiórki GC mają swój koszt, ale na tyle niewielki, że na dzisiejszym sprzęcie jest to prawie niezauważalne. Druga sprawa, że działanie GC da się zoptymalizować tak, żeby w ogóle nie przeszkadzało. Na upartego nawet bezczelnie obejść i zabronić w krytycznych fragmentach.
I druga strona medalu - programując z niskiego poziomu można docisnąć CPU i nie grać fair z resztą systemu. I mamy potem gry z których ciężko zrobić Alt+Tab żeby wyjść na chwilę odpisać na ważnego maila. Jak dla mnie dla kilku dodatkowych FPS kompletnie nie warto. Wolę takie, które nie biorą sobie 101% zasobów systemu i zostawiają jakąś niewielką funkcjonalność tła. A jak mi czasem FPS spadnie na chwilę z 60 do 40, da się przeżyć. Jeszcze jedno - w C++ zrobienie dobrego kodu wielowątkowego korzystającego z wielordzeniowych CPU to zadanie dość ambitne i trudne. To samo w C# jest niemal trywialne. No dobra, amator nie zrobi stabilnej synchronizacji wątków, ale .NET ma niesamowite automaty zrównoleglające wątki. Jak wiesz jak tego użyć, oszczędzisz miesiące czasu. Przy okazji źródła są czytelne i mniej podatne na błędy. Robiłem tez test polegający na przydzieleniu przemieleniu kilku GB (powyżej 4) w C++ i C#. Różnice wydajności były pomijalne. Jasne, wersję w C++ można by zoptymalizować tak, żeby banglała 100x szybciej, ale to już byłby ASM i programowanie pod konkretny sprzęt, głównie CPU.