Symulator/MaSzyna/21.04/Uwagi

Wnioski po zakończonym etapie przeliczenia zachodniej części linii 61, po przetestowanie wszystkich misji po kolei, na paczce MaSzyna 21.04. Być może w późniejszych paczkach zostało coś z tego poprawione, ale wolałem dosyć zaawansowane zmiany w plikach scenerii testować w konsekwentnie na jednej paczce, mając świadomość, co w niej może nie działać poprawnie (żeby się błędy nie nałożyły). Sprawdzę przy okazji kolejnych testów, ale przynajmniej mam tu spisane, na co uwagę zwrócić.

Start w trybie manewrowym zamiast pociągowego

W tzw. "czasach słusznie minionych" stan początkowy pociągu był określony jednoznacznie:

Jeśli rozkład jest podany jawnie jako none, powinien się uruchomić tryb manewrowy.
Jeśli skład ma podany rozkład, startuje w trybie pociągowym. Kiedyś jednak wprowadziłem wyjątek, że niezerowa prędkość mniejsza niż 0.1, załącza tryb manewrowy (np. 0.01).

Aby składy startowały w trybie pociągowym, do paczki dodany był pusty plik rozklad.txt (a Rainsted tworzył go, jeśli nie znalazł). Dodałem też wyjątek, że zamiast nazwy pliku można było podać liczbę (nadającą się na wartość prędkości w km/h, np. "70"), przez co można było uzyskać inną prędkość maksymalną (dla pustego pliku było przyjmowane 100km/h).

Dziwnie wygląda mijanie na szlaku składów, które stoją ze światłem manewrowym. Np. przed wjazdowym w Herbach Starych. Nie dopatrzyłem się uzasadnienia, dlaczego taka zmiana została wprowadzona. Również nie wiem, dlaczego ktoś, kto ją wprowadził, nie dostosował scenerii, żeby składy startowały w trybie pociągowym. Ostatnio też przeczytałem, że również samochody jeżdżą w trybie manewrowym...

Start z uruchomionym pociągiem

Kiedyś pociąg z wpisaną prędkością początkową od razu startował jako uruchomiony. Gdy integrowałem linie rozwojowe w 2013 roku, doszedł problem załączenia baterii oraz ciśnienia w zbiorniku pantografu, przez co wyłączyłem tymczasowo "samoczynne uruchamianie" (bo i tak przestało działać). Naprawiłem to dopiero w połowie 2015 roku. Jednak wersja z "odhamowanym rozwojem" nadal nie obsługuje startu z uruchomionym pociągiem, przez 7 lat jakoś nikt się tym nie przejął, że załączanie baterii i podnoszenie pantografów jest trochę bez sensu, gdy pociąg się zbliża do semafora wjazdowego...

Zderzenia samochodów

Zupełnie nie rozumiem, po co ktoś wprowadził zderzenia samochodów, jeśli nie potrafią one unikać zderzeń. Np. na linii 61 widać zderzone ze sobą kolejne samochody. Nie wiem, czy na tej paczce też to jest, ale na wcześniejszych samochody potrafiły w siebie wjechać tak, że się nakładały.

Na paczce MaSzyna 23.07 nadal samochody się zderzają i pozostają w miejscu zderzenia.

Opóźnione animacje

Jedną z rzeczy, którą zostawiłem sobie na później do poprawienia, jest wykonanie niewidocznych animacji. W stanie zastanym w 2010 roku animacje zaczęły się wykonywać dopiero po pojawieniu się obiektów w obszarze renderowania. Aby wykryć zakończenie animacji, dodałem eventy *:done, co miało pozwolić na wykonanie kolejnych operacji niezależnie od czasu trwania animacji (np. było przydatne dla obrotnicy). Jednak, animacja powinna się również wykonywać, gdy obiekty są poza obszarem renderowania (aby manewry na obrotnicy wykonały się poprawnie, niezależnie od tego, czy ktoś je ogląda, czy nie). Po 7 latach widzę, że chyba tylko mi to przeszkadzało... Jest to szczególnie istotne ze względu na animacje przejazdu i uzależnienie podania semafora od zamknięcia przejazdu. Gdyby teraz wprowadzić takie uzależnienie, to przejazd poza obszartem renderowania się nie zamknie i pociąg nie dostanie wyjazdu...

