- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Na warsztacie => Wątek zaczęty przez: Paul w 13 Stycznia 2017, 00:48:09
-
Dzień dobry,
Być może niektórzy znają projekt SCS-1 (Symulacyjne Centrum Sterowania), będący interfejsem operatora i systemem zależnościowym współpracującym z symulatorem TD2, imitującym komputerowe urządzenia srk (nie jest to symulator konkretnego typu urządzeń). Program udostępniony jest na forum TD2 jako załącznik dostępny po zalogowaniu, bez zalogowania można przejrzeć ogólne informacje i dokumentację użytkownika: http://td2.info.pl/index.php/topic,100.0.html
Pierwotnie program powstawał z myślą o Maszynie, która również została dostosowana do takiej formy sterowania, choć dotąd nie było to nigdzie szerzej wykorzystywane. W ostatniej wersji uruchomiona została automatyka nastawiania przebiegów, która pozwala na użycie programu w roli systemu samodzielnie sterującego ruchem na scenerii według wczytanego planu przebiegów, z możliwością interwencji użytkownika w proces sterowania. Mamy zatem coś na kształt VD, którego koncepcja przewijała się na forum już dawno temu. Eventy przestają być używane do realizowania logiki sterowania, a stają się warstwą wykonawczą (przynajmniej jeżeli chodzi o srk). Odpadają problemy typu za wczesne przestawienie zwrotnicy spowodowane za długim składem, ruch na scenerii przestaje być sztywny - dodanie pociągu, zmiana kolejności jazd czy miejsca krzyżowania nie stanowi problemu. Rozwiązanie rozwinąć można o kolejną warstwę, nadrzędną w stosunku do SCS-1, która może zarządzać rozkładem jazdy i dynamicznie generować plan przebiegów (jest on odczytywany z dysku cyklicznie). Oczywiście można też wcielić się w rolę dyżurnego ruchu i sterować ręcznie.
W tym wątku przedstawiam przykład scenerii sterowanej w ten sposób, z Maszyną działają praktycznie wszystkie funkcje przewidziane w programie (m.in. nastawianie przebiegów, pip - śledzenie numerów, przejazdy, sbl, ANP). Niezbędne pliki wraz z samym programem zamieszczone są w załączniku. Otwarta pozostaje kwestia dostosowania plików .inc do sterowania przez program - bez zmian plików oraz pewnych zmian w sceneriach nie będzie to możliwe. Pliki .inc zaprezentowane tutaj mają raczej charakter prowizorki.
Ogólne założenia:
- program SCS-1 uruchamiany jest przed uruchomieniem Maszyny, wybierany jest plik pulpitu, po czym program oczekuje na nawiązanie połączenia, tzn. wywołanie eventu "gotow_<nazwa>" przez Maszynę po uruchomieniu scenerii (na pulpicie przestanie migać białe oznaczenie EU07, pojawi się zielone oraz wyświetlony zostanie właściwy stan zajętości odcinków),
- SCS-1 łączy się z Maszyną komunikatami międzyprocesowymi WM_COPYDATA, w razie potrzeby możliwe jest zastosowanie dodatkowego ogniwa transmisyjnego i uruchomienie SCS-1 na innym komputerze, z połączeniem TCP/IP (uzyskujemy wtedy namiastkę symulacji sieciowej dyżurny - maszynista; nie wiem jak wygląda temat multiplayera z wieloma maszynistami - czy cokolwiek było w tym kierunku robione?),
- sterowanie i kontrola odbywa się na zasadzie zdalnego wywoływania eventów typu multiple oraz detekcji ich wykonania w Maszynie (własnych oraz innych, uruchomionych np. eventami torów), ponadto wykrywane są zajętości odcinków izolowanych - są one wymagane w scenerii (działanie komunikacji można podejrzeć w rejestratorze SCS-1 - uwaga: w trybie testowym logi będą trochę inne),
- z uwagi na nieciągłą komunikację stosowane jest cykliczne kontrolowanie zdalnego wykonywania eventu "gotow_<nazwa>",
- plik pulpitu SCS-1 zawiera graficzny obraz stacji wraz z danymi niezbędnymi do realizacji zależności, plik ten tworzony jest przy pomocy dołączonego edytora,
- obsługa programu jest zbliżona do obsługi komputerowego pulpitu nastawczego, z możliwością automatyzacji w pewnym zakresie.
Rzeczy, które wymagają przedyskutowania/przeróbki/dopracowania:
- brak możliwości sterowania niektórymi obiektami bez modyfikacji plików .inc - zdalnie działają tylko eventy multiple, a niektóre są innych typów (dotyczy większości sygnalizatorów - sterowanie W24, również Sp),
- generalnie konieczność usunięcia z plików .inc obiektów wszelkich uzależnień od torów, innych semaforów, opóźnień zadziałania itp. - zależności realizuje SCS-1 (dotyczy głównie powiązań sygnalizatorów oraz przejazdów),
- konieczność usunięcia ze scenerii wszelkich eventów oddzielnie sterujących obiektami, które sterowane i kontrolowane mają być przez SCS-1,
- konieczność uzupełnienia plików .inc zwrotnic o eventy kontrolujące rozprucia (brak detekcji ewentualnych rozpruć może doprowadzić do nieciekawych efektów),
- wskazane jest uporządkowanie nazw obiektów oraz sposobu ich nadawania w sceneriach, jak również rozmieszczania odcinków izolowanych i eventów używanych jako czujniki ssp (dokumentacja użytkownika zawiera wytyczne co do nazw obiektów).
Możliwe rozwiązania:
- adaptacja plików które zamieściłem w załączniku po drobnych poprawkach - część jest nowa, a część stanowi "nakładki" na stare pliki, wszystkie wymagają sprawdzenia - proszę nie traktować ich jak gotowego rozwiązania do stosowania,
- przygotowanie nowych wersji plików .inc przeznaczonych do zdalnego sterowania z zewnątrz, z uporządkowanymi nazwami eventów, najlepiej o formacie "<obiekt>:<akcja>", podobnie jak przyjęte zostało w TD2 (obecnie zgodne z tą konwencją są tylko eventy "forced+" i "forced-" zwrotnic, pozostałe na ogół używają znaku "_", z kolei zwrotnice i wykolejnice jedynie dodają znak +/-/o/z do nazwy).
Interfejs sterowania używany przez SCS-1 może być wykorzystany również przez inne programy, planuję dostosować kiedyś pod tym kątem symulator ISDR.
Wykaz aktualnie używanych w komunikacji z Maszyną eventów:
a) zwrotnice
- "<nazwazwr>+", "<nazwazwr>-" - przestawienie do położenia "+", "-"; wykonanie eventu jest traktowane jako kontrola wysterowania, z określonym opóźnieniem przyjmowana jest kontrola położenia końcowego,
- "<nazwa>:forced+", "<nazwa>:forced-" - event wykonywany w scenerii gdy zwrotnica zostanie rozpruta i przestawiona przez tabor do położenia "+", "-",
b) wykolejnice
- "<nazwawk>o", "<nazwawk>z" - otwarcie, zamknięcie wykolejnicy, analogicznie jak przestawienie zwrotnicy,
c) sygnalizatory (w tym TOP)
- "<nazwasygn>_<sygnal>" - wyświetlenie sygnału; wykonanie eventu jest traktowane jako kontrola wysterowania; w miejscu <sygnal> pojawia się nazwa sygnału zapisana małymi literami, lub "wyg" - wygaszenie TOP/semafora sbl (sygnalizator ciemny), dla wyświetlenia Sz używane jest oznaczenie "sz1", dla wskaźników W24 - "w24" i "w24off",
d) przejazdy
- "<nazwaprzej>_zamykaj", "<nazwaprzej>_otwieraj" - rozpoczęcie zamykania/otwierania; wykonanie eventu jest traktowane jako kontrola wysterowania, natomiast stan zamknięcia/otwarcia przyjmowany jest z pewnym opóźnieniem (za właściwą sekwencję sterowania sygnalizatorami drogowymi, dzwonem i rogatkami odpowiada już sam .inc),
- "<nazwaprzej>_wj1", "<nazwaprzej>_wj2", "<nazwaprzej>_zw" - w przypadku przejazdu zamykanego czujnikami: wjazd na czujnik zamykający od strony 1, wjazd na czujnik zamykający od strony 2, zjazd ze strefy przejazdu (realizowane jako eventy torów, przy czym "_zw" uruchamiany jest warunkowo po cyklicznym sprawdzaniu stanu toru przez oddzielny plik .inc),
e) odcinki izolowane
- używany jest oddzielny rodzaj komunikatów, bez wykorzystania eventów.
Zawartość załącznika:
- SCS.exe - plik programu, jest to nieznacznie zmodyfikowana wersja 2017.01.07 znana użytkownikom TD2 (poprawione zostały funkcje komunikacji z Maszyną; należy wybrać tryb WM_COPYDATA; z uwagi na rozwojowy charakter powiązania z Maszyną wersję tą traktować należy jako roboczą, a nie stabilną),
- EdytorSCS.exe - edytor pulpitów,
- dokumentacja/ - dokumentacja użytkownika (ta sama co na forum TD2),
- scenery/*.inc - nakładki i zmienione wersje plików .inc przystosowane do sterowania z zewnątrz, oryginalne pliki nie są zmieniane/nadpisywane,
- scenery/anp_test.scn - prosta sceneria przystosowana do sterowania przez SCS-1, zawiera cztery małe posterunki ruchu, jeden przejazd włączany czujnikami, jeden przejazd uzależniony w przebiegach, dwa szlaki jednoodstępowe z ruchem na zasadzie utwierdzania przebiegów oraz jeden szlak z czterostawną, dwukierunkową sbl (uwaga: dla włączenia komunikacji WM_COPYDATA konieczne jest ustawienie multiplayer 1 w eu07.ini),
- anp_test.scs - plik pulpitu dla powyższej scenerii (możliwe jest również uruchomienie programu w trybie testowym, bez Maszyny/TD2, z zajętościami zadawanymi ręcznie),
- anp_test.anp - plan przebiegów, po uruchomieniu którego program automatycznie będzie prowadził pociągi z jednego końca scenerii na drugi, realizując krzyżowania w razie potrzeby (po uruchomieniu SCS-1 i następnie Maszyny należy wczytać i uruchomić plan ANP w SCS-1 oraz wprowadzić numery pociągów w SCS-1 - nieparzyste jadą w prawo, parzyste w lewo, zawiera również pewne zautomatyzowane manewry - więcej informacji w komentarzach w pliku).
Działanie niektórych szczegółów dokładniej opisane jest w dokumentacji użytkownika. Powinno ruszyć bez większych problemów, choć nie testowałem tego na standardowych paczkach całościowych - używam własnej, minimalistycznej "dystrybucji" symulatora na potrzeby testów. Proszę o uwagi na temat rozwiązania plików .inc jak i całego programu oraz możliwości jego zastosowania w Maszynie.
-
Super, moje przemyślenia:
1. Tylko TCP/IP lub inne sposoby komunikacji międzyprocesowej, WM_COPYDATA to nie jest sposób komunikacji.
2. Chciałem od dawna zaimplementować w exe ZeroMQ w tym celu. Wymaga opracowania protokołów danych, ale można wtedy przesyłać wszystko binarnie i w trybie push. Czy jest to do zrobienia w SCS?
3. Chciałbym zupełnie wyrzucić eventy ze sterowania. To też było już dyskutowane wstępnie. Czyli
a. Niskopoziomowo nie uruchamiamy eventów do sterowania srk tylko żądamy konkretnego stanu (ustawienia) dla danego urządzenia. Urządzenie wysyła nam swój stan po zmianie lub na żądanie.
b. Średniopoziomowo to łatwiej by było, gdyby nie trzeba generować tego poziomu w ogóle, czyli SCS sam tworzy na swoje potrzeby ten poziom za pomocą parsera scenerii podczas wczytywania.
c. Wysokopoziomowo żeby to zaimplementować jest potrzebny element sterowania scenariuszem: czyli wyznaczanie przebiegów jak i wysyłanie poleceń do pojazdów (zmień kierunek, odepnij się od wagonów i takie tam). To co teraz jest robione za pomocą sygnałów co jest ogólnie chorym pomysłem z punktu widzenia architekturalnego.
Do poziomu 3b da się zrobić multiplayera. Żeby zmienić sposób sterowania niestety 3c jest niezbędny co wcale nie będzie łatwe ale jak najbardziej wykonalne.
-
@Paul: a czy Testowo dało by się do tego modyfikować? IMO pulpit kostkowy wydaje się być bardziej elastyczny w konstrukcji (zarówno w pamięci komputera jak i namacalnego pulpitu dla chętnych) i podpięciu do symka jako źródła danych o ruchu pojazdów.
-
No ja sie bede musial troche napocic, aby to uruchomic, ze wzgledu na stara paczke calosciowa, ale mam pytanko pawle (sorry, ze z malej litery, ale klawa w telefonie zepsuta). Mianowicie, zauwazylem, iz zwrotnice w scenerii maja geometrie bliska linii prostej. Dopiero do koncowek zwrotnicy, masz odpowiednio wygiete tory. Dlaczego tak? Ja sobie wytlumaczylem, iz w ten sposob zwrotnice sa uniwerslane (np. predkosci), a dopiero tory dolaczone do koncowek, decyduja o typie zwrotnicy. W sumie jesli mam racje, to sprytnie wykombinowane, ale z drugiej strony, to juz sam nie wiem, czy lepsze szablony, czy twoj sposob.
-
1. Tylko TCP/IP lub inne sposoby komunikacji międzyprocesowej, WM_COPYDATA to nie jest sposób komunikacji.
2. Chciałem od dawna zaimplementować w exe ZeroMQ w tym celu. Wymaga opracowania protokołów danych, ale można wtedy przesyłać wszystko binarnie i w trybie push. Czy jest to do zrobienia w SCS?
W obecnym rozwiązaniu stosowane jest WM_COPYDATA, ponieważ zostało już wcześniej przewidziane w Maszynie do takich celów i radzi sobie całkiem dobrze. WM_COPYDATA przewiduje ponadto kilka innych funkcji nieużywanych przez SCS.
Dla zdalnego sterowania docelowo proponuję tekstowe TCP/IP z uwagi na prostotę i możliwość sterowania z innego komputera (Maszyna w roli serwera TCP/IP, tak jak działa to dla TD2). Idealnie było by uzyskać protokół jak najbardziej ujednolicony dla obu obecnie obsługiwanych symulatorów (Maszyna i TD2) - dla TD2 powstawał od zera, bez bałaganu narzuconego przez stare pliki i warto to wykorzystać (notacja "<obiekt>:<akcja>"). Chyba że ZeroMQ również sobie poradzi przez sieć i posiada jakieś istotne zalety w porównaniu do komunikatów TCP/IP.
3. Chciałbym zupełnie wyrzucić eventy ze sterowania. To też było już dyskutowane wstępnie. Czyli
a. Niskopoziomowo nie uruchamiamy eventów do sterowania srk tylko żądamy konkretnego stanu (ustawienia) dla danego urządzenia. Urządzenie wysyła nam swój stan po zmianie lub na żądanie.
Jeżeli eventy z Maszyny zostaną usunięte i zastąpione innym rozwiązaniem, dostosowanie SCS nie będzie większym problemem (pod warunkiem, że jakieś istotne sygnały/stany nie zostaną pominięte).
b. Średniopoziomowo to łatwiej by było, gdyby nie trzeba generować tego poziomu w ogóle, czyli SCS sam tworzy na swoje potrzeby ten poziom za pomocą parsera scenerii podczas wczytywania.
SCS automatyzuje zależności tam gdzie to możliwe, ale nadal niektóre parametry trzeba wprowadzić ręcznie (wszelkie nietypowe uzależnienia i dane których nie da się odgadnąć z samego kształtu układu torowego). Generowanie danych dla tej warstwy automatycznie, wprost ze scenerii będzie i tak wymagało wprowadzania tych parametrów dla obiektów scenerii, co niekoniecznie będzie bardziej wygodne od ich wprowadzenia w przeznaczonym do tego edytorze. Ponadto automat nie wygeneruje estetycznie wyglądającego schematu układu torowego.
c. Wysokopoziomowo żeby to zaimplementować jest potrzebny element sterowania scenariuszem: czyli wyznaczanie przebiegów jak i wysyłanie poleceń do pojazdów (zmień kierunek, odepnij się od wagonów i takie tam). To co teraz jest robione za pomocą sygnałów co jest ogólnie chorym pomysłem z punktu widzenia architekturalnego.
W podanym rozwiązaniu w pliku .anp definiowane jest, które przebiegi są wjazdowe i wyjazdowe dla poszczególnych posterunków, czy też w zależności od kategorii pociągu, manewry itp. Po przyjęciu przejrzystej notacji dla tych przebiegów warstwa wyżej może zająć się już ściśle rozkładem jazdy, bez zastanawiania się jakie konkretnie przebiegi nastawiać, oraz ewentualnymi poleceniami dla pojazdów typu połącz/odłącz - choć te myślałem "doklejać" do definicji przebiegów w planie .anp (typu - gdy pociąg X wjedzie na stację A, ustaw manewr za semafor wyjazdowy i jednocześnie każ odłączyć lokomotywę).
@Paul: a czy Testowo dało by się do tego modyfikować? IMO pulpit kostkowy wydaje się być bardziej elastyczny w konstrukcji (zarówno w pamięci komputera jak i namacalnego pulpitu dla chętnych) i podpięciu do symka jako źródła danych o ruchu pojazdów.
Jest możliwe podłączenie do opisanego interfejsu symulatora urządzeń przekaźnikowych, ale raczej jako symulator urządzeń przekaźnikowych, a nie kompleksowe narzędzie zarządzania i sterowania ruchem w scenerii. Pulpit kostkowy jest bardziej pracochłonny do przygotowania (tu mamy zróżnicowane szczegóły graficzne kostek, różne przyciski dla poszczególnych obiektów, natomiast w wersji komputerowej w zasadzie obiekty i łączące je linie), dla dużych odcinków sterowania będzie niezbyt przejrzysty i kiepsko nadaje się do automatyzacji. Można niby zrobić to samo co w SCS, wyglądające z grubsza jak pulpit kostkowy, ale powstanie twór który nie istnieje w rzeczywistości - tymczasem interfejs graficzny i sposób działania SCS wzorowany jest na rzeczywistych centrach sterowania.
Mianowicie, zauwazylem, iz zwrotnice w scenerii maja geometrie bliska linii prostej. Dopiero do koncowek zwrotnicy, masz odpowiednio wygiete tory.
Rozjazd złożony jest tu z części zwrotnicy - mniej więcej o rzeczywistej długości iglic - oraz odcinków stanowiących resztę. Obie części są łukiem o promieniu 300 m. Nietypowy format rozjazdów wynika z tego, że sceneria jest eksportem z edytora którego zasadniczo używam do ISDR.
-
W obecnym rozwiązaniu stosowane jest WM_COPYDATA, ponieważ zostało już wcześniej przewidziane w Maszynie do takich celów i radzi sobie całkiem dobrze. WM_COPYDATA przewiduje ponadto kilka innych funkcji nieużywanych przez SCS.
Dla zdalnego sterowania docelowo proponuję tekstowe TCP/IP z uwagi na prostotę i możliwość sterowania z innego komputera (Maszyna w roli serwera TCP/IP, tak jak działa to dla TD2). Idealnie było by uzyskać protokół jak najbardziej ujednolicony dla obu obecnie obsługiwanych symulatorów (Maszyna i TD2) - dla TD2 powstawał od zera, bez bałaganu narzuconego przez stare pliki i warto to wykorzystać (notacja "<obiekt>:<akcja>"). Chyba że ZeroMQ również sobie poradzi przez sieć i posiada jakieś istotne zalety w porównaniu do komunikatów TCP/IP.
WM_COPYDATA zostanie zapewne jeszcze przez jakiś czas z nami. ZMQ działa na TCP/IP. To jest po prostu mechanizm kolejkowania, buforowania i zapewniania dotarcia wiadomości do nadawcy. W niego można jak najbardziej wsadzić dowolną treść i nie dekodujesz komunikatu TCP tylko obiekt daje Ci event do przepracowania jak przyjdzie wiadomość. Notacja może zostać jeśli to jest jakiś problem aczkolwiek widzę problem przypisywania wtedy do SCS logiki SRK każdego elementu wykonawczego, np sem_f:s1 co jest troszkę bez sensu. Lepiej byłoby mieć elementy wykonawcze po stronie exe. Chodzi mi o to, że SCS wysyła wtedy co dokładnie chce mieć wyświetlone zamiast co chce osiągnąć.
Jeżeli eventy z Maszyny zostaną usunięte i zastąpione innym rozwiązaniem, dostosowanie SCS nie będzie większym problemem (pod warunkiem, że jakieś istotne sygnały/stany nie zostaną pominięte).
Co znaczy istotne sygnały/stany?
SCS automatyzuje zależności tam gdzie to możliwe, ale nadal niektóre parametry trzeba wprowadzić ręcznie (wszelkie nietypowe uzależnienia i dane których nie da się odgadnąć z samego kształtu układu torowego). Generowanie danych dla tej warstwy automatycznie, wprost ze scenerii będzie i tak wymagało wprowadzania tych parametrów dla obiektów scenerii, co niekoniecznie będzie bardziej wygodne od ich wprowadzenia w przeznaczonym do tego edytorze. Ponadto automat nie wygeneruje estetycznie wyglądającego schematu układu torowego.
Ładny wygląd jest potrzebny do zabawy w dyżurnego. Do sterowania może nie być nawet nic wyświetlane. Ale rozumiem, że to może nie być najprostsze.
Edytor jest tak łopatologiczny, żeby przeciętna osoba się obsłużyła w nim nie znając do końca przepisów?
W podanym rozwiązaniu w pliku .anp definiowane jest, które przebiegi są wjazdowe i wyjazdowe dla poszczególnych posterunków, czy też w zależności od kategorii pociągu, manewry itp. Po przyjęciu przejrzystej notacji dla tych przebiegów warstwa wyżej może zająć się już ściśle rozkładem jazdy, bez zastanawiania się jakie konkretnie przebiegi nastawiać, oraz ewentualnymi poleceniami dla pojazdów typu połącz/odłącz - choć te myślałem "doklejać" do definicji przebiegów w planie .anp (typu - gdy pociąg X wjedzie na stację A, ustaw manewr za semafor wyjazdowy i jednocześnie każ odłączyć lokomotywę).
Warstwa wyżej powinna mieć informacje o torze podstawowym i ewentualnych alternatywach na danej stacji. Pliki dla przebiegów powinny umożliwiać napisanie na nim dowolnego scenariusza, czyli wszelkie sterowanie pojazdami bezpośrednio odpada w takim przypadku. Jeśli w SCS masz informacje o tym na którym torze masz dany pociąg to możesz z VD dawać polecenie dla pociągu tego na tej stacji podstawowy tor to 1, a alternatywne 3 i 5. Na tej podstawie SCS wie czy pociąg jest na parzystym / nieparzystym na szlaku i na które tory może wjechać pociąg. Chyba, że wolisz to wyrzucić do góry. Ale wtedy VD musi mieć tą informację i wysyłać do SCS polecenia ustawienia poszczególnych przebiegów.
Jest możliwe podłączenie do opisanego interfejsu symulatora urządzeń przekaźnikowych, ale raczej jako symulator urządzeń przekaźnikowych, a nie kompleksowe narzędzie zarządzania i sterowania ruchem w scenerii. Pulpit kostkowy jest bardziej pracochłonny do przygotowania (tu mamy zróżnicowane szczegóły graficzne kostek, różne przyciski dla poszczególnych obiektów, natomiast w wersji komputerowej w zasadzie obiekty i łączące je linie), dla dużych odcinków sterowania będzie niezbyt przejrzysty i kiepsko nadaje się do automatyzacji. Można niby zrobić to samo co w SCS, wyglądające z grubsza jak pulpit kostkowy, ale powstanie twór który nie istnieje w rzeczywistości - tymczasem interfejs graficzny i sposób działania SCS wzorowany jest na rzeczywistych centrach sterowania.
Pulpit kostkowy nadaje się do odwzorowania obwodów poszczególnych posterunków / najwyżej stacji. Nie całej scenerii. Aczkolwiek wydaje mi się, że można to zrobić jako nakładka do zabawy dla dyżurnego, tak samo jak rysujesz schematy dla komputerowych.
-
WM_COPYDATA zostanie zapewne jeszcze przez jakiś czas z nami. ZMQ działa na TCP/IP. To jest po prostu mechanizm kolejkowania, buforowania i zapewniania dotarcia wiadomości do nadawcy. W niego można jak najbardziej wsadzić dowolną treść i nie dekodujesz komunikatu TCP tylko obiekt daje Ci event do przepracowania jak przyjdzie wiadomość.
Tak czy inaczej używam bibliotek które załatwiają sprawy sieciowe, sama logika SCS wysyła/dostaje gotowy komunikat tekstowy i nie interesuje się, czy to było TCP/IP, WM_COPYDATA, zapętlenie w trybie testowym czy coś innego. W razie potrzeby mogę je rozszerzyć o ZMQ.
Notacja może zostać jeśli to jest jakiś problem aczkolwiek widzę problem przypisywania wtedy do SCS logiki SRK każdego elementu wykonawczego, np sem_f:s1 co jest troszkę bez sensu.
Pozostawienie starych nazw eventów nie jest problemem, jednak skoro piszesz że eventy zostaną całkiem usunięte, to może warto przy okazji uporządkować nazwy komunikatów dla obiektów srk.
Co znaczy istotne sygnały/stany?
Chodziło mi o zachowanie zakresu obecnie używanych w komunikacji SCS - Maszyna komunikatów (stany urządzeń oczywiście mają charakter pseudo-ciągły, bez ciągłej kontroli), tak aby nie okazało się, że po zmianie rozwiązania na dole będzie czegoś brakować do poprawnego działania.
Ładny wygląd jest potrzebny do zabawy w dyżurnego. Do sterowania może nie być nawet nic wyświetlane. Ale rozumiem, że to może nie być najprostsze.
Edytor jest tak łopatologiczny, żeby przeciętna osoba się obsłużyła w nim nie znając do końca przepisów?
Czytelny graficzny interfejs, jeżeli nawet wykluczamy ręczną obsługę jako dyżurny ruchu, bardzo ułatwi choćby testowanie na sucho działania systemu dla danej scenerii.
Edytor jest dość łopatologiczny, ale trzeba mieć minimum wiedzy na temat srk i ruchu aby zrobić porządny plik pulpitu (system sygnalizacji, logika zależnościowa, niektóre reguły rozmieszczania urządzeń srk itp.). Moim zdaniem nie da rady wiele dalej zautomatyzować tworzenia danych zależnościowych, chyba że kosztem odejścia od realizmu sterowania (typu ustawianie przebiegów które nie mają sensu lub pomijanie pewnych zależności). Zakładam, że do tworzenia scenerii czy danych do sterowania niezbędna jest znajomość przynajmniej podstawowych przepisów - w przeciwnym razie powstawać będą buble.
Warstwa wyżej powinna mieć informacje o torze podstawowym i ewentualnych alternatywach na danej stacji. Pliki dla przebiegów powinny umożliwiać napisanie na nim dowolnego scenariusza, czyli wszelkie sterowanie pojazdami bezpośrednio odpada w takim przypadku. Jeśli w SCS masz informacje o tym na którym torze masz dany pociąg to możesz z VD dawać polecenie dla pociągu tego na tej stacji podstawowy tor to 1, a alternatywne 3 i 5. Na tej podstawie SCS wie czy pociąg jest na parzystym / nieparzystym na szlaku i na które tory może wjechać pociąg. Chyba, że wolisz to wyrzucić do góry. Ale wtedy VD musi mieć tą informację i wysyłać do SCS polecenia ustawienia poszczególnych przebiegów.
W obecnym rozwiązaniu zakładam, że warstwa nadrzędna informuje SCS, w którym kierunku i o której godzinie dany pociąg ma jechać, oraz w razie potrzeby na które tory może zostać przyjęty. Czyli generalnie zajmuje się dostarczeniem danych zawartych w rozkładzie jazdy. Jeżeli możliwa jest pewna dowolność jazd, wybór toru odbywa się już w SCS zależnie od stanu i dostępności elementów infrastruktury. Czyli warstwa nadrzędna w zasadzie planuje ruch bez kontroli wykonania planu, choć nie wykluczam dodania przepływu informacji z SCS do góry (lokalizacja pociągów, dostępność torów) gdyby było to potrzebne.
-
Odnośnie przekazywania informacji pomiędzy aplikacjami/komputerami. O ile na jednej maszynie fizycznej między różnymi aplikacjami można wykorzystać mechanizm stosowany w D-Bus (który nawet ma porta na winde), to przy sieci trzeba po prostu znaleźć albo coś podobnego, ale sposób na tunelowanie D-Bus.
-
Paul, wydaje mi się, że mieszasz w SCS funkcjonalność dwóch różnych warstw. Jeśli w SCS będzie już wybór konkretnego toru z dostępnych to albo będziesz mieć bardzo skomplikowany algorytm wyboru torów dla kolejnych pociągów, żeby to było elastyczne i przewidywało przyszłość, albo oddajesz to autorowi scenariusza. Jeśli to drugie to powodujesz, że pliki układu torowego nie będą przypisane do scenerii tylko scenariusza, czy dokładnie to samo co mamy teraz i z czego chcemy zejść.
Oczywiście obowiązkowe wpisanie na które tory pociąg może wjechać wielce upraszcza algorytm sterowania nie komplikując przesadnie pracy scenarzysty.
El, ZMQ jest o tyle fajne, że automatycznie wybiera sposób przesyłania danych zależnie od tego gdzie jest uruchomiony drugi program. Jeśli na tej samej maszynie to wybiera np. D-Busa, jeśli gdzieś w necie to TCP.
-
To jest rozdzielone. Podstawowo SCS odpowiada za kontrolę scenerii, realizację zależności i sterowanie (nastawianie przebiegów, sygnały, sterowanie przejazdami itp.) na podstawie pliku .scs, przypisanego do scenerii, nie zawierającego danych dla konkretnych scenariuszy. Przy użyciu tylko tego pliku można jedynie sterować ręcznie.
Nakładką na to jest funkcja ANP, która automatycznie nastawia przebiegi na podstawie pliku .anp, w którym definiowane jest, kiedy i dla jakich pociągów jakie ma nastawiać przebiegi. Plik ten przypisany jest do scenariusza i wybierany opcjonalnie po uruchomieniu SCS z daną scenerią. W tym pliku możliwe jest zdefiniowanie przebiegów z grupy torów/na grupę, dzięki czemu w razie niedostępności jednego toru, przebieg nastawiony zostanie na inny. Nie jest to jednak obowiązkowe - można zdefiniować przebieg tylko na jeden tor.
Plik .anp może zawierać reguły ogólne, np. przepychanie wszystkich pociągów parzystych/nieparzystych w określonych kierunkach bez zdefiniowanych godzin, może również zawierać reguły dla konkretnego pociągu z uwzględnieniem godzin odjazdu. Ponieważ SCS przeładowuje ten plik w cyklu pracy ANP (co ok. 10 s), może być on na bieżąco modyfikowany ręcznie lub przez inną aplikację, która stanowiłaby interfejs do wprowadzania rozkładu jazdy czy też sama zarządzałaby ruchem.
-
A czy możliwe było by przypinanie do poszczególnych stacji/podg (a nawet okręgów) osobnych .anp? Bo z tego co mi z tego topic'u wychodzi, to pojawia się możliwość włączenia do symulacji jednocześnie kilku "graczy" na stanowiska dyżurnych ruchu, więc dobrze by było, żeby sobie w paradę nie włazili :D
-
W obecnym rozwiązaniu SCS obsługuje jedno stanowisko operatorskie, więc włączenie kilku dyżurnych ruchu będzie polegać na uruchomieniu kilku niezależnych instancji SCS. Każda oczywiście może mieć własny plik .anp.
Z tym, że Maszyna wymienia komunikaty z jednym zewnętrznym programem. Dla uruchomienia kilku SCS trzeba by dodać do tego prosty serwer uruchamiany wraz z Maszyną, który będzie wymieniał z nią komunikaty WM_COPYDATA i przekazywał je do poszczególnych klientów dyżurnych ruchu np. przez TCP/IP. Rozwiązanie obecnie możliwe i proste do zrobienia, ale będzie miało charakter prowizoryczny - zakłada tylko jedną maszynę z Maszyną, docelowo trzeba by pomyśleć jak w to włączyć innych maszynistów. Ale to już po stronie exe Maszyny.
-
Właśnie dlatego chciałem użyć ZMQ, gdyż można zrobić wtedy prostego hub-a rozsyłającego komunikaty po całej sieci podłączonych klientów i serwerów. Można też użyć jednej z instancji jako exe jako taki hub. W każdym bądź razie w takim układzie i tak koniec końców przy multiplayerze kończymy z TCP, a lokalnie można uruchamiać 3 exeki lub za pomocą zmiennej ustawiać w jakiej konfiguracji uruchamiamy daną sesję.
Jeszcze jest inna kwestia, że taki hub może nam służyć też jako miejsce rozsyłania samego pliku scenerii i scenariusza tak aby wszyscy na pewno mieli tą samą wersję. Mam na myśli same pliki tekstowe.
Myślałeś o tym, żeby rozbić to na wątki na takiej zasadzie, że każda stacja ma własny plik anp na własnym wątku? To ułatwia ewentualne włączenie się do sesji w trakcie jej trwania.
-
Przy założeniu, że dyżurny może włączyć/wyłączyć się z sesji sprawa się trochę komplikuje, wielowątkowość ANP to przy tym mniejszy problem. SCS po uruchomieniu zakłada, że wszystkie urządzenia srk (oprócz odcinków, których status jest przysyłany po starcie) znajdują się w stanie zasadniczym, głównie dotyczy to stanów związanych z realizacją przebiegów (utwierdzone odcinki, zamknięte zwrotnice, podane sygnały).
Możliwość włączania/wyłączania się z trwającej sesji wymagać będzie przechowywania tych stanów na serwerze (w zasadzie na żywo, żeby przypadkowe rozłączenie nie spowodowało ich utraty), realizacji zależności i sterowania przez serwer w czasie, gdy stacja jest bez obsady oraz pobrania stanów przy objęciu sterowania.
W zasadzie w tym przypadku aplikacja sterująca ruchem powinna działać na serwerze, najlepiej pod nadzorem jednego z użytkowników - "dyspozytora sesji", z możliwością objęcia sterowania przez klienta dyżurnego ruchu. Powinna być przy tym możliwość przekazywania uprawnień do sterowania poszczególnymi stacjami, tak aby jeden dyżurny mógł objąć jednocześnie dwie lub więcej stacji na jednym kliencie. Na razie nie przymierzałem się do takiego rozwiązania, zależnie od ilości rzeczy które chcemy osiągnąć będzie to dostosowanie SCS-1 lub stworzenie czegoś od nowa. Dobrze byłoby też przewidzieć możliwość użycia w sesji symulacji innych typów urządzeń, np. przekaźnikowych.
Dla porównania w TD2 zastosowane zostało inne podejście, w którym stacja nie może działać bez zalogowanego dyżurnego ruchu, przy włączeniu do sesji startuje pusta i w stanie zasadniczym, a przy rozłączeniu znika z sesji (razem z maszynistami) - tu SCS może pracować lokalnie, bez zapisywania stanów. Nie polecam jednak tego rozwiązania do Maszyny.
-
Przy założeniu, że mamy hub pośredniczący to jest to dobre miejsce do przechowywania stanów sesji. To można używać niezależnie czy jest to uruchomione tylko lokalnie czy także globalnie (przez sieć). Masz pewność, że dopóki hub się nie wywróci będziesz miał stan w miarę na żywo. Jeśli SCS miałby pracować jako część wykonawcza scenariusza to i tak musisz mieć automatyczne prowadzenie ruchu, czy to w SCS czy w warstwie wyższej. O tym właśnie piszę wcześniej. Może troszkę nie zrozumieliśmy się odnośnie tej kwestii.
-
Przetwarzanie poleceń ANP z kilku oddzielnych plików jest do zrobienia, dla objęcia ręcznego sterowania wybraną stacją myślałem też o możliwości wyłączenia ANP dla danej stacji.
Trzeba by się jednak zastanowić na czym ma polegać włączenie się dyżurnego ruchu do sesji i z czym warstwa nadrzędna zarządzająca ruchem miałaby się komunikować. Można trzymać stany w hubie, ale musi być zapewniona jeszcze ciągłość sterowania po rozłączeniu się dyżurnego ruchu - działanie srk nie może być zawieszone do czasu aż ktoś obejmie sterowanie (z uwagi na ruch składów po parunastu sekundach stany elementów przebiegów staną się nieaktualne względem sytuacji na gruncie), chyba że wtedy cała symulacja się zatrzymie i będzie czekać na połączenie brakującego dyżurnego. Stąd wydaje mi się, że najlepiej będzie SCS (lub jego odpowiednik) uruchamiać na serwerze, z możliwością objęcia sterowania lokalnie przez klienta, przy czym proces sterowania nadal będzie realizowany na serwerze - klient dyżurnego ruchu będzie jedynie terminalem do wprowadzania poleceń i zobrazowania stanu. Warstwa nadrzędna wtedy również pracuje na serwerze.
-
No tak, wtedy serwer jest jednocześnie hub-em oraz zajmuje się wykonastwem poleceń. Każdy posterunek ruchu ma swojego klienta, jeśli nie ma człowieka to wtedy uruchamiany jest klient AI.
-
Jedno mam pytanie. Czy w MaSzynie są zaimplementowane blokady liniowe i automatyka?
-
Nie ma nic. Dlatego chciałbym wykorzystać soft Paula. Po co pisać drugi raz to samo.
-
Pytanie brzmi, czy zewnętrzny program powinien kontrolować w pełni wszystko w MaSzynie czy powinien np przejmować kontrolę nad blokadą (tak jak to działa w rzeczywistości) w celu wypuszczenia jakiegoś pociągu? Wtedy AI lub użytkownik w LCS "pyta" czy są warunki do wypuszczenia pociągu ze stacji a reszta już po stronie automatu.
-
To co na gruncie dzieje się automatycznie i samoczynnie powinno zostać w MaSzynie (planowo puścić przez LD), a na zewnątrz wyprowadzić tylko interakcje.
-
Nie ma nic. Dlatego chciałbym wykorzystać soft Paula. Po co pisać drugi raz to samo.
Na pewno przyspieszyłoby to prace. Pytanie czy będzie to dobre rozwiązanie na dłuższą metę? Nie chciałbym, żeby okazało się, że potrzebuje włączyć SRS żeby pojeździć na maszynie ;)
El Mecánico:
Czyli tak: ustawianie się semaforów powinno być w MaSzynie, przebiegi i uzależnienia też.
Zmiana zwrotnic i podawanie sygnałów zezwalających ląduje po stronie kontrolera (zewnętrzny lub wbudowany w maszynę).
Pokrótce: mam skład na torze 1 na stacji A. Odjazd o godzinie 12:00 zapisany jest w planie. O godzinie 12:00 świeci się wyjazd (w zależności od następnych sygnalizacji czy układu przebiegu). Po minięciu Semafora wyjazdowego zapala się na nim STÓJ. Dojeżdżam do stacji B. W planie wjazd mam podany o godzinie 12:30 lub jakiś ivent z uzależnieniami. W planie wjeżdżam na tor 3 i taki dostaję przebieg. Sygnał na semaforze wjazdowym zależy od przebiegu. AI lub użytkownik wysyła tylko komendę "podaj wjazd" lub "podaj wyjazd". Dobrze kminię?
-
Eee, nie do końca. Ktoś musi jeszcze wajchy poustawiać, i to też powinno iść na karb kontrolera (chyba że robimy dziś za "przekaźnik" na ręcznych wajchach :D).
-
Nie mam pojęcia o czym piszesz :)
-
Jeśli chodzi o sterowanie za pomocą urządzeń przekaźnikowych i pulpitu kostkowego, to polecam pobawić się trochę symulatorem ISDR, na początek np. stacją Testowo: http://www.symulator.isdr.pl/download.php Można tam zobaczyć co i jak obsługuje dyżurny, a co i jak wykonuje się automatycznie. Do MaSzyny trzeba by też dodać odcinkowe sprawdzanie zajętości torów, m.in. do wygaszania semaforów, co obecnie jest realizowane eventami oraz do innych uzależnień związanych z bezpieczeństwem.
-
Odcinki izolowane są obsługiwane i są wykorzystywane w SCS do sygnalizowania zajętości, a wygaszanie semaforów to klasyczy event _s1, mozna by albo zostawić klasyczy event albo wg zajętości toru za semaforem. Czyli do sterowania MaSzyny z SCS'a wystarczy przerobić scenerie (dodanie odcinków izolowanych i pozbycie się większosci klasycznych eventów, a zamiast tego eventy które będą ewentualnie przesyłanie informacje do programu) oraz napisać program które będzie sterowało i konstrolowało co się dzieje na scenerii i w SCS i będzie umiało tym sterować (czy to ogólne zasady sterowania czy konkretne dla danego sceneriusza. A sam SCS potrzebuje przebieg od semafora do semafora/punktu końcowego, a sam sobie ustawi rozjazdy.
Jeśli chodzi o sterowanie za pomocą urządzeń przekaźnikowych i pulpitu kostkowego, to polecam pobawić się trochę symulatorem ISDR, na początek
Pulpit kostkowy mógłby byc fajnym dodatkiem, ale do samego sterowania SCS naprawdę daje radę, tylko potrzebny automat czy wirtualny dyżurny który będzie nim sterował. Pulpit kostkowy moze by się przydał na jakieś oficjane pokazy czy coś, więc mozna o tym też pomysleć ale jak na razie SCS chyba sam w sobie jest bardziej potrzebny.
-
W sumie to na razie nie jest ważne czy będzie sterowaniem SCS czy pulpitem bo tak czy siak potrzebny jest jakiś interfejs do wymiany sensownych danych. Jeden interfejs można wykorzystać do komunikacji z każdym programem ;) Zrobić trzeba sprawną komunikację z SCS a w przyszłości może uda się podpiąć pulpit kostkowy do SCS-a albo bezpośrednio
-
Pulpit kostkowy mógłby byc fajnym dodatkiem, ale do samego sterowania SCS naprawdę daje radę, tylko potrzebny automat czy wirtualny dyżurny który będzie nim sterował. Pulpit kostkowy moze by się przydał na jakieś oficjane pokazy czy coś, więc mozna o tym też pomysleć ale jak na razie SCS chyba sam w sobie jest bardziej potrzebny.
Miałem na myśli wygląd ekranu sterującego, który imitowałby pulpit kostkowy (jak w ISDR), czyli od razu trochę przyszłościowo w stronę multiplayera, kiedy będzie mogło być kilku dyżurnych obsługujących poszczególne stacje/posterunki. Chodzi mi o to, aby zostawić możliwość zrobienia takiego pulpitu dla poszczególnych stacji, żeby każdy dyżurny mógł sobie ew. wybrać, na jakim sprzęcie chce pracować - nowoczesny system komputerowy czy klimatyczny pulpit kostkowy (na ekranie). Podłączenie rzeczywistego pulpitu (czy to z prawdziwych elementów, czy wykonanego samodzielnie) to zupełnie inna kwestia (i nie ten temat) oraz przesyłanie odpowiednich danych przez UART do jakiegoś mikrokontrolera obsługującego wszystkie przyciski, szczeliny świetlne, powtarzacze itd., ale to już @maciek001 ma chyba opanowane... ;)
Edit:
Zrobić trzeba sprawną komunikację z SCS a w przyszłości może uda się podpiąć pulpit kostkowy do SCS-a albo bezpośrednio
Racja, to w pierwszej kolejności.
-
@miko22: W SCS-ie trzeba od razu mieć wszystkie stacje? ;) Osobiście wolałbym, żeby całość sterowania ruchem była zamknięta w maszynie a SCS miał możliwość sterowania ale jestem świadom, że to bardzo dużo roboty.
Swoją drogą: ciekaw jestem czy można zrobić nakładkę graficzną na SCS żeby sterować jak kostkowym :)
-
Z SCS jest jak z Rainsted. Nie ma launchera w exe więc korzystamy z dobrego zewnętrznego softu. Paul ma pomysł na sterowanie scenariuszem więc to jest lepsza droga niż zabawa w implementację logiki układania przebiegów, która już została zaimplementowana i przetestowana.
Dla mnie nie jest problemem, że automatycznie odpalasz na kompie drugi proces, który komunikuje się z tym głównym. Może być nawet bezokienny jeśli komuś to będzie wadziło.
-
Jeśli taki SCS miałby możliwość odczytu i zapisu komórek pamięci, to zajętości można zostawić na eventach, tam gdzie są, zamieniając je tylko na ustawienie arbitralnej wartości dla true (tor wolny) lub false (tor zajęty), albowiem fachowo mówi się o niezajętości toru.
-
Jeśli taki SCS miałby możliwość odczytu i zapisu komórek pamięci, to zajętości można zostawić na eventach
Hmm ale po co zostawaiać komórki pamięci, skoro SCS w samych swoim pulpicie pokazuje zajętości torów oraz blokuje już ustawiony przebieg, tak że już inne sprzeczny go nie ustawi?
Chyba że chodzi o rozwiązanie tymczasowe na istniejących sceneriach, ale tak czy tak w torach mają być odcinki izolowane zajętości dla SCS'a więc tak czy tak zajętośc pokaże, pomijając używanie komórek pamięci.
-
@miko22: W SCS-ie trzeba od razu mieć wszystkie stacje?
Jeśli uda się usunąć z odpowiednich plików eventy sterujące tylko jedną stacją, to pewnie można by sterować na początek tylko tą jedną stacją, a reszta mogłaby działać po staremu - tak myślę. Problemem może być właśnie usunięcie eventów tylko dla wybranej stacji. Do usuwania wszystkich z całej scenerii jest z MaSzyną dołączony program "EventoUsuwacz_v1.0" w folderze "programy_na_potrzeby_symulatora", a w przypadku pojedynczej stacji pewnie trzeba by to zrobić ręcznie. Nigdy się w to nie zagłębiałem, próbowałem tylko kiedyś sił z napisaniem scenariusza. A link do ISDR-a podałem głównie po to, żebyś sobie zobaczył, jak takie urządzenia (akurat w tym przypadku przekaźnikowe) działają w rzeczywistości - nastawianie przebiegów, ich utwierdzanie, realizacja, ręczne rozwiązywanie i wygaszanie sygnałów, czasami dodatkowe zależności dla sąsiednich rozjazdów, działanie i obsługa poszczególnych rodzajów blokad liniowych itd.
-
Czyli tak: ustawianie się semaforów powinno być w MaSzynie, przebiegi i uzależnienia też.
Główną ideą SCS jest przeniesienie logiki sterowania na zewnątrz, z uwagi na to że implementacja przebiegów i uzależnień w eventach jest bardzo utrudniona - życzę powodzenia w odwzorowaniu sterowania dużą stacją zgodnie z tablicą zależności, z wszystkimi wykluczeniami i ciągłą kontrolą stanu elementów. To co było dotychczas na eventach to raczej prowizorka dla wybranych przebiegów, choć z punktu widzenia maszynisty działała - przynajmniej dopóki dwa pociągi nie trafiły z jakiegoś bzdurnego powodu na jeden tor, uniemożliwiając kontynuację scenariusza.
Oczywiście wszystko zależy od twórcy scenerii, SCS nie jest "jedynym słusznym" rozwiązaniem - można też zrobić tak, że eventy wykonawcze będą dostosowane do SCS, ale wariantowo można będzie włączyć scenerię z dołączonym plikiem eventów realizujących logikę, i w takim wariancie SCS nie będzie używany.
Odcinki izolowane są obsługiwane i są wykorzystywane w SCS do sygnalizowania zajętości, a wygaszanie semaforów to klasyczy event _s1, mozna by albo zostawić klasyczy event albo wg zajętości toru za semaforem.
Nie tylko do sygnalizowania zajętości, przy wyświetlaniu sygnału kontrolowana jest niezajętość całej drogi przebiegu, nie tylko odcinka za semaforem. Ponadto zajętość jest konieczna do śledzenia przemieszczania się pociągów (przesuwanie numerów), bez którego nie zadziała pełna automatyka. Event wygaszający może się przydać jako zabezpieczenie na wypadek niespodziewanego rozłączenia, kiedy SCS semafora nie wygasi (ale przy rozłączeniu już cała symulacja zacznie się sypać z powodu utraty części informacji).
W sumie to na razie nie jest ważne czy będzie sterowaniem SCS czy pulpitem bo tak czy siak potrzebny jest jakiś interfejs do wymiany sensownych danych. Jeden interfejs można wykorzystać do komunikacji z każdym programem ;) Zrobić trzeba sprawną komunikację z SCS a w przyszłości może uda się podpiąć pulpit kostkowy do SCS-a albo bezpośrednio
Interfejs wymiany danych używający WM_COPYDATA i eventów jest już opracowany i działa. Nie jest to interfejs specyficzny dla SCS, może być wykorzystany w innych aplikacjach sterujących, testowałem to wstępnie z urządzeniami E i pulpitem kostkowym, nie było problemów. Pytanie czy zostanie taki interfejs sterowania (przynajmniej "prowizorycznie"), czy zmienione zostanie medium transmisyjne (np. na TCP/IP, co było omawiane - można dostosować SCS), czy w ogóle wszystko zostanie zmienione, łącznie z zakresem i formatem przesyłanych danych (o ile ma to jakiś sens, skoro zostało już zrobione; jak na razie uwag do mojego rozwiązania nie ma). W roboczych exe++ zdaje się WM_COPYDATA aktualnie nie chodzi.
Pozostaje jeszcze kwestia interfejsu (głównie blokady liniowe) pomiędzy dwoma procesami SCS, lub ogólnie między aplikacjami sterującymi. Mam na to pewne pomysły, choć w Maszynie chyba nie będzie to w najbliższym czasie potrzebne.
W SCS-ie trzeba od razu mieć wszystkie stacje?
SCS będzie mógł obsługiwać wybrane stacje, reszta może działać po staremu na eventach lub może jej nie być - np. uruchamiamy scenerię w wariancie tylko z jednym odcinkiem, pomijając wczytywanie drugiego odcinka, który nie będzie potrzebny w danym scenariuszu. W przypadku sterowania częściowo z SCS i częściowo po staremu może być problem z powiązaniem i przekazywaniem informacji (np. numery pociągów, wykluczenia jazd na szlakach) między jednym i drugim rozwiązaniem - nie jest to jednak dużym problemem jeżeli podział jest tymczasowy, z uwagi na stopniowe dostosowywanie scenerii do sterowania z zewnątrz.
Jeśli taki SCS miałby możliwość odczytu i zapisu komórek pamięci, to zajętości można zostawić na eventach, tam gdzie są, zamieniając je tylko na ustawienie arbitralnej wartości dla true (tor wolny) lub false (tor zajęty), albowiem fachowo mówi się o niezajętości toru.
Chyba jednak prościej przypisać odcinki izolowane niż kombinować z eventami. Pierwsze prototypy SCS powstały przed wprowadzeniem odcinków izolowanych, wykrywały zajętości właśnie eventami torów, działało to kiepsko (niby działało, do czasu aż na torze nie znalazły się dwa pociągi, albo jakiś skład się nie rozłączył, po czym zostawiona część znikała z toru). Odcinki izolowane zostały wprowadzone dla eliminacji problemów z eventami torów.
-
W roboczych exe++ zdaje się WM_COPYDATA aktualnie nie chodzi.
W tym momencie chodzi teoretycznie, tzn jest w kodzie ale nie mam jak przetestowac funkcjonalnosci. Musialby to sprawdzic ktos inny. A docelowo i tak zapewne sugerowana przesiadka na tcp/ip bedzie sensowna, w ramach pracy na innych systemach niz windows itp.
edit: natomiast co do samych ewentualnych zmian w sterowaniu, zakladam ze jest to cos, co sobie opracuje Firleju w ramach ewentualnych zmian tego, jak zorganizowana jest symulacja itp (jako ze jest to dziedzina ktora sie zajmowal, wiec chyba najlepiej wie co tam bedzie sensowne)
-
Starter Ra ma przecież przycisk Multiplayer i tam jest komunikacja przez WM, trzeba tylko w eu07.ini mieć multiplayer ustawione na 1.
-
Sprawdziłem eu07++170301, SCS nie dostaje od niego komunikatów. Stare exe (sprzed konwersji) przy identycznej konfiguracji współpracuje prawidłowo.
-
nie działa bo nazwa klasy jest chyba zła. mógłbyś sprawdzić czy działa przy klasie GLFW30?
-
Starter Ra ma przecież przycisk Multiplayer i tam jest komunikacja przez WM, trzeba tylko w eu07.ini mieć multiplayer ustawione na 1.
Jest to byc moze proste gdy sie wie jak to ustrojstwo uruchomic, ale po wyszukaniu czegos co wyglada na instrukcje (http://eu07.pl/forum/index.php/topic,26661.0.html) moje proby zakonczyly sie na punkcie
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
i paragraf tekstu w ktorym moze rozezna sie jakis doswiadczony trasopisarz, ale na pewno nie ja. paczka calosciowa nie ma zadnych gotowych plikow .rsf, a o sensownym debugowaniu na linii 61 mozna z gory zapomniec. Bez pliku .rsf przycisk "uruchom serwer" nie robi nic. Jesli ktos moglby zrobic plik .rsf dla TD to byloby super. Sprobuje jeszcze, czy uda mi sie moze uruchomic SCS, chociaz na sukces specjalnie sie nie nastawiam :s
edit: ok, po uruchomieniu scenerii anp_test.scs komunikacja nie nastepuje, niewazne w jakiej kolejnosci uruchomie programy. Podejrzewam ze Milek ma racje, i komunikaty z SCS nie docieraja, bo zmienila sie nazwa klasy okna symulatora.
-
do licha z tym copydata, robię socketa tcp
widzę to tak: SCS tworzy serwer tcp, eu07 łączy się pod adres wskazany w ini
przesyłane komunikaty są jak obecne DaneRozkaz, tylko po iSygn jeszcze dodać uint32 z długością payloadu (czyli bez iSygn, długości i iComm).
EDIT: wszystkie inty i floaty w big endian, inaczej niż obecnie. (we wszystkich protokołach jest raczej big endian)
może być, czy jakieś inne propozycje?
PS: ten SCS ma być szansę otwartoźródłowy czy nie?
-
Witam.
U mnie na najnowszej kompilacji exe C++ z SCS nie współpracuje. Teoretycznie według loga, symulator wysyła komunikaty. Sprawdziłem dla pewności na Next4, łączy się bez problemu.
Pozdrawiam.
-
nie działa bo nazwa klasy jest chyba zła. mógłbyś sprawdzić czy działa przy klasie GLFW30?
To było oparte o opisy okien, a nie nazwy klas - dlatego SCS po ustawieniu trybu WM_COPYDATA ustawia sobie opis TEU07SRK, i wyszukuje okna EU07. Niezbyt elegancko, ale przez buga w środowisku nie mogę zmienić deklarowanej nazwy klasy okna.
widzę to tak: SCS tworzy serwer tcp, eu07 łączy się pod adres wskazany w ini
przesyłane komunikaty są jak obecne DaneRozkaz, tylko po iSygn jeszcze dodać uint32 z długością payloadu (czyli bez iSygn, długości i iComm).
Może lepiej serwer w EU07, a SCS jako klient - żeby można było połączyć więcej niż jedną aplikację z EU07, np. dwa stanowiska SCS, różne systemy sterowania dla różnych stacji itp. Ogólnie dobrze byłoby wpasować to do jakiejś przyszłościowej koncepcji symulacji sieciowej z wieloma maszynistami.
wszystkie inty i floaty w big endian, inaczej niż obecnie. (we wszystkich protokołach jest raczej big endian)
Ja mam wszystko w little endian, razem ze standardowymi funkcjami zapisu/odczytu ze strumieni, EU07 ma jakoś inaczej? Musiałbym je odwracać (co w ostateczności nie jest skomplikowane, ale może się coś pomieszać).
PS: ten SCS ma być szansę otwartoźródłowy czy nie?
Nie za bardzo, a co byś potrzebował podejrzeć?
-
wyszukuje okna EU07. Niezbyt elegancko, ale przez buga w środowisku nie mogę zmienić deklarowanej nazwy klasy okna.
Nie bardzo rozumiem, w jaki sposob wyszukujesz okno EU07? Jesli funkcja FindWindow() to mozna w niej zadeklarowac nazwe wyszukiwanego okna lub jego klase. Sek w tym ze po przenosinach na glfw nazwa klasy okna EU07 zostala zmieniona na GLFW30. Wyszukiwanie po nazwie wydaje sie raczej malo precyzjne, bo ta zmienia sie zaleznie od prowadzonego pojazdu.
-
Sprawdziłem i faktycznie, SCS szuka nazwy klasy EU07, nie nazwy okna, natomiast w drugą stronę było szukanie nazwy okna - TEU07SRK. Mogę zmienić z EU07 na GLFW30, ale i tak SCS nie dostaje komunikatów od EU07.
-
Jesli to nie problem, czy mozesz dolaczyc tutaj wersje SCS, ktora komunikuje sie z klasa GLFW30? Moge wtedy sprawdzic czy jakiekolwiek komunikaty przychodza z SCS.
fake edit: wyglada na to, ze symulator probuje wysylac sygnaly do okna klasy "TEU07SRK", a nie o nazwie "TEU07SRK". Rozumiem, ze nie mozesz zmienic nazwy klasy, dam poprawke, zeby w przypadku porazki probowal znalezc tez okno o takiej nazwie, powinno pomoc. Albo mozliwosc definiowania nazwy klasy okna odbiorcy w .ini, jako prowizorka wystarczy
edit: a nie, probuje szukac i tak, i tak. przyjrze sie dokladniej, ale w miedzyczasie to exe i tak by sie przydalo ;)
-
Może lepiej serwer w EU07, a SCS jako klient - żeby można było połączyć więcej niż jedną aplikację z EU07, np. dwa stanowiska SCS, różne systemy sterowania dla różnych stacji itp. Ogólnie dobrze byłoby wpasować to do jakiejś przyszłościowej koncepcji symulacji sieciowej z wieloma maszynistami.
Właśnie ja myślałem że scs powinien być serwerem żeby można było w przyszłości podłączyć więcej symulatorów do jednej nastawni.
Ale jeżeli wchodzimy w takie połączenia multi-symulator - multi-nastawnia, to może faktycznie warto wykorzystać ZeroMQ, tak jak firleju proponował.
Jak już zmieniamy na coś porządniejszego to trzeba się też zastanowić czy dalej zostajemy na takiej serializacji adhoc w kodzie, czy może np. użyć protobuf3.
Ze źródłami mi chodzi o to, że jeżeli scs miałby być kiedyś wykorzystany jako zamiennik eventów przy tworzeniu scenerii, to imo raczej wymogiem jest żeby wszystkie komponenty dostarczane z maszyną były otwartoźródłowe. Dopiero co otworzone zostały źródła eu07 i są prace nad wieloplatformatyzacją kodu, więc wracanie do zamkniętych blobów to moim zdaniem krok wstecz.
-
Jesli to nie problem, czy mozesz dolaczyc tutaj wersje SCS, ktora komunikuje sie z klasa GLFW30? Moge wtedy sprawdzic czy jakiekolwiek komunikaty przychodza z SCS.
W załączniku. Teraz wysyła do GLFW30, ale nie wygląda na to żeby EU07 na to reagował. Przy czym SCS czeka na komunikat gotowości od EU07, i dopiero potem sam zaczyna wysyłać komunikaty, w pierwszej kolejności żądanie stanu odcinków. Dorobiony został przycisk ODBL udający zgłoszenie gotowości, po jego kliknięciu można przez kilkanaście sekund próbować coś wysyłać (aż SCS nie wykryje oszustwa i ponownie się nie zablokuje). Jak jest potrzeba, to przygotuję prosty program do testowania wysyłania komunikatów WM_COPYDATA bez takich kombinacji.
Właśnie ja myślałem że scs powinien być serwerem żeby można było w przyszłości podłączyć więcej symulatorów do jednej nastawni.
W takim razie w miejsce SCS w tej koncepcji potrzebny jest serwer, do którego podłączać będą się klienci: EU07, właściwy SCS i opcjonalnie inne programy. W takim układzie EU07 może być klientem TCP/IP. Nie wiem jak tu w przyszłości wcisnąć innych klientów EU07 dla multiplayera - całość wymaga dokładniejszego przemyślenia, chyba że traktujemy to rozwiązanie jako "tymczasowe".
Ze źródłami mi chodzi o to, że jeżeli scs miałby być kiedyś wykorzystany jako zamiennik eventów przy tworzeniu scenerii, to imo raczej wymogiem jest żeby wszystkie komponenty dostarczane z maszyną były otwartoźródłowe. Dopiero co otworzone zostały źródła eu07 i są prace nad wieloplatformatyzacją kodu, więc wracanie do zamkniętych blobów to moim zdaniem krok wstecz.
SCS nie jest elementem Maszyny, tylko oddzielnym projektem, łączy się z Maszyną dynamicznie. Niezależnie używany jest w TD2 oraz jednym komercyjnym projekcie. Nie wydaje mi się, żeby przez dostosowanie do Maszyny przechodziła na niego licencja kodu Maszyny. Chyba że to wymóg dla wszystkiego co włączane ma być do paczki z Maszyną - w takim razie SCS będzie musiał być udostępniony oddzielnie.
-
OK, chyba udalo mi sie przywrocic komunikacje, ale nie wiem czy na 100% -- programy lacza sie, stan zajetosci torow jest uaktualniany, i rozkazy takie jak ustawianie zwrotnic czy kontrola przejazdow dzialaja, ale kazda proba ustawienia przebiegu konczy sie komunikatem "Nie mozna ustawic przebiegu" bez proby wyslania komunikatu przez SCS. Byc moze robie tutaj cos zle.
Dolaczone uaktualnione exe, jesli mozesz, sprawdz czy bedziesz mial wiecej szczescia.
-
Odczytywanie zajętości i sterowanie poszczególnymi obiektami wskazuje że sama komunikacja jest ok. "Nie można ustawić przebiegu" oznacza raczej jakiś problem po stronie SCS, a nie w komunikacji, chyba że np. któreś odcinki błędnie wykazują zajętość.
Ale na razie chyba nie sprawdzę, załączone exe eu07++170304 wysypuje się po zakończeniu ładowania scenerii - "Nazwa modułu z błędem: ig4icd32.dll". Przesłać .dmp w wątku exe, czy to jakiś znany problem i coś pominąłem? Wersja eu07++170301.exe mi się uruchamiała.
-
Podeslij jesli mozesz, to sie raczej nie powinno zdarzyc, nie zmienialem w kodzie nic szczegolnego.
jesli google nie klamie, to ten .dll to sterownik graficzny dla kart intela :< jesli poprzednio uzywales 170301, to podejrzewam ze posypal sie na zmianie nieba na VBO ktore nastapilo w 170302, byc moze za stary na to jest.
-
Na Nvidi, odpalilem 1070304, bez zadnych problemow.
-
W eu07++170304b komunikacja działa prawidłowo (nie licząc sypania się przy niektórych eventach, o czym napisałem w wątku exe). Jeżeli nadal pojawiają się problemy z ustawianiem przebiegów, podaj więcej szczegółów (które przebiegi, log).
-
Trzeba delikatnie podsumować:
- W wizji Pawła każda instancja SCS steruje tylko jednym obiektem
- obiekt może być całą scenerią lub pojedynczymi stacjami, tak?
- w jaki sposób instancje SCS przekazują sobie informacje o kolejnych pociągach?
- czy jest sens uruchamiać więcej niż jedną instancję jeśli nie mamy multiplayera?
- może osobne scenerie dla muli i osobne dla single, wtedy wiele rzeczy by się upraszczało
- należy posiadać warstwę nadrzędną zlecającą SCS poszczególne kroki (tj obecnie połączenie dyspozytora z dyżurnym jak mniemam)
- aby to działało potrzebny jest opis senariusza (co jak sądzę jest w opracowaniu)
- aby móc zrobić docelowo miltiplayer potrzeby jest hub wymieniający dane, więc można to wykonać od razu
- w każdej opcji dobrze jest przenieść komunikację na TCP. Co do big/little indian może to robić hub, i tak będzie musiał być osobnym procesem / programem
-
- W wizji Pawła każda instancja SCS steruje tylko jednym obiektem
- obiekt może być całą scenerią lub pojedynczymi stacjami, tak?
Tak, instancja SCS steruje "tylko" pojedynczymi stacjami lub całą scenerią. Czym więcej miałby sterować?
Przewiduję ponadto możliwość zmiany zasięgu sterowania, np. wprowadzone są dane całej scenerii, a obejmowane jest sterowanie połową stacji. Druga połowa stacji może być sterowana czymś innym, albo może jej nie być (przy modułowej budowie scenerii z wybranych odcinków, czy tam komórek scenerii).
- w jaki sposób instancje SCS przekazują sobie informacje o kolejnych pociągach?
Tym zająłby się serwer trzymający topografię sieci, stan blokad i pip (numery pociągów), do którego logowały by się instancje SCS (albo inne aplikacje sterujące, np. pulpit kostkowy). Ale na razie to tylko koncepcja.
- czy jest sens uruchamiać więcej niż jedną instancję jeśli nie mamy multiplayera?
Niezbyt. Chyba że multiplayer typu kilku dyżurnych steruje jednym maszynistą...
- może osobne scenerie dla muli i osobne dla single, wtedy wiele rzeczy by się upraszczało
Raczej wspólne, a przynajmniej ze wspólnym opisem infrastruktury i otoczenia, różniące się ewentualnie jakimiś incami ze szczegółami sterowania. Nie powinno być ograniczeń zastosowania scenerii tylko offline, lub tylko w multiplayerze.
- należy posiadać warstwę nadrzędną zlecającą SCS poszczególne kroki (tj obecnie połączenie dyspozytora z dyżurnym jak mniemam)
- aby to działało potrzebny jest opis senariusza (co jak sądzę jest w opracowaniu)
Multiplayer z dyżurnymi nie wymaga warstwy nadrzędnej - dyżurni sami będą sterować. Gdy sterowanie ma być automatyczne, SCS potrzebuje planu przebiegów, będącego czymś w rodzaju opisu scenariusza (co, skąd, dokąd, kiedy ma pojechać), i to już działa. W razie potrzeby można dodać warstwę nadrzędną która będzie dynamicznie modyfikować plan przebiegów, czyli zarządzać ruchem.
- aby móc zrobić docelowo miltiplayer potrzeby jest hub wymieniający dane, więc można to wykonać od razu
- w każdej opcji dobrze jest przenieść komunikację na TCP. Co do big/little indian może to robić hub, i tak będzie musiał być osobnym procesem / programem
Z pewnością jakiś hub musi być, jeżeli w symulacji ma brać udział coś więcej niż jedna instancja EU07 i jedna SCS. Na potrzeby sterowania hub będzie przekazywał polecenia i meldunki stanów między EU07 i instancjami SCS/innych aplikacji sterujących. Na poziomie huba lub za hubem z mojej strony potrzebny będzie jeszcze jakiś serwer zajmujący się działaniem blokad i przekazywaniem informacji pomiędzy SCS/aplikacjami sterującymi, oraz być może dodatkowo zarządzający uprawnieniami do sterowania poszczególnych stacji przez poszczególne aplikacje nastawni, trzymający stany sterowania na wypadek wyłączenia się klienta nastawni. Otwarta pozostaje kwestia roli i zasad działania huba przy wielu instancjach EU07.
-
Jesli pojawi sie serwer tcp w exe, to mozna by pomyslec o czyms w stylu, mozliwosc uruchomienia exe w trybie 'master', do ktorego moga nastepnie podlaczac sie inne exe (niekoniecznie symulator, rowniez SCS itd) i rejestrowac sie jako a) kontroler okreslonego pojazdu b) zrodlo komunikatow/eventow dla obiektow (jak rowniez liste obiektow ktorych stanem jest zainteresowany, zeby nie pchac stanu calej trasy do kazdej stacji) I w takim ustawieniu 'master' przekazuje otrzymane sygnaly od zarejestrowanych klientow do pozostalych, a kazdy klient juz sobie we wlasnym zakresie liczy/wizualizuje symulacje. Idealnie synchronizowane to nie bedzie, bo wejda opoznienia sieci itp, wiec komunikacje trzeba bedzie troche poszerzyc, ale w praktyce bylby to calkiem funkcjonalny multiplayer.
-
Żeby nie dociążać exe takimi zadania lepiej mieć odrębny kawałek softu, który mógłby służyć też jako miejsce rozsyłania plików / scenerii (wtedy jest pewność, że wszyscy mają taką samą).
SCS dla całości czy dla stacji to jest kwestia czy opis scenariusza, w którym muszą być też zawarte polecenia dla pojazdów łatwiej będzie robić osobno dla każdej stacji czy dla pociągu czy może dla wszystkiego naraz.
-
Mojej "części serwerowej" SCS/sterowania nie ładowałbym na pewno do exe EU07, zwłaszcza że być może będzie też używana w TD2. To raczej będzie klient serwera EU07, obsługujący klientów nastawni, być może uruchamiany na tej samej maszynie co EU07.
Co do "scenariuszy" w SCS, raczej widzę to jako rozkłady jazdy poszczególnych pociągów, uzupełnione o dodatkowe polecenia, z których przez jakiś interfejs automatycznie będzie generowany plan przebiegów dla SCS. Rozdzielanie tego na osobne instrukcje dla każdej stacji będzie niezbyt wygodne.
-
Zerknijcie jak działa wersjonowanie scenerii u nas to troche wam będzie łatwiej. Każdorazowa edycja pliku .sc powoduje wygenerowanie sumy kontrolnej i załadowanie nowego pliku .sc na serwer w momencie uruchomenia trybu dyżurnego.
W ten sposób klienci podłączający się zawsze mają aktualną wersję scenerii bo pobierają ja z serwera.
-
Żeby nie dociążać exe takimi zadania lepiej mieć odrębny kawałek softu, który mógłby służyć też jako miejsce rozsyłania plików / scenerii (wtedy jest pewność, że wszyscy mają taką samą).
Sek w tym, ze ten odrebny kawalek i tak bedzie musial miec w zasadzie pelna funkcjonalnosc symulatora (oprocz moze strony wizualnej, dlatego m.in. wspominalem ze jednym z celow zmian powinno byc rozdzielenie symulacji od renderingu) wiec czy dolozy sie do exe pare klockow, czy tez dolozy sie symulator do tej samej pary klockow i nazwie sie to "odrebny kawalek softu", to i tak wyjdzie na to samo :) Ale w przypadku odrebnego softu dojdzie koniecznosc wprowadzania zmian do dwoch programow i utrzymywania tychze, zamiast tylko jednego... co chyba nie jest zbyt praktyczne.
-
Ty myślisz o czymś co liczy poruszanie się pojazdów, a ja myślę o czymś co przesyła policzone elementy na poszczególnych kompach do innych, żeby zwizualizować przemieszczenia jedynie. Druga wersja nie wymaga implementowania niczego oprócz odpowiedniego interfejsu TCP i ewentualnie sprawdzania czy wszystkie klienty mają uruchomioną tą samą wersję scenerii. Po co rozdzielać?
Wg mnie są tylko dwa tryby: pełny singiel, gdzie wszystko liczymy na exe a hub służy do komunikacji z jedną instancją SCS oraz pełny multi gdzie AI to może co najwyżej sterować scenariuszem ale nie ma składów AI.
-
Ty myślisz o czymś co liczy poruszanie się pojazdów, a ja myślę o czymś co przesyła policzone elementy na poszczególnych kompach do innych, żeby zwizualizować przemieszczenia jedynie. Druga wersja nie wymaga implementowania niczego oprócz odpowiedniego interfejsu TCP i ewentualnie sprawdzania czy wszystkie klienty mają uruchomioną tą samą wersję scenerii. Po co rozdzielać?
Wg mnie są tylko dwa tryby: pełny singiel, gdzie wszystko liczymy na exe a hub służy do komunikacji z jedną instancją SCS oraz pełny multi gdzie AI to może co najwyżej sterować scenariuszem ale nie ma składów AI.
To niezupelnie tak -- (niektorzy) klienci jak najbardziej moga sobie liczyc stan symulacji u siebie na podstawie przekazanych sygnalow, ale oprocz tego uwazam ze 'master' takze musi to robic, chocby dlatego ze symulacji nie policza sobie np stacje pod kontrola SCS, i ktos musi dla nich zdecydowac o zajetosci torow itp, i przekazac im te informacje. Biezacy stan calej trasy musi byc takze przekazany klientom ktorzy podlaczaja sie w trakcie sesji, i do tego celu trzeba go skads wziasc. No i wreszcie jest to raczej przydatne do zwyklej weryfikacji -- "nigdy nie wierz klientowi" to dosc podstawowa zasada dla aplikacji sieciowych, dlatego przyjmowac od nich informacje, jakie komendy wydaje sterujacy jak najbardziej, mozna, ale juz slepo przyjmowac dane w rodzaju "moj pociag jest teraz tutaj" to jest proszenie sie o klopoty, takie rzeczy serwer liczy u siebie i jesli klient ma inne zdanie, to rozstrzygniecie jest na 'korzysc' serwera, nie klienta.
Co do trybow natomiast, mysle ze tutaj jak najbardziej mozna laczyc AI i ludzi -- upraszczajac, z punktu widzenia symulacji nie ma roznicy, czy 'ludzki' kontroler pociagu siedzi przed klawiatura komputera ktory liczy ta symulacje, czy sterowanie odbywa sie poprzez wariant tej klasy zmieniony by otrzymywac instrukcje ze 'zdalnej' klawiatury, za posrednictwem tcp i serwera. Ani czy sklad zarzadzany przez AI zostaje przejety przez "lokalne F5", czy jego sieciowy odpowiednik? Odpada w ten sposob problem, ze wieksze scenariusze albo nie moga byc uzywane w trybie multiplayer dopoki nie znajdzie sie grupa kilku(nastu) osob chcacych jezdzic w tym samym czasie akurat po tej trasie, zeby obsadzic wszystkie zdefiniowane pociagi, albo sa okrawane ze wszystkich skladow oprocz tych, ktore obsadza operatorzy, i robi sie na nich zwyczajnie pusto gdy tych operatorow jest 2-3.
-
Trochę się chyba zagalopowaliśmy. Narazie chodzi o stworzenie architektury tylko dla singla bo nic więcej nie uda się zrobić w najbliższym czasie więcej. Jeśli założymy, ze całe AI loków ma być w przyszłości liczone na serwerze to w tej chwili to nie jest jakoś znacząco potrzebne do życia.
Chciałbym jednak ustalić jakąś architekturę, która docelowo będzie się nadawać do rozbudowy, ale nie zostanie zaimplementowana w pełni na obecnym etapie.
-
Ale w wersji multiplayer ready? ;)
-
Tak, w wersji multiplayer do wprowadzenia kiedyś w przyszłości.
-
Odkopując "trochę", fajnie by było gdyby SCS obsługiwał coraz częściej pojawiające się cuda w postaci rozsuniętych semaforów blokady lub miejscowo zagęszczonych jednokierunkowo odstępów, gdzie w drugim kierunku muszą być dwa odcinki osłaniane jednym semaforem. Bo obecnie przy próbie skonstruowania czegoś takiego, udać się uda żeby właściwie reagowały semafory podczas przejazdu przez oba odcinki, ale zrywa cały czas połączenie.
-
Jak tam temat SCS i MaSzyny? Ktoś pracuje nad tym? Jeżeli tak, to warto byłoby przemyśleć zastąpienie komunikacji międzyprocesorowej komunikacją TCP/IP. Ciekaw jestem co Wy o tym sądzicie.