Wersja/21.9.154

Wersja 21.9.154.16575 została opublikowana w dniu 2021-09.27. Większość zmian dotyczy edycji scenerii i uwspólnienia koncepcji pomiędzy edytorami.

Zobacz też zmiany w poprzedniej wersji 153.

Zmiany w edytorze RSF

Menu kontekstowe do listy plików

Na liście plików można prawym przyciskiem myszy otworzyć menu kontekstowe, które będzie pozwalało wykonać pewne operacje na plikach w rsfdata. Na początek można odświeżyć listę, co dotychczas można było wykonać np. przez otwarcie okna pobierania danych zewnętrznych (tego z mapą Polski). Planowana jest opcja przeniesienia wcześniejszych wersji plików RSF do rsfold.

Koncepcja zasilania sieci trakcyjnej

Na potrzeby zasilania sieci trakcyjnej zostały utworzone obiekty pomocnicze o kodzie 0x7D00. Wyglądem będą podobne do parametrów łuku. Jeden z punktów (P[1]) będzie można postawić w dowolnym miejscu, a końce (P[0] i P[3]) będą pokazywać najbardziej oddalone od siebie przęsła, do których dany obiekt jest podłączony. Punkt ustawienia nie ma znaczenia użytkowego, jedynie trzeba go umieścić tak, aby było widoczne, na które przęsła wskazuje. Obiekt zasilania może definiować sekcję zasilania sieci (pomiędzy dwoma punktami zasilania) albo punkt zasilania (który może być podstacją albo kabiną sekcyjną, zwierającą z jednego końca kilka sekcji).

Eksportowanie z użyciem kodów eksportu

W definicjach plików INC można ustawić kody eksportowania, określające kolejność i znaczenie parametrów we wpisie include. Głównym zastosowaniem kodów eksportowania jest przetwarzanie obiektów z plików SCM do RSF i następnie z powrotem do SCM, z zachowaniem liczby parametrów include. Dotychczas do niektórych obiektów dodawały się zbędne parametry, jak również problematyczna była obsługa mocowań sieci trakcyjnej z podkatalogu tr/ ze względu na inaczej umieszczone współrzędne — w (p1) (p2) (p3), a nie (p2) (p3) (p4), jak to jest w przypadku większości pozostałych obiektów. Również umieszczenie tekstury w pewnych grupach obiektów było problematyczne Tekstura może być w (p1) — większość modeli 3D, (p5) — mocowania z tr/, (p6) — tabliczki sygnalizatorów, podsypki i napędy rozjazdów, kozły, (p7) — podsypki wykolejnic albo (p8) — obiekty z trzema kątami obrotu. Kody eksportowania umożliwią również korektę położenia rezonatora na łuku z przechyłką — jest specjalny kod eksportowania w tym celu (NXYZADRT). Kody eksportowania dla poszczególnych plików INC są umieszczone w katalogu obiektów (INCE1.DBF), niezależnie od tego eksport do RSF ma zaawansowany algorytm rozpoznawania plików INC i dopasowania im odpowiednich kodów. W razie potrzeby można łatwo zmienić kod eksportowania dla pliku INC w edytorze RSF, a nawet uzyskać sytuację użycia różnych kodów dla jednego pliku INC (musi być zdefiniowany w dwóch osobnych pozycjach).

Zmiana koncepcji pozycjonowania sygnału przy torze

Dotyczy tylko torów bez przypisanej niwelety. Dotychczas, jeśli tor nie miał przypisanej niwelety, to sygnały były pozycjonowane wyłącznie względem ułożenia końców toru. Częściowo było to odpowiedzialne za obracanie sygnałów podczas dodawania niwelety. Obecnie używany jest również znak wartości Id toru, a przypisanie niwelety bądź nie przestało być istotne. Dzięki temu łatwiej jest przenieść obiekty z plików SCM (gdzie z założenia nie ma niwelet), w których wpisy torów mają naliczony kilometraż, a przynajmniej znaki liczb podanych jako "długość" odpowiadają kierunkowi wzrostu kilometrażu (wartość dodatnia oznacza, że punkt 1 ma mniejszy kilometraż niż punkt 2, a ujemna odwrotnie). W związku z tą zmianą może się przejściowo objawiać nieprawidłowe działanie podczas edycji torów bez niwelet (w tym przy dodawaniu niwelety). Będzie to obserwowane i poprawiane w przyszłych wersjach.

Przekroje a warstwy trójkątów