Zbyt szybko przewijany rozkład dla departuredelay

Kiedyś zaproponowałem, aby opóźnić wykonanie eventu względem czasu odjazdu. O ile opóźnione układanie przebiegu działa w miarę dobrze, o tyle synchronizacja podania semafora do godziny odjazdu rąbie się koszmarnie... bo zwykle wcześniej przełącza się rozkład na kolejną stację. Przełączenie na kolejną stację na potrzeby departuredelay powinno być mniej więcej powiązanie ze znikaniem posterunku z rozkładu (chociaż ten znika zbyt szybko, powinno to być w okolicy W5).

Prędkość semaforów dla Sz

Prędkość ta powinna różna, zależnie od tego, czy wyjazd jest na SBL (20km/h), czy nie (40km/h). Coś mi się kojarzy, że kiedyś próbowałem uporządkować semafory w tym zakresie, ale nie byłem w stanie wysłać moich zmian, bo ktoś mi zablokował dostęp do SVN na eu07.pl. Albo powinny być osobne semafory wyjazdowe na blokady S i P, albo plik INC semafora powinien zawierać osobne wersje Sz (np. jako _Sz1p i _Sz1s).

Logowanie eventów none_

Aby nie definiować osobnych semaforów z tarczą i bez tarczy, zaproponowałem około 2010 roku opcję ignorowania eventów, których nazwy rozpoczynają się od "none_". Dzięki temu można do semafora podać "none" zamiast nazwy tarczy, a całe sterowanie tarczą zostanie zignorowane. Niemniej, te ignorowane eventy się logują w errors.txt, a nawet jako duplikaty.

Niezrozumienie sensu errors.txt

W założeniu do pliku errors.txt miały się zapisywać niektóre linie z log.txt, w szczególności te wskazujące na niespójności w danych i ewentualnie uszkodzenia podczas symulacji. Jednocześnie format tych informacji miał być zunifikowany, aby móc błędy rozpoznać dodatkowym oprogramowaniem. Np. Rainsted miał możliwość poprawienia błędnych dźwięków (które miały narzuconą częstotliwość, a jednocześnie w nagłówku była podana inna) oraz wyświetlenia miejsc zaników napięcia i uszkodzenia pantografów na podglądzie scenerii. Poprawna formalnie sceneria i normalnie przebiegająca symulacja nie powinny nic zapisywać do errors.txt. A jeśli coś zapisują, to jest coś do poprawienia, albo np. doszło do wykolejenia czy zderzenia i ewentualnie trzeba sprawdzić przyczyny.

Jednym z logowanych błędów do "errors.txt" było skalowanie pantografów. Dodałem logowanie tego jako błąd, ponieważ zrobiłem wyliczanie kątów dla ramion pantografów w zależności od wysokości zawieszenia sieci i z uwzględnieniem pozycji pantografu w modelu, a nie chciało mi się zastanawiać nad tym, jak wymiary pantografu zostaną zmienione przez macierz transformacji i jak następnie należy korygować kąt. Prościej było założyć, że modele składowe nie posiadają przekształcenia. W założeniu to logowanie miało prowadzić do poprawienia modeli pantografów, aby wyświetlały się poprawnie i bez użycia skalowania. Po czym ktoś wymyślił, że najlepiej będzie do "errors.txt" wepchnąć wszelkie skalowania. Może to i słusznie, ale przez 7 lat nie ma chętnych, żeby te "błędne" skalowania poprawić.

