Edytor/RSF wersja 16

Wprowadzenie niektórych funkcjonalności wymaga istotnych zmian w strukturze pliku RSF (w zakresie użycia pól oraz wartości domyślnych), które wpływają na wsteczną zgodność pliku RSF. Rozpoznanie plików stworzonych wcześniejszymi wersjami edytora wykonywane jest przez odczytanie numeru wersji pliku i w razie potrzeby wykonanie odpowiednich korekt oraz ustawienie wartości domyślnych.

Zmiany w pierwszych kilkunastu wersjach były raczej drobne. Wersja 16 pliku RSF jest najdłużej obsługiwaną wersją.

Informacje o zmianach w strukturze plików są kluczowe w przypadku użycia pliku RSF jako bezpośredniego źródła danych dla scenerii. W 2015 roku były plany na wczytywanie scenerii z RSF do MaSzyny. Miało to na celu dynamiczne zarządzanie fragmentami scenerii w pamięci i np. uwolnienie symulacji od obsługi pociągów znajdujących się w miejscach odległych od użytkownika. Pamiętanie pozycji pojazdów oraz stanu sygnalizacji miało być obsługiwane przez osobne programy, zwane serwerami ruchu (uruchamiane lokalnie przez użytkownika bądź dostępne przez internet, jako rozgrywka wieloosobowa), również działające w oparciu o pliki RSF. Serwery ruchu z kolei miały mieć ograniczoną do minimum obsługę grafiki, za to pozwalać na zapisanie i odtworzenie stanu symulacji, a także późniejszą analizę zdarzeń. W 2022 roku projekt uruchomienia serwerów ruchu nadal pozostaje bezterminowo zawieszony.

Wcześniejsze zmiany

Opis wcześniejszych zmian jest na stronie RSF_wersja_15.

Zmiany względem wersji 15

Konwersja zawartości pliku RSF z wersji 15 na wersję 16 jest wykonywana jednokrotnie, przy wczytywaniu. Następnie zmieniany jest numer wersji i zapisanie pliku nastąpi już z numerem 16. W razie potrzeby wykonywane są kolejno konwersje ze wcześniejszych wersji do wersji 15 i następnie 16.

Wskaźniki na wtórne kierunkowe z numerem końca

Do wersji 15 odwołanie do linii kierunkowej miało tylko adres rekordu obiektu, który linię definiował (jako BaseItem). Po wprowadzeniu rozjazdów symetrycznych każdy jego tor może definiować osobny kierunek i pojawiła się konieczność ich rozróżnienia. Dlatego od wersji 16 wskaźnik zawiera numer końca toru rozjazdu, określającego wtórną kierunkową. Dla zwykłych rozjazdów będzie to zawsze 3, na symetrycznych albo 1 albo 3 (rozjazdy symetryczne nie są obsługiwane w wersji 15).

Zmiana kodu dla drzew

Do wersji 15 włącznie drzewa miały kod 0xA2. Od wersji 16 mają kod 0xA6. Wiąże się to z uporządkowaniem kodów obiektów okrągłych, które teraz będą mieć zakres od 0xA4 do 0xA7.

Rozstaw torów dla ukresów

Do wersji 15 ukresy miały wpisaną w P7 odległość osi toru (np. 1.75m). Od wersji 16 liczba ta jest rozstawem torów w miejscu ukresu. Konwerter wersji mnoży P7 przez 2, jeśli dotychczasowa wartość była większa lub równa od 1.75m. Być może część ukresów nie miała w ogóle wpisanej wartości i przy okazji zostało to uzupełnione na domyślną wartość 3.5m.

Szerokość góry podsypki w definicji

Podawanie szerokości podsypki na zewnątrz od rozstawu torów rodzi dwa problemy: konieczne jest pomnożenie przez dwa i dodanie rozstawu (np. 0.9 daje wartość 0.9+1.435+0.9=3.235) oraz ze względu na rozstaw wynik ma cyfry obejmujące tysięczne części metra (np. 3.235). Aby lepiej uzmysłowić sobie szerokość górnej powierzchni podsypki albo ustawić ją np. na równe 3m, jest ona teraz podawana wprost, a przeliczana na potrzeby eksportu do MaSzyny (np. (3-1.435)/2 da 0.7825 we wpisie toru — takiej wartości nie dałoby się wpisać ze względu na przyjętą dokładność do całkowitej wielokrotności 1mm).

Zmiany względem wersji 16