Dotychczas algorytm poszukiwania terenu dla przekrojów poprzecznych poszukiwał jedynie trójkątów w warstwie 0x30, ponieważ przez długi czas obsługa trójkątów była minimalna i była to jedyna używana warstwa. Jednak dla trójkątów opartych na punktach NMT-100 została ustalona warstwa 0x31, przez co były one ignorowane przy wyliczaniu przekrojów. Obecnie wyszukiwane są trójkąty warstw 0x30..0x37, a ignorowane 0x38..0x3F. Obsługa warstw trójkątów będzie prawdopodobnie rozwijana dalej i warunek ten może ulec zmianie. Podział trójkątów na warstwy wynika z potrzeby przeprowadzania operacji na trójkątach o różnym zastosowaniu (np. pominięcie całej warstwy przy eksporcie). Na przykład warstwa 0x32 obejmuje trójkąty fundamentów, wygenerowane z CityGML i trójkąty dodawane w inny sposób powinny być w innych warstwach.

Pochylanie rezonatorów na przechyłce

Rezonatory w RSF są wstawiane na wysokości główki szyny (niwelety), a eksportowane z powinny być z kodem eksportu NXYZADRT. Ten kod eksportowania powoduje, że wykonywane jest przeliczenie punktu wstawienia tak, aby uwzględniane były pochylenie i przechyłka. Przesunięcie w pionie jest realizowane wzdłuż wektora pionowego do powierzchni toru w miejscu wstawienia rezonatora.

Przeliczanie łuku po zmianie parametrów

Przycisk [Zapisz wprowadzone dane] na karcie parametrów łuku powoduje również wykonanie przeliczenia odcinków, które mają przypisany obiekt parametrów łuku. Aktualizuje to np. wartość przechyłki — niemniej obecnie eksport pobiera kąt przechyłki z parametrów łuku. Przeliczenie może też prowadzić do uszkodzeń torów, jeśli są problemy z topologią obiektów (np. łuki odwrotne stykające się krzywymi przejściowymi nie są nadal poprawnie obsługiwane). W przypadku znalezienia odcinka prostego z przypisanym obiektem parametrów łuku, połączenie to jest usuwane.

Korekta wysokości dla obiektów z obrysem

W wersji 153 zostało wyłączone doliczanie korekty wysokości obiektu do współrzędnych obiektu w RSF (ma to na celu oddzielenie sensu obiektu w RSF od jego reprezentacji w symulacji). Obecnie korekta wysokości jest doliczana przy eksporcie. W szczególności korekta wysokości jest stosowana dla bramek trakcyjnych (ma ona wartość -0.53m dla zawieszenia sieci na wysokości 5.25m, a -0.18m dla 5.6m). Docelowo (w przyszłych wersjach) wysokość ustawienia bramki względem niwelety będzie określać wysokość nad torem dolnej krawędzi poprzecznej belki, a odpowiednia różnica będzie uwzględniana przy tworzeniu zwisów — wymagać to będzie skorygowania wszystkich bramek odpowiednim algorytmem (obecnie można to zrobić wpisując wysokość w parametrach INC i dokonując przeliczenia obiektów przyciskiem — tylko dla tegoż INC).

Zmiany w starterze do MaSzyny

Łączenie przęseł sieci trakcyjnej

Dotychczas operacje na sieci trakcyjnej wykonywały łączenie przęseł (ze sobą i ze słupami) tylko w zakresie potrzebnym w danej chwili, czyli np. dla przęsła korygowanego względem toru. Jednak na potrzeby eksportu SCM do RSF dodane zostało łączenie wszystkich przęseł ze sobą (podobnie, jak łączone są ze sobą odcinki torów). Można je także wykonać z menu Sieć w edytorze SCM. Łączenie to (oraz eksport do RSF) wymaga, aby wszystkie sekcje naprężania zostały wcześniej uporządkowane (ten sam kierunek przęseł pomiędzy kotwieniami). W formacie RSF słup jednocześnie określa początek przęsła, w związku z tym nie mogą do jednego słupa dotykać dwa przęsła punktem 1. Kierunek ułożenia przęseł w sekcji naprężania nie ma większego znaczenia, zalecane jedynie jest, aby przęsła były zgodne z kierunkiem wzrostu kilometrażu, co np. przekłada się na jasność sytuacji na krawędzi komórki — z której strony przęsła powinny wystawać.

Poprawiony eksport do RSF

W ramach ulepszania pliku wyczerpy.scm wprowadzone zostały poprawki do eksportu w wersji trzeciej (v3 — z zachowaniem kolejności wpisów; pierwsza wersja została już wyrzucona, druga eksportowała obiekty kategoriami). Poprawki dotyczą przetworzenia tabliczek semaforów, powiązań semaforów oraz sieci trakcyjnej. Przed tymi poprawkami zostały już utworzone pliki RSF dla linii 139 i podczas ich tworzenia pewne błędy zostały zignorowane, a nie było też sieci trakcyjnej. Przy okazji także poprawiany jest eksport z RSF do SCM, aby uzyskany plik był możliwie bliski pierwotnemu (znikają głównie zakomentowane eventy wewnątrz wpisów torów).