Od 7 lat obserwuję, że errors.txt potrafi mieć ponad sto kilobajtów, parę tysięcy linii i są tam logowane "błędy", których poprawieniem się nikt nie przejmuje. Ja rozumiem, że jeśli podłączyłem pierwotną wersję Linii 61 do Drawinowa, to może być z tego masa błędów (np. duplikatów) i wtedy errors.txt wyjdzie ogromny, a tak połączona sceneria nadaje się do użytku nawet mimo tych błędów. Ale scenerie przygotowane do paczki całościowej nie powinny tworzyć pliku errors.txt... Albo trzeba pomyśleć nad jakimś errors2.txt, do którego będą zapisywane naprawdę krytyczny błędy (duplikaty rozjazdów, semaforów, ale np. nie dróg)...

Usunięcie obiektów z paczki

Moim skromnym zdaniem do każdej nowej paczki powinna być tworzona lista plików, które zostały przemieszczone w inne miejsca oraz usuniętych (które powinny być zastąpione innymi obiektami). Nie jest sztuka powymieniać obiekty w jakimś pliku, sztuka jest móc je analogicznie powymieniać w sceneriach, które nie są dodane do paczki. Rozwiązanie takie opracowałem na potrzeby wymiany drzew w scenerii MZD: przy okazji którejś paczki dodano nowe tekstury drzew i zaktualizowano scenerie w paczce. Na podstawie porównania plików pomiędzy paczkami opracowałem listę "zmiany tekstur" (zmiany nie były jednoznaczne 1:1, czasem jedną teksturę wymieniano na kilka różnych). Na podstawie tej listy zaktualizowałem drzewa w scenerii MZD.

Tymczasem brakuje:

zegar.t3d — zegar doklejany do budynków dworców i latarni — po co został usunięty albo dokąd przesunięty i dlaczego nie poprawiono scenerii?
wasyl/reklama_duza.t3d — używałem tych obiektów do postawienia informacji o końcu torów. I nagle obiekty zniknęły.

Podjeżdżanie do sygnalizatorów

Widać to na misji "linia61_towarowy2". ET22 po uruchomieniu podjeżdża bliżej do tarczy manewrowej. Z początkowej odległości 7m do 2.3m. Po co? Musi niepotrzebnie ruszać z miejsca i następnie hamować. Z kolei SM31 ze składem sieciowym stanęło 4.4m za semaforem — w "czasach słusznie minionych" byłoby to niedopuszczalne.

Manewry do W5

W "czasach słusznie minionych" zrobiłem analizę trasy AI pod kątem jazdy manewrowej do W5. Na samym początku ten wskaźnik nie był uwzględniany w skanowaniu i dojechanie na określony tor uruchamiało komendę Change_direction, co czasem potrafiło doprowadzić do wyjechania lokomotywy za semafor wjazdowy. Niemniej, po wykryciu W5 załączało się skanowanie wsteczne, aby ustalić punkt zatrzymania przed tarczą zezwalającą na jazdę w przeciwną stronę. Było to szczególnie potrzebne do zmiany czoła składu w Mydelniczce — zbędne dojeżdżanie do W5 niepotrzebnie opóźniało pociąg. Obecnie lokomotywy dojeżdżają do W5, jakby w ogóle wprowadzone przeze mnie udoskonalenie wcale nie istniało.

Nie działa Manewrowo 3

W ramach porządkowania zaległych rzeczy sceneria została przeniesiona do pliku RSF. Jednak jej przetestowanie nie było możliwe, gdyż algorytm misji przestał działać. Poszczególne etapy misji uruchamiały się z bardzo dużym opóźnieniem. Nie wiadomo, na którym etapie prac nad paczką i symulacją błędy powstały, ale na pewno działało to poprawnie na paczce 15.02, w której sceneria była świeżo po zmianach dokonanych w 2014 roku.

Nieprzypisywanie aktywatora dla komendy z sygnalizatora