Każdorazowo po wczytaniu wykonywane są sprawdzenia danych i korekty dla wersji 16. Część korektorów jest wynikiem błędnego działania edytora — algorytmy zostały dopracowane później, jednak ich wcześniejsze wersje mogły produkować błędy, możliwe do masowego poprawienia. Przejście na wersję 17 sprawi, że większość z nich zostanie już pominięta — wczytywanie będzie nieco szybsze. W razie potrzeby (wykrycia błędów powstających podczas edycji) korektory mogą być uruchamiane również na wersji 17 i dopiero usunięte w kolejnej.

Użycie pola Len jako liczby rekordów agregatu

Do wersji 15 agregatami były tylko rozjazdy, rozpoznawane przez flagi +0x10 oraz +0x18 w polu Type. Ze względu na wprowadzenie szablonów rozjazdów oraz następnie słupów podwójnych, rolę licznika rekordów w agregacie przejęło pole Len (kiedyś miało być używane do zapisania długości danych obiektu w bajtach, za którymi można by umieścić nazwę albo komentarz — jednak nazwy zostały opracowane inaczej, a wpisywanie komentarzy do obiektów nie przyjęło się). Pole Len było już ustawiane od wersji 11, ale nie zawsze poprawnie. Dla rekordów zawierających tylko jeden obiekt, do pola Len wpisywane jest 1 (dotyczy rekordów nieusuniętych, czyli w których pole Type jest różne od zera). Większość mechanizmów edytora jest już przerobionych na to, by korzystać z pola Len. Ze względu na krytyczne znaczenie tego pola, wersja 16 była wyjątkowo długo testowana.

Zmiana kodu dla ścian lasów

Do wersji 15 ściany lasów miały kod 0x75, od wersji 16 jest to kod 0x79. Kod 0x75 pozostaje wykluczony, tzn. jest zmieniany na 0x79 przy wczytywaniu. Dopiero od wersji 17 będzie można wykorzystać kod 0x75 do innych celów (szablony skrzyżowań dróg). Odpowiednio zmieniane są kody plików, np. z 0x2075 na 0x2079.

Wyliczanie promienia zasięgu trójkąta

Dla trójkątów, do pola Id jest wpisywana największa odległość pomiędzy środkiem P[0] a wierzchołkami. Odległość ta nie jest przeliczana na jednostki metryczne (jak zwykle Id), tylko wyraża się w 1/8192m.

Naprawianie liczby rekordów w rozjazdach

Dla rozjazdu (który jest agregatem) pierwszy rekord powinien mieć Len=2, a drugi Len=0. Ustawiane to powinno być podczas edycji rozjazdu, jednak we wcześniejszych wersjach edytora było z tym różnie. Rozjazdy potrafiły się rozpadać na dwa osobne obiekty, które potem żyły własnym życiem, powodując problemy w eksporcie do MaSzyny oraz tworząc odcinki niemożliwe do usunięcia. Przy okazji sprawdzany jest wskaźnik tekstury szyny drugiego toru rozjazdu i jeśli jest błędny, zastępowany jest wskaźnikiem z pierwszego toru.

• Od wersji 25.8.172.19051 usuwany jest drugi tor rozjazdu (przez zerowanie typu), jeśli obiekt w poprzednim rekordzie nie będzie torem (warstwa 0x40 do 0x4F).

Naprawianie zepsutych słupów podwójnych

Wczesne wersje edytora potrafiły rozbić słup podwójny na dwa, które następnie powodowały problemy (np. nie dało się usunąć słupa). Sprawdzana jest zgodność typu i porównywane są współrzędne — jeśli się zgadzają, pierwszy rekord dostaje Len=2, a drugi Len=0. W razie wykrycia słupa, który był drugim rekordem słupa podwójnego, a stracił swój pierwszy rekord — jest on usuwany.

Poprawki mapowania na teksturach dla niwelety

Wcześniejsze wersje edytora generowały domyślne mapowanie i nie trzeba było podawać, co ile ma się powtarzać tekstura trawy. Obecnie podanie tych wartości jest konieczne, a w razie by nie były wpisane (zerowe), korektor wstawi wartość domyślną 5m (wcześniej 25m, od paczki MaSzyna 21.04 zmieniono zalecane powtarzanie mapowania trawy).

Uzupełnianie promienia łuku pionowego w poprzeczkach

Ponieważ zostało wprowadzone generowanie łuków pionowych na załomach profilu, konieczne jest wpisanie promienia w poprzeczkę. Wcześniej wartości te nie były uzupełniane — korektor ustawia domyślnie 10km.