Zmiana koncepcji dla mocowań sieci

Mocowania sieci trakcyjnej z tr/ mają inne położenie współrzędnych XYZA we wpisie niż wszystkie pozostałe obiekty punktowe (include), a jednocześnie punkt wstawienia mocowania pokrywa się z końcem dolnej krawędzi przęsła (drut jezdny). Na potrzeby edytora RSF powstała inna koncepcja, w której ważniejszym parametrem jest zachowanie skrajni toru w pobliżu słupa, a punkt mocowania sieci jest drugorzędny — tak zostały skonstruowane słupy w podkatalogu tra/. Jednak edycja scenerii w edytorze SCM ze słupami z tra/ okazała się być problematyczna — ze względu na jego uproszczenie nie było możliwe przyklejenie sieci do słupa z tra/ w odpowiednim miejscu. Obecnie obiekty słupów (mocowań sieci) dostały drugi zestaw współrzędnych XYZ na punkt mocowania sieci, a edytor SCM jest przerabiany w kierunku ich wykorzystania. Z tego względu mogą przejściowo występować problemy w przypadku edycji sieci — wskazane jest wykonanie operacji [Połącz przęsła ze słupami] z menu Sieć, aby zostały wyliczone współrzędne mocowania (przy czym jeszcze nie wszystkie warianty mocowania zostały uwzględnione). Docelowo punkt mocowania sieci będzie wyliczany automatycznie przy wczytywaniu pliku z siecią trakcyjną.

Głównym celem tych zmian jest udoskonalenie eksportu SCM do RSF oraz używanie słupów z tr/ w edytorze RSF z zachowaniem wstecznej zgodności przy eksporcie z RSF do SCM, jak również dotarcie do etapu obsługi sekcjonowania (izolowania sekcji) sieci w edytorach SCM oraz RSF. W dalszej kolejności planowane jest ewentualne udoskonalenie słupów z tr/ (z zachowaniem wstecznej zgodności), aby w pewnym zakresie możliwa była regulacja położenia słupa (np. lepsze spasowanie słupów parasolowych na międzytorzu bądź wysięgników mocowanych do nogi bramki).

Normalizacja kąta azymutu obiektów punktowych

Modyfikacje obiektów punktowych (typu include) będą dawać kąt obrotu w osi pionowej w przedziale <0.0;360.0), wcześniej można było uzyskać kąt o dowolnej wartości, najczęściej w przedziale <-180.0;180.0>. Z menu Operacje można wykonać normalizację dla wszystkich obiektów punktowych w pliku, ale jest to wskazane głównie w przypadku porównania z zawartością eksportowaną z RSF. Eksport z RSF będzie również normalizowany do zakresu <0.0;360.0). Normalizacja kątów nie dotyczy pochylenia ani przechyłki — te kąty będą pozostawione jako ujemne (zwykle nie przekraczają kilku stopni).

Wyszukiwarka nieumocowanych przęseł

Na końcach przęsła sieci trakcyjnej powinny się znajdować obiekty mocowania (np. słupy). Wyszukiwarka pozwala znaleźć przęsła, które nie mają podłączonego mocowania z którejś strony. Między innymi pozwala to znaleźć przęsła, które powinny się stykać, a minimalnie różnią się współrzędnymi. Operacja wyszukania przęsła jest w menu Sieć.

Prowizoryczne naliczanie kilometrażu

Podczas eksportu do RSF sygnalizacja jest pozycjonowana względem kilometrażu linii kolejowej. W związku z tym ważne jest, aby w torach była informacja, czy tor jest ułożony zgodnie ze wzrostem kilometrażu (>0), czy przeciwnie (<0). Wykorzystywane jest pole we wpisie toru, określane kiedyś jako długość odcinka, a nigdy niewykorzystywane w praktyce (symulacja zawsze wylicza długość przy wczytywaniu). Są dwa sposoby ustawienia kilometrażu w torach: można wpisać wartość większą niż 1000 (w sensie bezwzględnym, więc może być też mniejsza niż -1000) w pole "długość" albo przed wskazaniem toru wskazać najbliższy słupek hektometrowy. Wcześniej trzeba dodać do grupy (żółtej) tory, w dla których ma być przeliczony kilometraż. Przeliczanie zatrzyma się na torach, które mają już ustawiony kilometraż (zbliżony do ustawianego — należy uważać w miejscach, gdzie jest więcej niż jedna linia). Wpisywana jest wartość bez ułamka dziesiętnego, ponieważ kilometraż naliczony od jednego punktu jest dużo mniej dokładny niż kilometraż naliczany w RSF, w oparciu o kotwienie znanych wartości w dwóch punktach.

Poprawka dla obrotu grupy torów

