Po wstępnym dostosowaniu Linii 61 zabrałem się za naprawianie sterowania ruchem z Rainsted. Było to zaczęte w 2010 roku i poprawiane w 2011, ale potem leżało odłogiem.
Co jest potrzebne1. Dwa komputery w sieci TCP/IP, w tym jeden ze stałym IP (może być lokalne), najlepiej z Windows. Można też testować na jednym komputerze, ale jest to uciążliwe. Podejrzewam, że obecnie to już chyba każdy ma jakiś drugi komputer, używany kilka lat wcześniej. Ten gorszy można użyć jako serwer ruchu (ze stałym IP), bo ma mniejsze wymagania sprzętowe.
2. Paczka MaSzyna 15.02 z wgraną ostatnią łatką, dostępną pod adresem
eu07.pl/daily. Na komputerze z serwerem ruchu dobrze by przynajmniej było mieć zaktualizowany katalog
scenery z paczki.
3. Zaktualizowany Rainsted, najlepiej w trybie dla trasopisarzy (od razu wczytuje wszystkie include bez parametrów i łączy tory przy wejściu na Podgląd terenu).
4. Plik scenerii bez zbędnych rzeczy, z którego będzie można utworzyć RSF dla serwera ruchu. Przykładowy plik dla Linii 61:
include linia61/l61_tory.scm end
include linia61/l61_sygnalizacja.scm end
include linia61/l61_drogi.scm end
include linia61/l61_hekto.scm endPo wybraniu takiego pliku w Rainsted trzeba albo wczytać wszystkie include bez parametrów, połączyć tory i dowiązać semafory, albo włączyć tryb dla trasopisarzy i otworzyć Podgląd terenu, która to operacja wykona automatycznie wcześniej wypisane. Następnie należy wyeksportować scenerię do RSF. Dla poprawy prędkości wczytywania RSF dobrze by było jeszcze otworzyć edytor, wybrać utworzony plik RSF i zapisać go. Dzięki temu zostanie uaktualniony do najnowszej wersji struktury i nie będzie ta operacja powtarzana przy każdym uruchomieniu serwera (eksport zapisuje nieco starszą wersję niż edytor). Plik ten trzeba przekopiować albo utworzyć na komputerze z serwerem ruchu. Ja aktualnie testuję Linię 61, inne scenerie mogą wymagać pewnych drobnych zmian (np. nazwania wszystkich torów, przypisania semaforów, itp.). Nie zamieszczę gotowego pliku RSF, ponieważ na dniach mam zamiar wymienić nazwy rozjazdów i semaforów na zgodne ze schematami i po tej operacji trzeba będzie zrobić nowy RSF. Więc najlepiej zrobić sobie samodzielnie z ostatnio pobranej nakładki na paczkę i w razie pobrania nowszej nakładki powtórzyć tworzenie RSF.
Procedura uruchomienia5. Na komputerze przeznaczonym na serwer ruchu uruchamiamy najnowszy Rainsted i z zakładki Ustawienia uruchamiamy serwer ruchu guzikiem po prawej. W otwartym oknie możemy wybrać zrobiony wcześniej plik RSF dla scenerii oraz zmienić port z domyślnego 42400 na inny. Następnie użyć przycisku
Uruchom serwer. Serwer ma dwa tryby pracy, o czym poniżej — można wybrać tylko jeden.
6. Na komputerze z symulacją wybieramy scenerię — jeśli RSF będzie utworzony z Linii 61 w sposób opisany powyżej, to można wybrać dowolny z 8 scenariuszy. Co do innych scenerii, to nie mogę zagwarantować, że będą współpracować. Scenerię uruchamiamy bez wyłączania Rainsted. Po wczytaniu scenerii używamy przycisku
Multiplayer na dole okna Rainsted i wpisujemy IP serwera oraz numer portu. Wpisane dane powinno dać się zapisać i wtedy nie będzie potrzeby ich ponownego wpisywania przy kolejnym uruchomieniu. Login i hasło są obecnie bez znaczenia. Istotny jest ptaszek przy
Ponawiaj, ponieważ w razie błędu połączenia bądź rozłączenia z poziomu serwera wykona ponowne zalogowanie. W momencie logowania zapamiętywany jest numer okna symulatora — gdyby tam nadal było 0, to oznacza jakiś problem z oknami.
Dwa tryby pracyWspomniałem wcześniej o dwóch trybach pracy. Różnią się one sposobem współpracy z symulacją, a główną cechą jest liczba jednocześnie podłączonych użytkowników.
Pierwszy nazwałem
Instruktor i jest tryb, w którym można uruchamiać normalne scenariusze. Na podglądzie serwera ruchu powinny być widoczne zajętości odcinków (tory rysowane kolorem czerwonym) oraz stany semaforów. Osoba obsługująca serwer ruchu może ingerować w działanie scenariusza — gasić semafory, zmieniać drogę przebiegu, podawać inne sygnały. Należy jednak znać działanie scenariusza i dokonywać zmian dopiero po tym, gdy uruchomią się mechanizmy scenariusza (inaczej to scenariusz poustawia rozjazdy i semafory). Ten tryb pozwala obsłużyć tylko jednego podłączonego użytkownika, ponieważ niemożliwy byłby jednoczesny podgląd stanu scenerii u wielu użytkowników na raz. Oprócz zabawy w dwie osoby tryb ten może być przydatny do eksperymentowania z modyfikowaniem scenariuszy, a także testowania scenariuszy w trakcie ich tworzenia.
Drugi tryb nazwałem
Dyżurny i jest on przeznaczony do synchronizacji stanu urządzeń u wielu użytkowników. Używane scenerie powinny być raczej pozbawione scenariuszy, ponieważ mogą one wprowadzać chaos. W tym przypadku to osoba obsługująca serwer ruchu decyduje i ustawia rozjazdy oraz semafory. Zmieniony stan jest rozsyłany do wszystkich użytkowników i do czasu potwierdzenia urządzenie migocze kolorem białym ("brak kontroli", czyli u każdego użytkownika może być inny stan). Nowy użytkownik dostaje po zalogowaniu eventy przestawiające urządzenia, które są w stanie innym niż podstawowy (zakłada się, że po wczytaniu scenerii zwrotnice są na wprost, a semafory i tarcze zabraniają jazdy — z wyjątkiem SBL). Serwer ruchu pozwala synchronizować scenerie w zakresie urządzeń, czyli dany użytkownik jeździ jednym pociągiem, a pozostałe są prowadzone przez AI. Nie ma synchronizacji pozycji pojazdów, więc nie są możliwe interakcje pomiędzy użytkownikami (np. popych).
Z czasem pewnie będzie to ewoluować, być może nawet oba tryby da się połączyć w jeden (tzn. będzie podgląd stanu scenerii wybranego użytkownika). Być może z czasem dojdzie synchronizacja położenia pojazdów czy sterowania. Ale póki co do rozwiązania jest wiele innych problemów.
Wątek: Sterowanie ruchem z Rainsted (Przeczytany 19210 razy)