Sceneria/Kaliska/Etap 1
Pierwotne analizy scenerii "Kaliska" wobec możliwości edytora RSF doprowadziły do wniosku, że jest ona nieprzydatna do rozwoju edytora RSF, ani też edytorem RSF nie da się nic w niej ulepszyć (niewymiarowe rozjazdy, rozstawy torów na stacjach niezgodne z rzeczywistością, nie zachowane kąty, niezgodności w odległościach). Jednak doświadczenia zebrane podczas urealniania Linii 61 (dopasowanie do mapy, korekta układów torowych, wprowadzenie profilu pionowego, wykorzystanie rzeczywistych rozkładów) dały nowe spojrzenie na możliwość wykorzystania pracy już włożonej w scenerię "Kaliska". Możliwe jest wykorzystanie algorytmów opracowanych na potrzeby ulepszenia Linii 61, jak również do zaakceptowania jest znacznie większy poziom niezgodności z rzeczywistością, niż się to wydawało wcześniej (np. na Linii 61 przejściowo były używane niewymiarowe szablony rozjazdów 34m). Na uwadze jest też odgrzebanie i uruchomienie trasy Łódź — Kutno — Włocławek — Toruń, w którą też dużo pracy zostało włożone.
Ponieważ prace nad scenerią nadal trwają (nie powstał jeszcze stan finalny), będzie je trudno pogodzić z procesem dostosowania do map. Dlatego dostosowanie do map musi być podzielone na etapy — każdy etap powinien zostawić stan lepszy. Może się również zdarzyć, że proces nie zostanie zakończony, a utknie na którymś etapie.
Spis treści
- 1 Cele etapu
- 2 Stan realizacji etapu
- 3 Zmiany w Rainsted
- 3.1 Zwiększenie dokładności "długości" odcinka
- 3.2 Zwiększenie dokładności współrzędnych odcinka
- 3.3 Wyłączone zerowanie wektorów kontrolnych
- 3.4 Zmiana kolejności parametrów toru
- 3.5 Zwiększenie dokładności zapisu kąta
- 3.6 Automatyczne naprawianie zwrotu wektora kontrolnego
- 3.7 Zwiększenie dokładności zapisu normalnych i mapowania trójkątów
- 3.8 Wyłączona normalizacja wektorów normalnych
- 3.9 Podział na dwa odcinków o błędnych kontrolnych
- 3.10 Zmieniony zapis node...model
- 4 Procedura przekształcenia — rozpoczęcie
- 5 Procedura przekształcenia — kontynuacja
- 6 Rezultaty prac
- 7 Następne etapy
- 8 Zamknięcie etapu
Cele etapu
Obrócenie scenerii o 180°
Obrócenie scenerii ma nie tylko dostosować ułożenie trasy do przyjętych kierunków świata, ale również przetestować mechanizmy przetwarzania plików przed wykonaniem bardziej zaawansowanych operacji (lepsze dopasowanie do map: obrót o inny kąt, przesunięcie o wektor, podział scenerii na obszary, dla których zastosowane będą odrębne zestawy przekształceń).
Lista problemów z obracaniem
Wiele funkcjonalności związanych z zapisem zmienionych elementów scenerii zostało naprawionych podczas prac nad Linią 61. Jednak niektóre błędy były na tyle trywialne, że zamiast dopracowania mechanizmów zostały użyte inne narzędzia, np. edytor tekstowy. Być może nie wszystkie algorytmy będzie sens udoskonalać, jednak ze względu na trwające prace rozwojowe może powstać potrzeba wielokrotnego wykonania obrotu, co będzie skutkować ciągłym powstawaniem tych samych błędów. Lista problemów pozwoli sprawdzić newralgiczne miejsca.
Lista potrzebnych zmian w Rainsted
Na podstawie listy wykrytych błędów będzie można opracować listę potrzebnych poprawek algorytmów. Realizacja poprawek może się rozciągnąć w czasie, niemniej poprawki powinny skracać listę znanych błędów podczas przekształcenia. W celu ograniczenia różnic pokazywanych przez SVN, wyłączone zostały pewne mechanizmy w Rainsted — będą one włączane ponownie w kolejnych etapach. Inne znane niedoskonałości, które skutkują różnicami w SVN, a nie są użyteczne:
- Zmiana ukośników w ścieżkach do plików.
- Usuwanie wpisu lights w node...model.
- Ujednolicanie wielkości liter w nazwach plików (wskazane jest wykonanie tego edytorem tekstowym).
- Usuwanie wewnętrznych komentarzy we wpisach (np. zakomentowane eventy).
- Zmiana kolejności parametrów opcjonalnych we wpisach odcinków trajektorii.
- Gubienie/psucie wpisów odcinków trajektorii z błędnymi wektorami kontrolnymi.
- Zaokąglanie wartości pikometrycznych (nadal używane są zaokrąglenia, jednak np. do 9 cyfr dziesiętnych).
- Konwersja liczb z formatu wykładniczego na ułamek dziesiętny (zwykle z e-005, e-006 i e-007).
- Wstawianie pustej linii na początku pliku.
Zautomatyzowanie procesu
Automat powinien mieć listę plików i zakres dokonywanych zmian, po czym jego uruchomienie powinno wyprodukować docelowe pliki. Ewentualne poprawki, konieczne do wykonania ręcznego, powinny być znane i realizowane w razie potrzeby.
Stan realizacji etapu
Usuwanie komentarzy i poprawki formatowania
Operacje wykonywane przez Rainsted usuwają komentarze znajdujące się wewnątrz wpisów, z drugiej strony sceneria posiada takie komentarze, ponieważ jest eksportowana z 3ds Max. Komentarze te są zbędne dla symulacji, jednak aby testować algorytmy przeliczające, lepiej będzie usunąć komentarze edytorem tekstowym. Podobnie edytorem tekstowym można usunąć zbędne spacje, a także zapis 0.0, skoro jedno zero ma dokładnie taką samą wartość użytkową. Poniżej szczegółowa lista operacji, gdyby trzeba było powtórzyć (kolejność niektórych jest istotna):
- Zamiana średników na spacje.
- Zamiana tabulatorów na spacje.
- Usunięcie komentarzy "//point 1", "//control vector 1", "//control vector 2", "//point 2".
- Usunięcie komentarzy "//Active", "//Passive", "//Plants", "//Signal", "//hekto".
- Zamiana podwójnych pustych linii na pojedyncze (w plikach tylko z INC całkowite usunięcie pustych linii).
- Zamiana "node 600 0 ", "node 700 0 ", "node 800 0 ", "node 1000 0 " na "node -1 0 ".
- Zamiana koloru " 149.94 149.94 149.94 " na " 150 150 150 ".
- Usunięcie specular z parametrami: "specular: 255.0 255.0 255.0", "specular: 229.5 229.5 229.5".
- Usunięcie "diffuse: 255.0 255.0 255.0", "ambient: 255.0 255.0 255.0".
- Usunięcie ciągów ".0" o ile kolejnym znakiem jest spacja albo koniec linii.
- Zamiana podwójnych spacji na spacje pojedyncze.
- Usunięcie białych znaków z początków i końców linii.
- Usunięcie pustych "material endmaterial" po usunięciu podwójnych spacji.
Ponadto po pierwszym teście wskazane są:
- Zamiana " 0.200001 " na " 0.2 ".
- Zamiana "rail_screw_used1" na "Rail_screw_used1" oraz "rail_screw_unused1" na "Rail_screw_uNused1" (z wielkiej było dużo więcej).
Wgranie plików na SVN
Na podstawie doświadczeń z wieloma sceneriami można uznać, że SVN się sprawdził w zakresie kontroli prawidłowości masowych zmian w plikach scenerii. Pozwala również przywrócić poprzednią wersję, jak i porównać z wcześniejszymi. Możliwe jest również sięgnięcie do wykonanych w przeszłości zmian w kontekście wykrytych dużo później błędów.
Dwukrotne obrócenie scenerii
Obrócenie scenerii o 180° w zasadzie sprowadza się do zmiany znaków przy współrzędnych X oraz Z. Jednak ma również różne inne konsekwencje, np. dotyczy także wektorów normalnych w trójkątach. Dwukrotne obrócenie o 180° powinno dać stan pierwotny, jednak pozwoli już zrobić pierwszą listę niedoskonałości algorytmów.
Po dwukrotnym obróceniu torów, już oczyszczonych edytorem tekstowym, widoczne są na pierwszy rzut oka następujące zmiany (w sumie ponad 25 tysięcy):
- Zaokrąglenie "długości" (parametr ignorowany w symulacji, planowane użycie jako rozpoznanie kilometrażu) do 3 cyfr dziesiętnych, oryginalnie są 4, więc zmiana powstaje w prawie każdym wpisie.
- Niekonsekwencja wielkości liter w nazwach tekstur — Rainsted ujednolica wg pierwszych znalezionych.
- Zerowanie wektorów kontrolnych dla odcinków prostych.
- Zaokrąglanie wektorów kontrolnych do 4 cyfr dziesiętnych.
- Zaokrąglenie współrzędnej pionowej np. z 0.200001 do 0.2.
- Zamiana położenia parametru velocity we wpisie toru — przenoszony przed eventy.
- Przeliczenie kąta w include np. pierwotnie było 63.1788, zrobiło się -296.8212.
Drugie podejście do torów, po wykonaniu korekt edytorem tekstowym i po poprawce w Rainsted, która nie zaokrągla "długości", pozostało ponad 16 tysięcy zmian. Jest to nadal zbyt wiele, żeby pobieżne przejrzenie pozwalało na wyłapanie ewentualnych błędów, planowane są więc kolejne tymczasowe modyfikacje do Rainsted (zmiany te będą najprawdopodobniej cofnięte po zakończeniu etapu 1).
Trzecie podejście do torów dało ponad 12 tysięcy różnic, czwarte ponad 7 tysięcy. Następnie edytorem tekstowym zostały ujednolicone nazwy tekstur szyn i podsypek (wielkie N w uNused, TpD- i TpB- zamiast tpd- i tpb-). Piąte to ponad 5 tysięcy i zamiana w 16 wpisach tpd1 na TpD1. Przy kolejnym podejściu pozostało nieco ponad 1200 różnic, które można przejrzeć ręcznie:
- Liczby typu -6.85453e-007 zamieniane są na zero.
- Są puste linie wewnątrz wpisów torów.
- Mimo przesunięcia parametru velocity w Rainsted okazuje się, że odwrotne ułożenie też się zdarza.
- Zaokrąglają się mikrometry w wektorach kontrolnych, np. 0.000976563 do 0.000977.
- Środowiska Canyon, Tunnel, Bridge, Bank, Mountains są zamieniane na małe (180 takich zmian).
W kolejnym kroku parametr środowiska jest zmieniany edytorem tekstowym i usuwane są puste linie przed endtrack. Po dalszym ograniczeniu zaokrągleń udało się uzyskać około 550 różnic. W zasadzie można uznać, że zapis toru przebiega poprawnie — nie zapisały się jedynie odcinki toru o błędnych współrzędnych kontrolnych (przynajmniej pierwsze z par), co wymaga sprawdzenia:
node -1 0 none track normal 18.6698 1.435 0.25 25 20 0 flat vis Rail_screw_used1 4 TpD-old1 0.2 0.5 1.1 3882.94 0.2 19706.4 0 0.220703 0 -5.48242 0.216553 0 -5.48242 3883.57 0.2 19689.9 0 0 velocity 100 endtrack
node -1 0 none track normal 60.0091 1.435 0.25 25 20 0 flat vis Rail_screw_used1 4 TpD-old4 0.2 0.5 1.1 88073.4 0.2 -15155.6 0 -0.976563 0 -17.6094 -0.960938 0 -17.6104 88070.5 0.2 -15208.4 0 0 event2 lk_A12_s1 velocity 60 endtrack
Zmian w drogach jest dużo mniej. Zrobiło się ujednolicenie wielkości liter w nazwach plików. Są też liczby w postaci wykładniczej oraz problematyczne odcinki — jest ich znacznie więcej i trzeba coś z tym zrobić, żeby się dały przeliczyć:
node -1 0 none track road undefined 3 0.85 -1 15 0 flat vis AsphaltGray1 undefined AsphaltGray1 0.2 0.2 0.5 2213.48 6.3 -5451.24 0 0 0 0 0 0 0 2220.86 6.3 -5444.49 0 0 endtrack node -1 0 none track road undefined 3 0.85 -1 15 0 flat vis AsphaltGray1 undefined AsphaltGray1 0.2 0.2 0.5 1694.92 9.5 -4843.91 0 0 0 0 0 0 0 1702.3 9.5 -4837.16 0 0 endtrack
node -1 0 none track road 100 5 0.85 -1 15 0 flat vis droga_polna 6 grass 0.2 0.2 0.5 21368.7 0.2 -8133.13 0 -0.183594 0 15.7295 -15.6172 0 1.88477 21372.9 0.2 -8086.12 0 0 endtrack node -1 0 none track road 100 3 0.85 -1 15 0 flat vis droga_polna 6 grass 0.2 0.2 0.2 21536.3 0.2 -8367.24 0 0 0 0 0 0 0 21636.3 0.2 -8367.24 0 0 endtrack
Zmiany w Rainsted
Większość zmian ma charakter tymczasowy i ma na celu odnalezienie błędów przy przetwarzaniu plików scenerii. W związku z tym wyłączane są np. mechanizmy zaokrąglania, aby SVN nie pokazywał różnic wynikających z zaokrągleń.
Zwiększenie dokładności "długości" odcinka
Parametr we wpisie toru, będący kiedyś długością, który stracił swoje znacznie na rzecz obliczania długości przy wczytywaniu, był zaokrąglany do 3 miejsc dziesiętnych. Liczba cyfr dziesiętnych została zwiększona. Docelowo parametr ten ma określać kilometraż danego odcinka, dzięki czemu AI łatwiej określi swoją pozycję — i dokładność do 1mm jest wystarczająca.
Zwiększenie dokładności współrzędnych odcinka
Zwiększona została liczba cyfr ułamka dziesiętnego dla współrzędnych. Dla równowagi zostało wprowadzone zaokrąglanie przy przesyłaniu z edytora RSF do SCM, aby nie były niepotrzebnie wstawiane dodatkowe cyfry.
Wyłączone zerowanie wektorów kontrolnych
Tymczasowo zablokowany jest mechanizm przerabiania odcinków prostych z niezerowymi wektorami kontrolnymi na wpis z wyzerowanymi wektorami kontrolnymi.
Zmiana kolejności parametrów toru
Roboczo parametr velocity został przesunięty za eventy. Jednak w scenerii występują odcinki toru, w których parametr velocity jest jako pierwszy. Po upewnieniu się, że wpisy torów zapisują się prawidłowo, kolejność zostanie przywrócona do poprzedniej, aby nie wprowadzać zmian w pozostałych sceneriach.
Zwiększenie dokładności zapisu kąta
Dla plików INC dokładność obrotu w osi pionowej została zwiększona do pięciu cyfr ułamka dziesiętnego (0.00001°). W praktyce wystarczają 4 cyfry, jednak zaokrąglenie do 4 cyfr pokazuje wiele niepotrzebnych różnic. Zaokrągleń do 5 jest już niewiele.
Automatyczne naprawianie zwrotu wektora kontrolnego
Zwrot pierwszego wektora kontrolnego powinien być taki sam, jak zwrot wektora łączącego punkty, a drugiego wektora — przeciwny. Badany jest iloczyn skalarny i w razie potrzeby są zmieniane znaki współrzędnych wektora na przeciwne. W pewnych przypadkach naprawia to skutecznie odcinki, w innych nie. Z praktyki można powiedzieć, że odcinki z wektorami kontrolnymi na zewnątrz mają praktycznie zerowe zastosowanie do symulacji — można sobie wyobrazić pętlę tramwajową ze zwrotnicy i jednego odcinka, ale raczej będzie to kuriozum. Zmiana raczej na stałe.
Zwiększenie dokładności zapisu normalnych i mapowania trójkątów
Na potrzeby obrócenia terenu tymczasowo zostanie zlikwidowane zaokrąglanie współrzędnych oraz wektorów normalnych dla trójkątów terenu. Jedynie współrzędne wektora normalnego o wartości bezwzględnej mniejszej od 0.1mm są zaokrąglane do zera.
Wyłączona normalizacja wektorów normalnych
Dotychczas każdy wektor normalny o długości większej niż 1.005 był przeliczany do długości 1.0. W związku z przypadkami współrzędnej pionowej równej ±1.57079 normalizacja została wyłączona, aby nie generować niepotrzebnych różnic w SVN.
Podział na dwa odcinków o błędnych kontrolnych
W drogach było około 20 odcinków, których wektory kontrolne uznane zostały za błędne. Po obejrzeniu scenerii okazało się, że są to w pewnym sensie skrzyżowania (docelowo będą wymagać poprawienia). W związku z tym zostało wprowadzone dzielenie takich odcinków na dwa, zamiast oznaczania ich jako błędne. Jednak jeden z odcinków był prostym, który miał za długie wektory kontrolne — jego podział zapętlał się, w związku z tym zostało wprowadzone ograniczenie długości wektorów kontrolnych do 67% odległości pomiędzy końcami — odcinek taki jest zamieniany na posty, a wektory kontrolne zostają wyzerowane.
Zmieniony zapis node...model
W związku z bardzo dużą liczbą zmienianych ukośników oraz różnorodnością wielkości liter, zmieniona została definicja obiektu node...model w Rainsted. Obecnie nazwa T3D modelu oraz tekstura są ciągami liter i nie podlegają dalszemu przetwarzaniu (ujednolicenie wielkości liter, zmiana ukośników). Tymczasowo mogą nie działać prawidłowo niektóre operacje na scenerii, np. eksport do RSF.
Procedura przekształcenia — rozpoczęcie
Rozpoczęcie ma miejsce, gdy nie mamy plików wgranych na SVN i zaczynamy od ostatniej przetestowanej wersji scenerii. Moment wgrania plików na SVN zależy od zaufania do używanego edytora tekstowego. Można wgrać od razu pierwotne pliki i następnie śledzić poprawność każdej operacji, można też wykonać operacje makrem i wgrać rezultat. Proponuję w tym zakresie wykorzystać podkatalog scenery/kaliska, ponieważ wprowadzone edytorem tekstowym zmiany nie mają (a przynajmniej nie powinny mieć) żadnego wpływu na działanie scenerii.
Po wykonaniu kompletu zmian z poziomu edytora tekstowego można dalej pracować w tym samym katalogu, albo przekopiować pliki do scenery/kaliska0 i tam dokonywać kolejnych zmian. Poniższy opis będzie dotyczył drugiego rozwiązania, ponieważ wtedy nieco łatwiejsze będzie postępowanie z aktualizacją scenerii.
Kolejnym krokiem jest wczytanie każdego SCM do Rainsted i obrót najpierw o 180°, a następnie o -180° (można też wykonać inne, sumujące się do zera operacje, jak przesunięcie o metr i następnie w przeciwną stronę). Celem jest zapisanie pliku z Rainsted tak, jakby uległ on modyfikacji (Rainsted zapisuje w pierwotnej postaci wszystkie wpisy, które nie zostały zmienione). Otrzymane różnice należy przejrzeć przy pomocy klienta SVN — powinny one ograniczyć się do zaokrągleń liczb i zmiany kolejności parametrów opcjonalnych we wpisach odcinków. Wszelkie inne sytuacje należy sobie wypisać, ewentualnie dokonać napraw (np. błędnych wektorów kontrolnych).
Kolejnym krokiem jest przeniesienie plików do podkatalogu scenery/kaliska1 i obrócenie o 180° w osi pionowej. Tym razem zmiany widoczne na SVN powinny ograniczać się do zmiany znaku liczb. Jeśli pojawiły się błędy we wcześniejszym kroku, trzeba je odnaleźć i zmodyfikować ręcznie.
Procedura przekształcenia — kontynuacja
Kontynuacja ma miejsce, gdy mamy już pliki wgrane na SVN, a pojawi się kolejna wersja scenerii. Ponieważ nie wiadomo, czy bieżące prace nad scenerią zostaną przeniesione na przekształcone pliki, a jeśli tak, to kiedy, do tego czasu trzeba wykonywać przekształcenia jako kontynuację. Można oczywiście opróżnić SVN i zacząć ponownie od rozpoczęcia.
Ponieważ na SVN mamy już wersję zmienioną, należy wykonać na plikach wszystkie operacje edytorem tekstowym. SVN pokaże zakres zmian, jakie zostały wykonane w scenerii — należy przejrzeć i zapamiętać bądź zapisać sobie, łącznie z liczbą różnic. Będzie to potem potrzebne do porównania ze zmianami po przekształceniu.
Następnie przenieść pliki do scenery/kaliska0 i wykonać na nich operacje w Rainsted, które nic nie zmienią, a wymuszą zapis, jakby były dokonane zmiany (np. obrót o 180° i następnie o -180°). Rezultat należy porównać z zakresem zmian wprowadzonych przez aktualizację.
Ostatnim krokiem jest przeniesienie plików do podkatalogu scenery/kaliska1 i obrócenie o 180° w osi pionowej. Również rezultat należy porównać z zakresem zmian wprowadzonych przez aktualizację.
Rezultaty prac
W pierwszej kolejności zostały przetworzone pliki datowane na okres od 2018-11 do 2019-02-04 (plik kaliska_events.ctr z 2019-03-09). Jeśli pojawią się nowsze pliki, a dalsze prace nad scenerią nie zostaną przeniesione na pliki po obrocie, to z czasem będą kolejne rezultaty etapu 1. Pliki są do pobrania pod adresem http://rainsted.com/warsztat/Kaliska.
- Archiwum kaliska0-190309.7z zawiera pliki scenerii potraktowane makrem w Notepad++ i następnie zapisane z Rainsted. W przypadku niektórych plików zostały przywrócone puste linie i elementy obcinane przez Rainsted. Pliki te są punktem wyjścia do wykonania obrotu i ich kopia w SVN ewentualnie posłuży do określenia skali zmian w nowszej wersji scenerii.
- Archiwum kaliska1-190309.7z zawiera pliki scenerii po obróceniu o 180° w osi pionowej. Rezultat prac nie był jeszcze testowany. Podgląd sieci trakcyjnej z tej paczki wykazał, że współrzędna Z wszystkich obiektów obiektów została błędnie zmieniona na ujemną.
- Archiwum kaliska1-200131.7z zawiera "plik z posekcjonowaną siecią trakcyjną", udostępniony przez autora w październiku 2020. Również zawartość obrócona i nie testowana. W ścieżkach do plików INC zostało zmienione tr\ na tr/, ponieważ dla tych pierwszych obracanie nie zadziałało prawidłowo. Wstępne porównanie wykazało, że zawartość pliku różni się znacząco od zawartości z poprzednich paczek. Należałoby wczytać obie wersje pliku (np. do symulacji przesunięte o 5m w pionie) i ocenić zakres i przydatność wprowadzonych zmian. W pliku były dwa uszkodzenia, wykryte przy porównaniu przez SVN: wpis bramki o współrzędnych "-1.#IND 1.#QNAN 1.#QNAN" oraz niepotrzebne znaki "2 =". Pierwszy został zakomentowany, a drugi został skorygowany bez weryfikacji sensowności i ewentualnego zdublowania z innym poprawnym.
Następne etapy
W następnej kolejności planowane jest lepsze dostosowanie scenerii do map. Doświadczenia z Linią 61 wykazały, że lepiej jest uzyskać kilka punktów względnie dobrej zgodności torów z mapą niż np. dopasować tylko jedną stację. Kilka punktów dopasowania zostawia dużo możliwości wyboru kierunku dalszych prac: można lepiej dopasować tory pomiędzy którymiś punktami, albo zająć się rozbudową na zewnątrz punktu dopasowania.
Plany również obejmują dostosowanie nazewnictwa urządzeń do współpracy ze skryptami sterującymi. Ulepszanie nazewnictwa może rozwijać się w miarę niezależnie od układu geometrycznego.
Najprawdopodobniej kolejny etap będzie obejmował zerowanie wektorów kontrolnych w odcinkach prostych (co uprości kwestię porównania zmian po obrocie) oraz normalizację. Być może w tym samym etapie, a być może już w następnym, sceneria zostanie przesunięta o wektor. Póki co brane jest pod uwagę obrócenie całej scenerii w celu zgrubnego dopasowania odcinka Łódź – Zduńska Wola oraz alternatywnie, obrócenie tylko fragmentu w tym samym celu.
Zamknięcie etapu
Ponieważ dalsze niezależne prace nad scenerią (w październiku 2020) uwzględniły zmiany wprowadzone w tym etapie, etap zostaje uznany za zamknięty (nie będą do niego dodawane nowe operacje, jak zaokrąglenia współrzędnych, zerowanie wektorów kontrolnych odcinków prostych, ustalanie znaku promienia, czy normalizacja wektorów normalnych w trójkątach terenu). Kolejne etapy będą bazować na aktualnym opublikowanym stanie prac, a nie na plikach z 2018 i 2019.
Efektem realizacji Etapu 1 jest lepsze dopasowanie scenerii do kierunków świata oraz naprawienie błędów w obsłudze obiektów przez Rainsted.