Dla prostokątnego zaznaczenia torów (z zakładki Komórki) mogły pojawiać się błędy wyliczenia kąta styczności funkcją atan2(). Było to spowodowane niepotrzebnym przeliczeniem wektorów kontrolnych w odcinkach oraz "poprawianiem" odcinków prostych z wektorami kontrolnymi i zerowym promieniem (promień był ustalany na dużą wartość, a w efekcie wektory kontrolne miały zerową długość). Został poprawiony algorytm korygowania wektorów kontrolnych, a także przeliczeniu podlegać będą tylko odcinki dodane wcześniej do grupy ograniczników rozlania (grupa fioletowa).

Poprawiona obsługa node...model

Przerobiony został parser dla node...model tak, aby można było podać do 8 wartości typu float. Wcześniej rozpoznawane były jedynie 0, 1, 2 i 3, przy czym zapis nie działał poprawnie (ze względu na rzadkie występowanie modeli ze światłami w plikach scenerii, obsługa tego nie miała dużego priorytetu). Eventy zmieniające światła nie są dostosowane, ale póki co Rainsted nie obsługuje analizy ani zarządzania eventami w sceneriach.

Poprawiona obsługa dyrektyw

Dyrektywy w komentarzach, w szczególności //$g (pozycjonowanie scenerii na mapie) oraz //$r (dodanie obiektów jako tło dla pliku SCM), zostały ongiś uruchomione prowizorycznie i przez to nie były prawidłowo zapisywane. Obecnie zapisywanie tych dyrektyw jest poprawione, jednak trzeba zwracać uwagę na ewentualne efekty uboczne. Dodatkowo dla dyrektyw został wprowadzony warunek, aby uwzględniane były tylko te, które są na początku linii (był kiedyś problem z komentarzem, który opisywał użycie dyrektywy, podając ją jako cytat).

Skalowanie przy przeliczaniu prostokątnym

Edytor SCM w Rainsted posiada mechanizm przeliczenia obszarów scenerii. Obszary są definiowane za pomocą prostokątów o bokach równoległych do osi OX i OZ. Każdy obszar prostokątny może być niezależnie obrócony o jakiś kąt względem OXZ, a następnie przesunięty. Z wykorzystaniem tego mechanizmu były parę lat temu naciągane na mapy tory Linii 61, jednak brak skalowania wymuszał wykonanie wielu pracochłonnych poprawek. Obecnie mechanizm ten został nieco udoskonalony — możliwe są dwie opcje skalowania. Pierwsza opcja obejmuje proste odcinki torów, dla których kąt obrotu jest ten sam. W efekcie uzyskuje się proporcjonalne skrócenie albo wydłużenie odcinka. Oczywiście nie powinno się skalować rozjazdów, a uważać też trzeba na długość przęseł sieci trakcyjnej (pojedyncze przęsło nie powinno przekraczać 70m). Skalowanie wykonywane jest względem pionowych albo poziomych boków prostokąta, a skalowane tory powinny przecinać wybraną parę boków. Druga opcja skalowania dotyczy zmiany kąta dla fragmentu łuku. Należy wtedy podać środek okręgu w pierwotnym pliku oraz jego promień (zamiast kąta obrotu i przesunięcia). Tory na łuku powinny przecinać pionowe boki prostokąta (dla poziomych nie zostało przygotowane). Istotne są również sąsiednie obszary prostokątne, ponieważ ich parametry są używane do wyznaczenia docelowego kąta skalowania. Po skalowaniu może być konieczne poprawienie długości przęseł, a także przeliczenie wektorów kontrolnych. Skalowanie zostało przetestowane podczas realizacji Etapu 2 przeliczenia scenerii "Kaliska" (dwa łuki i jeden odcinek prosty).

Poprawiony zapis usuniętych obiektów

Po zaznaczeniu grupy (prostokątnej) można usunąć obiekty, które do grupy nie należą. Obiekty te domyślnie są zapisywane w pliku !wydzielone.scm. Dotychczas były zapisywane grupami wg typu. W ramach Etapu 2 przeliczenia scenerii "Kaliska" zostało uruchomione wydzielanie fragmentu scenerii i pojawiła się potrzeba, by kolejność obiektów została zachowana. Ponadto w specjalny sposób zostały potraktowane bloki komentarza: ich zapis do pliku wydzielonych obiektów zależy od statusu kolejnego wpisu. Jeśli obiekt jest wydzielany, to komentarz przed nim również (i zostaje usunięty z pierwotnego pliku). Jeśli nie jest wydzielany, pozostaje w pierwotnym pliku. Blok komentarza, po którym jest kolejny blok komentarza (oddzielony pustą linią) zostanie zapisany w obu plikach (zarówno razem z obiektami wydzielonymi, jak i w pierwotnym).

---