Na planach kolejowych pojawiają się łuki pionowe oznaczone jako R=0. Oznacza to tyle, że nikt się nie będzie przejmował takim łukiem pionowym na gruncie, a ułożenie szyn w takim miejscu będzie konsekwencją ich sprężystości oraz pochylenia na sąsiednich odcinkach. Jednak na potrzeby symulacji trzeba albo zrobić łuk pionowy o bardzo dużym promieniu (300km), albo pogodzić się z załomem zbudowanym z odcinków prostych, albo nadać wygięcie odcinkowi ponad łukiem pionowym (flaga 0x0020 typu obiektu). Szczegółowe wytyczne mogą być ustalone w przyszłości. Również w przyszłości może być akceptowalne ustawienie R=0 i nie będzie poprawiane automatem na 10km.

Korekta flagi kierunku łuku

W zależności, czy łuk z punktu 1 w stronę punktu 2 skręca w lewo, czy w prawo, ustawiana jest parzystość w polu Type. Parzyste w lewo. Dotyczy również krzywych przejściowych. Flaga ta jest następnie używana przy wyliczeniach, zamiast każdorazowego wyznaczania zwrotu, co przyspiesza obliczenia, ale może czasem prowadzić do błędów w obliczaniu geometrii (gdy ustawienie flagi zwrotu nie będzie poprawne).

Inne wskazanie wbudowanych szablonów rozjazdów

Do wersji 15 szablony wbudowane były oznaczane poprzez dodanie do długości szablonu w [mm] liczby 0xFF000000. Wraz z wersją 16 zostało to zmienione na ujemną długość w [mm].

Ze względu na propozycję budowy szablonów w oparciu o promień łuku i skos, a nie rysunki techniczne, rozważana jest również ewentualna zmiana kodowania szablonów na większą rozdzielczość (np. jednostki edytora, równe 1/8192m). Zmiana ta nie będzie miała wpływu na użytkowanie edytora (przynajmniej nie powinna mieć). Przykładowo, szablon oznaczony obecnie jako 33230 [mm] wg rysunków technicznych, wyliczony z promienia i skosu będzie miał 33231.08288245mm długości (co w jednostkach edytora daje odpowiednio 272220 oraz 272229). W tym przypadku różnica wynosi nieco ponad 1mm, więc dałoby się je rozróżnić bez zmiany jednostki, jednak w innych przypadkach zaokrąglenie może być mniejsze.

Odbijanie szablonów rozjazdów symetrycznych

Opublikowane ongiś szablony rozjazdów symetrycznych (w plikach ADD) miały pierwszy tor w lewo, a drugi w prawo, co jest niezgodne z obecną konwencją (drugi zawsze w lewo). Aby skorygować pliki RSF z dołączonymi takimi szablonami, uruchomiony został korektor szablonów — zamieniający tory w szablonie. Nie jest on bardzo dopracowany, ponieważ w dalszej kolejności potrzebne jest ręczne naprawienie rozjazdów symetrycznych, które używały tych szablonów. Ze względu na małą skalę użycia rozjazdów symetrycznych korektor raczej nie będzie udoskonalany. Ponadto stare szablony rozjazdów symetrycznych nie miały wpisanego promienia łuku, co powodowało błędy w tworzeniu rozjazdów. Obecnie dostępne pliki ADD mają układ torów zgodny z konwencją.

Zerowanie długości stycznej w poprzeczkach Z

W związku ze zmianą koncepcji dla poprzeczek z zablokowaną wysokością (Z), wprowadzone jest zapamiętywanie wyliczonej długości stycznej w rekordzie poprzeczki (o ile zawiera ona nazwę, a nie profil poprzeczny). Przy wczytywaniu wersji 16 RSF pole zawierające długość stycznej jest zerowane, aby mogło zostać wyliczone podczas wyświetlania. Wartość ta jest używana do wyświetlenia okręgu pokazującego zasięg łuku pionowego, wynikającego z wysokości poprzeczki oraz dwóch sąsiednich, mających również ustawioną wysokość. Docelowo długość stycznej będzie również używana do wyznaczenia wysokości obiektów na łukach pionowych. W wersji 17 prawdopodobnie długości stycznych będą od razu wyliczone i nie będzie potrzeby ich zerowania i ponownego wyliczania.

Usuwanie średników z wzorców dla słupków

Pierwotnie dla słupków były dodawane wzorce z parametrami rozdzielonymi przy użyciu średników. Ponieważ zostało zmienione znaczenie średnika w pliku RSF, a wpisy ze średnikami nie wnoszą istotnej jakości, średniki we wpisach dla słupków są zamieniane na spacje.

Planowane zmiany względem wersji 16

