Edytor/Komórki
Koncepcja komórek scenerii nadal jest rozwijana i nie została jeszcze ukształtowana finalnie.
Edytor RSF obsługuje obszar edycyjny o boku 524km (±262km od środka). Jest to kompromis pomiędzy liczbą bajtów przeznaczonych na współrzędne punktu (12) a rozdzielczością (1/8192m, przy czym pierwotnie miały być zaokrąglane do całkowitych mm). Aby można było objąć edytorem cały obszar Polski (ale także osiągnąć inne cele, jak np. poprawa wydajności wyświetlania), dodana została do pliku RSF definicja środka scenerii oraz obszaru referencyjnego. Obszar referencyjny domyślnie ma 1000km×1000km, a środek scenerii może być w nim umieszczony na współrzędnych będących wielokrotnością 1km (przy czym pliki tworzone edytorem dostają środki o współrzędnych będących wielokrotnością 8km).
Spis treści
- 1 Zastosowania komórek scenerii
- 1.1 Zmniejszenie ilości danych potrzebnych do symulacji
- 1.2 Łączenie scenerii fikcyjnych w sieć kolejową
- 1.3 Integracja klonów
- 1.4 Zasięgi nazewnictwa
- 1.5 Łączenie plików RSF
- 1.6 Niezależne dopracowanie fragmentów
- 1.7 Poprawa wydajności wyświetlania
- 1.8 Dynamiczne wczytywanie komórek
- 1.9 Wersje historyczne
- 2 Nazewnictwo obiektów
- 3 Identyfikatory
Zastosowania komórek scenerii
Pierwsza komórka została wydzielona w 2012 roku ze scenerii Quark — Mydelniczka.
Zmniejszenie ilości danych potrzebnych do symulacji
Jedną z koncepcji zastosowania komórek było ograniczenie wielkości plików wczytywanych do symulacji. Około 2010 roku wczytywanie scenerii do MaSzyny trwało bardzo długo, a do tego symulacja obejmująca duży obszar była mało wydajna. W przypadku wielu misji (tras pociągów) nie była wykorzystywana cała sceneria, a jedynie jej część. Stąd pojawiła się koncepcja podziału scenerii na mniejsze fragmenty, będące komórkami. Dla wybranego pociągu miały być wczytywane tylko te komórki, przez które przebiegała trasa jego przejazdu. Koncepcja ta jest zrealizowana częściowo na Linii 61, gdzie zależnie od wybranej misji łączone są różne fragmenty — jednak one tylko częściowo pokrywają się z komórkami (zawierają więcej niż jedną).
Łączenie scenerii fikcyjnych w sieć kolejową
Koncepcja z 2008 roku zakładała dopasowanie do siebie scenerii fikcyjnych w taki sposób, aby można było tworzyć trasy pociągów nieprzewidziane wcześniej przez autorów scenerii, ale za to pozbyć się zbędnych fragmentów (nie wczytywać ich, jeśli nie leżą na trasie pociągu). Zostało opracowanych kilka propozycji złożenia dostępnych scenerii, ale nie spotkały się one z większym zainteresowaniem.
Scenerie miały być podzielone na granicy siatki kilometrowej. Ze względu na możliwe problemy z przeliczaniem współrzędnych, przesunięcia fragmentów miały być wykonywane tylko o całkowitą liczbę kilometrów.
Integracja klonów
Wiele scenerii istnieje jako klony, czyli ma osobne (powtórzone) zestawy obiektów dla poszczególnych scenariuszy. Dla Linii 61 istniało 18 klonów i każdy miał własne tory, w tym własny Lubliniec. Wydzielanie komórek może być dobrą metodą na integrację klonów — można obiekty podzielić geograficznie dla każdego klonu, a następnie łatwiej może być integrować mniejsze pliki. Tak zostały zintegrowane klony Linii 61 — Lubliniec wspólny już dla kilku scenariuszy wschodniej części został następnie podczepiony pod scenariusze zachodniej części — po usunięciu obiektów na wschód od linii łączenia do scenariusza dodawana była cała komórka Lublińca.
Zasięgi nazewnictwa
Jednym z problemów przy łączeniu scenerii fikcyjnych były powtórzone nazwy torów w różnych plikach. Aby uniknąć niejednoznaczności, można było dodać do nazw kody komórek. Komórki muszą być obszarem spójnym (każda komórka ma swój obwód i jest on jedną linią zamkniętą), dzięki czemu różni autorzy mogli stosować te same dalsze części nazwy torów, o ile przedrostek pochodził z komórki.
Częściowo kody komórek zostały wykorzystane jako zasięgi nazewnictwa dla infrastruktury w okolicy Wrocławia (bardzo małe komórki). Jednak nie jest to zalecane zastosowanie, od 2020 roku dostępne jest alternatywne rozwiązanie "zasięgów nazewnictwa", niezależne od komórek.
Łączenie plików RSF
Siatka kilometrowa miała również służyć do ograniczenia zasięgu scenerii tworzonych w RSF. W 2011 roku powstała trasa Wrocław — Legnica, która była w 3 niezależnych plikach RSF i ich łączenia były przewidziane na granicy komórek.
Niezależne dopracowanie fragmentów
Pliki scenerii mają po kilka MB i liczbę linii rzędu 100 tysięcy. Do tego podzielone są na warstwy: osobno tory, osobno sieć trakcyjna, osobno sygnalizacja. W efekcie drobna zmiana (np. korekcja łuku) przekłada się na zmiany w wielu dużych plikach (co dodatkowo komplikuje się, jeśli istnieją klony). Jeśli zmiany są wprowadzane przez wielu autorów (zwłaszcza na nieaktualnych plikach), to ciężko te zmiany zintegrować. Podział na komórki miał dać mniejsze pliki (kilkaset kB, kilkadzieści tysięcy linii), przy czym infrastruktura (istotna dla symulacji) miała być tylko w jednym.
Poprawa wydajności wyświetlania
Jednym z problemów na dużych sceneriach było drganie obiektów oddalonych od środka. Propozycją rozwiązania było geograficzne grupowanie obiektów w komórki, a następnie przełączanie całych grup obiektów podczas przekraczania granicy pomiędzy nimi. Z kolei przeliczanie obiektów do nowego środka zajmuje zauważalny czas i prawdopodobnie jest przyczyną przycinania symulacji (zauważalne na MaSzyna 21.04).
Dynamiczne wczytywanie komórek
Planowane było wczytywanie komórek podczas jazdy. W ten sposób można by pokonać trasę o dowolnej długości. W praktyce zrealizowane w Train Driver 2.
Wersje historyczne
W związku z przebudowami stacji na przestrzeni lat, pliki danej komórki mogą mieć przypisany okres zgodności z rzeczywistością. Poszczególne komórki mogą mieć te okresy umiejscowione w innym zakresie lat. Jeżeli komórki będą miały różne warianty dla różnych okresów, można dobrać te najbardziej pasujące dla wybranego roku. Warunkiem koniecznym jest tylko zachowanie zgodności torów na łączeniach komórek.
Nazewnictwo obiektów
Jednym z bardziej istotnych celów istnienia komórek jest unikalność nazewnictwa odcinków i sygnałów. Unikalność nazw powinna jednoznacznie określać, którego obiektu dotyczy operacja albo błąd. W trakcie rozwoju edytora Rainsted przyjęte zostały następujące założenia.
Nazwy z wielkiej litery
Nazwy z wielkiej litery uznawane są za posiadające wyższą dbałość ze strony autorów. Powinny mieć człon określający jednoznacznie np. stację albo linię kolejową. Nazwy z wielkiej litery mogą również zawierać przedrostki (do pierwszego znaku podkreślenia), definiowane obiektami zasięgu nazewnictwa. Obiekty zasięgu nazewnictwa określają jednoznacznie zasięg geograficzny, na którym dopuszczalne są określone przedrostki z wielkiej litery. Użycie przedrostka poza obszarem wyznaczonym przez zasięg nazewnictwa jest uznawane za błąd przez wyszukiwarkę błędów. Jako błąd do ręcznego poprawienia raportowane są również powtórzone nazwy. Przedrostki zasięgu nazewnictwa raczej powiązane są z nazwami stacji i nie muszą zgadzać się z kodem komórki (co jest możliwe, gdy komórka zawiera tylko jedną stację).
Nazwy z małej litery
Ogólnie nazwy te zapisane są w całości małymi literami. Nazwy te powinny posiadać przedrostek (2 albo 3 znaki) wyznaczony nazwą komórki. Po przedrostku powinien być znak podkreślenia. Jeśli w pliku RSF zostaną znalezione dwie identyczne nazwy obiektów, jedna z nich zostanie zmieniana na unikalną, z użyciem przedrostka komórki. Co do zasady edytor nie aktualizuje przedrostków w przypadku zmiany zasięgu komórek, trzeba taką aktualizację uruchamiać ręcznie. Jeśli obiekt jest istotny pod względem sterowania albo tor służy do wstawiania taboru, należy nazwę zapisać z wielkiej litery, a zalecane jest użycie przedrostka określonego zasięgiem nazewnictwa. Nazwy z małej litery uznawane są za nazwy robocze, tożsame z none w MaSzynie — ich unikalność była potrzebna do raportowania zajętości w przypadku sterowania ruchem z Rainsted, a także do sprawniejszego znajdywania i poprawiania błędnych odcinków.
Nazwy od znaków specjalnych
Nazwy zaczynane od znaku # (krzyżyk) są uznawane za opisowe i nie mające wymogu unikalności. Nazwa taka nie pozwala się odwołać jednoznacznie do konkretnego obiektu. Rozważana była opcja użycia nieunikalnych nazw do zarządzania wieloma obiektami (np. grupowe zapalenie latarń, jednak zapalanie latarń zostało rozwiązane w prostszy sposób). W przypadku słupów znak ten załącza dwustronną tabliczkę hektometrową.
Nazwy zaczynane od znaku * (gwiazdka) traktowane są jako wyróżniające obiekt na brzegu komórki do specjalnej obsługi. Unikalność nazwy (z użyciem wielkiej litery po gwiazdce) jest wskazana, ale nie jest konieczna. Planowana była opcja wstawianie taboru na takich odcinkach z opóźnieniem wynikającym z rozkładu, w takim przypadku unikalność nazwy by była potrzebna.
Identyfikatory
Identyfikatory komórek scenerii są obecnie trzyliterowe. Identyfikator jest przeliczany w taki sposób: A=0, B=1, C=2... Z=25. Pierwsza litera mnożona przez 676, druga przez 26 i dodawane są do wartości trzeciej.
01234 56789 00 ABCDE FGHIJ 10 KLMNO PQRST 20 UVWXY Z
Mamy dzięki temu 26*26*26=17576 możliwości (od AAA do ZZZ). Ponieważ identyfikator jest zapisany na 14 bitach, to 1192 ostatnie (=17576-16384) nie wyświetlą się prawidłowo (od YGD do ZZZ). Ponieważ w Polsce nie ma nazw zaczynających się na X i Y, litera X umieszczona jako pierwsza wyświetlana jest jako Z. Identyfikator AAA jest zarezerwowany dla kwadratu nieprzypisanego do komórki.
Polska
Obszarem referencyjnym dla Polski jest Państwowy Układ Współrzędnych Geodezyjnych 1992 (w skrócie PUWG1992). Pozwala to połączyć scenerie np. z mapami i danymi dostarczanymi przez Geoportal.gov.pl, a także inną dokumentacją dostępną w tym układzie. Na obecną chwilę użyte są następujące identyfikatory komórek dla obszaru Polski:
- AAA - kwadrat nieprzypisany
- BBA - Bielsko-Biała
- BKW - Bukowno
- BUN - linia kolejowa Bydgoszcz - Unisław
- BYD - Bydgoszcz
- CHA - Chełmża
- CHR - Chrzanów
- CZD - Czechowice-Dziedzice
- HRB - Herby
- INO - Inowrocław
- JWR - Jawor
- KBK - Kluczbork
- KNC - Koniecpol
- KLT - Kalety
- KPN - Kępno
- LBC - Lubliniec
- LBN - Lubin
- LEG - Legnica
- LSZ - Leszno
- MSZ - Myszków
- NMS - Namysłów
- NWW - Nowa Wieś Wlk.
- OLE - Oleśnica
- OSW - Oświęcim
- POL - Polkowice
- PRJ - Poraj
- PSZ - Pszczyna
- RAC - Racibórz
- RUD - Rudna
- RYB - Rybnik
- SCI - Ścinawa
- SLQ - Solec Kuj.
- SYC - Syców
- TCH - Tychy
- TOR - Toruń
- UNI - Unisław
- WBM - Wolbrom
- WLN - Wieluń
- WLS - Włoszczowa
- WOL - Wolsztyn
- WRO - Wrocław
- ZAW - Zawiercie
- ZYW - Żywiec
EU07 - scenerie fikcyjne
Dla scenerii fikcyjnych został opracowany oddzielny zestaw komórek, aby możliwe było utworzenie sieci kolejowej, zanim powstające scenerie realistyczne będą w pełni nadawały się do użytku.
- DOL - sceneria Dolmiowo
- DZI - Dzierżawa na Linii 546
- KRO - Krosowo na Linii 546
- NSW - Nowy Świat na Linii 546
- SCK - szlak Czerwice - Karpice scenerii SDR
- RAB - Rabinów na Linii 546
- SIA - Sianowice na Linii 546
- TES - sceneria Testowo
- TRA - południowa część scenerii Zwrotnicowo
- TRZ - Trzemszyce na scenerii SDR
Klasy ogólne | Bin • BinManager • BinRecord • BinItem • BinLine • BinPos |
---|---|
Klasy parametrów | BinFile • BinArcInfo |
Klasy obiektów | BinTrack • BinPath • BinSection • BinTraction |
Linie | Linia kierunkowa • Niweleta • Poprzeczka • Trajektoria • Ściana |
Punktowe | Bramka • Budowla • Drzewo • Obrotnica • Most • Przejazd • Studnia • Ukres |
Trójkąty | Trójkąty • Teren NMT-100 • CityGML |
Eksport | MaSzyna • Kody eksportu |
Operacje | Układanie niwelety |
Inne | RSF wersja 15 • RSF wersja 16 • Warstwy • Grupa • Komórki • Scenerie • RSFSTRU |