Aby ograniczyć konieczność tworzenia dodatkowych komórek pamięci (oraz wiązania ich z torami, na których może zatrzymać się skład) zostało wprowadzone wpisywanie komendy do sygnalizatorów (semaforów, tarcz manewrowych). Wpisana komenda, która nie jest ustawieniem prędkości, jest widoczna jako prędkość zerowa i powinna doprowadzić skład do zatrzymania się przed sygnalizatorem. Zatrzymany skład pobiera komendę, po czym wykonuje się event komórka:sent, gdzie "komórka" jest nazwą komórki pamięci sygnalizatora. Oczywiście nadal można dodawać własne komórki w tym celu — ale po co, jeśli można wykorzystać istniejące już sygnalizatory? Problemem jest jednak brak powiązania eventu komórka:sent z pojazdem, który komendę pobrał. W szczególności, nie można przez to ustalić czasu do wyjazdu z użyciem departuredelay, ponieważ event nie ma przypisanego pojazdu i nie można użyć jego rozkładu (np. przypisanego chwilę temu przez sygnalizator).

Problemy z wybudzaniem składów

Na Linii 61 są dwie misje, które startują z opuszczonymi pantografami, gdzie trzeba uruchomić pociąg od zera - "osobowy3" oraz "towarowy2". Trzeci przypadek jest w "towarowy2" i dotyczy pociągu sieciowego. Kiedyś było tak, że wystarczyło wysłać komendę "PrepareEngine 1 0" i skład się załączał, a użytkownikowi tylko sugerował załączenie. Jednak przestało to działać. Oczywiście nie jest to jedyna komenda uruchamiająca, można było wysłać inne, np. "Shunt".

EN57 w "osobowy3" miał być uruchomiony od zera - przestał się uruchamiać.
ET22 w "towarowy2" miał być uruchomiony od zera - przestał się uruchamiać. A jeśli dodatkowo dostanie komendę uruchamiającą, to w ogóle jakoś zamula.
Skład sieciowy w "towarowy2" powinien stać na szlaku będąc oświetlonym. Nagle od którejś paczki zaczął sobie sam zjeżdżać w kierunku stacji. Żeby stał, trzeba zrezygnować z komendy uruchamiającej, ale wtedy nie ma jak zapalić w nim świateł.

Utrata świadomości AI przy braku zasilania

Jeśli AI nie pobiera prądu z sieci trakcyjnej, to np. nie potrafi się zatrzymać przed semaforem. Kiedyś to likwidowałem i nie potrafię zrozumieć, w jakim celu ten błąd został przywrócony.

Dźwięki dla rozkładów

Aby usprawnić udźwiękowienie odjazdów, dorobiłem opcję wiązania dźwięku z nazwą rozkładu. W ramach reorganizacji paczki, aby zlikwidować podkatalogi models/, textures/ i sounds/, zrobiłem od razu poszukiwanie dźwięków w tym samym miejscu, co rozkład. Ale z czasem się okazało, że na realnych trasach są te same numery pociągów, a rozkłady różnią się godzinami. W efekcie nie ma sensu robienie dźwięku pod każdy rozkład osobno, gdy np. wszystkie 5513 mogłyby używać tego samego dźwięku. Tym samym powinien być mechanizm poszukiwania dźwięku do rozkładu w katalogu wyżej, czyli albo w scenery/, albo w tym przypadku byłby może sens użycia sounds/. Jednak kwestie reorganizacji podkatalogów zostały zarzucone, nadal wszystkie dźwięki pojazdów pchane są do sounds/, a katalog dodatkowo doczekał się podziału na scenerie. Koncepcja zakładała, że pliki dotyczące jednego obiektu znajdują się w jednym podkatalogu, chyba że używane są np. uniwersalne tekstury materiałów, jak "stal" czy "węgiel".

Nie działa overhead 0

AI nie jest w stanie ruszyć, jeśli stanie na odcinku z własnością "overhead 0" (pomiędzy We8a i We9b). Sytuacja taka jest przy semaforze G1 w Fosowskich. W takich przypadkach AI powinno zatrzymać się przed odcinkiem z "overhead 0". Powinno również umieć ruszyć z toru, wymagającego przejazdu z wyłączonym zasilaniem (używając jednego pantografu i np. szukając miejsca, w którym pantograf może przejść na sekcję z innym napięciem).