W miarę rozwoju edytora weryfikowane są wcześniejsze koncepcje rozwiązań oraz porządkowane rozwiązania zrobione prowizorycznie. Istnieje np. potrzeba rozwoju agregatów (obiekt zajmujący więcej niż jeden rekord) oraz opisu infrastruktury w sposób niezależny od realizacji w symulacji (np. konkretne pliki INC w MaSzynie). Niemniej wprowadzenie zmian w strukturze RSF niesie ze sobą ryzyko zepsucia działania edytora, przekładające się na możliwość uszkodzenia wykonanej dotychczas pracy i pracochłonność naprawienia tych uszkodzeń. Poniżej planowane zmiany, które dojrzewają już jakiś czas.

Ujemne Len w kolejnych rekordach

Ponieważ zerowy Len w kolejnych rekordach robi nieco problemów, rozważane jest użycie wartości ujemnych. Pierwszy rekord miałby dodatnią liczbę rekordów, a kolejne zawierały by ujemny numer rekordu, np. 3, -1, -2. Rozmiar agregatu byłby ograniczony do 127 rekordów (obecnie agregaty wykorzystują 2 rekordy). Pozwalałoby to łatwo stwierdzić, czy dany rekord jest elementem składowym agregatu. Obecnie rekord z zerowym Len może być również skasowanym. Problem objawia się przy przeglądaniu listy zawierającej słupy podwójne, kiedy drut przeprowadzony jest po drugich rekordach. Na razie wykorzystanie drugiego rekordu jest ograniczone do kotwienia, ale ma być rozszerzone na słupy parasolowe itd.

Przebudowa parametrów toru

Obecnie tor posiada dwa wskaźniki na pliki tekstury szyny i podsypki. Opisy plików zawierają dodatkowe parametry. Jest to mało wygodne, ponieważ nie widać tych parametrów. Problematyczna jest też masowa zmiana tekstur. W planach jest przebudowa parametrów toru w taki sposób, aby szyny i podsypkę definiować w formie jednego obiektu, którego wszystkie parametry będą widoczne we Własnościach toru, a ponadto opis parametrów toru byłby tworzony hierarchicznie, poprzez dziedziczenie parametrów z bardziej ogólnego typu. Ewentualnie będzie zestaw flag (np. listy wyboru dla zużycia toru, wieku podsypki, typu podkładów), a do zestawu flag będzie przypisywany opis zawierający pliki i parametry.

Przebudowa parametrów słupów

Podobnie jak dla toru, planowana jest przebudowa słupów: zamiast wyboru INC słupa będzie opis parametryczny (typ słupa, wiek, kolor, dodatkowe elementy), a następnie dla zestawu parametrów będzie się definiować produkcję słupa.

Zmiana kodu szablonów rozjazdów

Obecnie szablony rozjazdów mają kod 0x77. Planowane jest przeniesienie do kodu 0x74, który obecnie zawiera parametry łuku. Kody 0x75 i 0x76 będą zawierały definicje dla skrzyżowań dróg i rzek (tzn. dodatkowe parametry, jak promienie łuków pomiędzy drogami).

Porządkowanie koncepcji kodów komórek

Kody komórek są zapisywane na 14 bitach, stąd zwykle są 2 bity wolne. W niektórych miejscach używane są bity 0..13, a w innych 2..15. Ponieważ wprowadza to zamieszanie, wszystkie struktury zmieniane będą na użycie wyłącznie bitów 0..13, aby uzyskiwać właściwy kod komórki przy użyciu maski 0x3FFF, a nie poprzez przesuwanie o 2 bity. Również przeliczone zostaną pliki z ustawieniem komórek, np. PUWG1992.DEF.

Planowane zmiany względem wersji 17

Zamiana Id z Path

Obecnie pole Id jest pomiędzy Path oraz polami Prev i Next. W związku z planami co do obsługi trójkątów, lepiej by było, aby trzy kolejne wskaźniki na sąsiednie obiekty były obok siebie. W związku z tym planowana jest zamiana miejscami pól Id oraz Path. Czyli najpierw będzie bajt liczby rekordów (Len), bajt z bitami (Flags), następnie dwa bajty z typem (Type) i następnie czterobajtowe: Id, Path, Prev i Next. Planowane jest uzyskanie zgodności w przód w taki sposób, że po wykryciu wersji 18+ obecne wersje Rainsted będą zamieniały pola w celu przywrócenia układu dla wersji 16/17.

Zmiany rozważane

Zamiana punktów mocowania drutu

Obecnie przęsła drutu są rozpięte pomiędzy P[2] a P[3], a P[0] jest rzutem P[1] na trajektorię (w tym zawiera wysokość z trajektorii). W ramach ujednolicenia koncepcji wskazane by było przeniesienie początku przęsła do P[0], a rzutu na trajektorię do P[2] — podobnie funkcjonują profile poprzeczne na niwelecie. Zmiana nie będzie miała wpływu na eksport do symulacji, jednak zmieni się znaczenie współrzędnych w poszczególnych polach.

---