Gubienie dźwięków radiowych

W razie wyjścia z kabiny (do innej kamery albo do drugiej kabiny) przestają być słyszalne dźwięki radiowe. Po ewentualnym powrocie nie są one kontynuowane. Być może ma to pewien sens, ale skoro już zostały "skrócone" pewne "uciążliwości", to takie coś chyba też powinno. Przykładowo, ja specjalnie nie umieściłem zegarka na podglądzie rozkładu, ponieważ w rzeczywistej lokomotywie na ogół zegarek oraz rozkład są osobno i trzeba patrzeć w różne miejsca...

Zasięg dźwięków radiowych

Kiedyś robiłem tak, by dźwięki radiowe były słyszalne w kwadracie ±2km, niezależnie od obszaru renderowania. Teraz jest chyba jakoś inaczej, bo za Lublińcem słyszalne są dźwięki z Herbów Starych ("linia61_towarowy2").

Nazwy zaczynane od #

Moim zamysłem było, aby powtórzenie nazw zaczynanych od # nie było logowane jako błąd (duplikat). W szczególności chodziło o elementy sygnalizacji, które z jakiegoś względu mogły mieć nazwę, ale w konkretnym przypadku nie miało to znaczenia (nazwa była tylko komentarzem). Osobną kwestią do przemyślenia było, czy np. Obecnie logowane są np. nazwy dróg. Oczywiście nazwy dróg mają znaczenie w przypadku wstawiania pojazdów drogowych, ale czasem nazwa odcinka drogi jest tylko nazwą ulicy i nie ma to znaczenia, gdzie dokładnie zostanie wstawiony samochód.

Zatrzymywanie towarowych na W4

W misji "l61+l144_towarowy" pociąg towarowy ma postój w Pawonkowie. Staje przy peronie mając wagony na rozjeździe i blokuje pośpiesznego. Po odczekaniu do godziny odjazdu rusza dalej i wtedy pośpieszny może pojechać.

Propozycja moja jest, aby pociąg wiedział, czy jest towarowym, czy nie. I jeśli nie jest, to nie powinien stawać przy W4, który ma definicję krawędzi peronowej (1..3). Za to może stawać przy W4 bez krawędzi peronowej. Przykładowo, na stacji Czernica Wrocławska jest przejazd w środku stacji, a przed nim są W4...
Druga opcja, to ogólne przejechanie za W4, jeśli jest konieczne do ściągnięcie końca składu poza ukres. Czasem jednak jest rozjazd w środku toru, więc można by przyjąć zasadę, że maksymalnie jeden rozjazd może być pod składem i nie może być na jego końcu.

Jazda do tyłu

Po uruchomieniu misji i załączeniu AI w "l61+l144_osobowy" skanowanie było do przodu (na północ), a pociąg zaczął jechać do tyłu.

Lewitujące podsypki

Kiedyś z założenia zrobiłem podsypki jako nieprzezroczyste, bo mi się wydawało, że nie ma sensu robić dziur w podsypkach. Ale potem "przyszedł ktoś, kto nie wiedział, że się nie da" i zrobił przezroczystość w podsypkach. Nadal nie potrafię zgadnąć, jaki był w tym cel. Jeśli chodziło o "integrowanie podsypki z terenem", to chyba to inaczej powinno wyglądać...

Latające samochody

Po uruchomieniu skrzyżowań w 2014 roku okazało się, że problemy robi mechanizm niezależnego prowadzenia osi. Druga oś samochodu nie zawsze podąża za pierwszą. O ile w przypadku taboru kolejowego ma to jakieś odniesienie do rzeczywistości i powinno to prowadzić do wykolejenia, to dla samochodów nie ma kompletnie sensu. Druga oś powinna podążać za pierwszą w stałej odległości.

Na paczce MaSzyna 23.07 nadal ma to miejsce.