- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: Winger w 14 Kwietnia 2009, 00:54:45
-
Mam pewien pomysł związany z usprawnieniami o których się w tym wątku pisze, ale chcę kilka rzeczy przetestować zanim wyjaśnię o co chodzi (zajmie mi to ok. tygodnia).
Tak więc 'stay tuned' ;)
Wątek ten został wydzielony z 'Teamspeak MaSzynowców...'
Winger
-
Albo każdy mechu ma swojego nastawniczego co go podgląda...
Na trasie jest niejedna nastawnia. Więc w sumie... pod kontrolą jednego człowieka było by nie więcej, jak 3 ludzi szacuję. Ale jak pamiętam, to VNC ciął już mi przy 2 podglądanych kompach :P
No, ale... Zobaczymy, co szykuje Winger, I'm tuned ;-)
-
No w sumie by musiał mieć podgląd na wszystkich maszynistów...
Nie musiał by. Dyżurny potrzebuje informacji na jakim torze znajduje się dany pociąg, a nie widoku z kabiny, który mu nic nie powie jeżeli nie zna perfekcyjnie trasy, zresztą może się łatwo pomylić. Można o wiele prościej i realistyczniej: maszyniści dojeżdżając do posterunków, wjeżdżając/wyjeżdżając itp. zgłaszają się do dyżurnego ruchu, a dyżurny wydaje pozwolenia na wjazd/wyjazd itp. Maszyniści układają sobie przebiegi według poleceń dyżurnego ruchu, a dyżurny aktualizuje sobie obraz sytuacji ruchowej według meldunków (nanosi numery pociągów na plan układu torowego w kontrolowanym okręgu przy pomocy jakiegoś prostego programu, ew. kartki, gumki i ołówka).
W podobny sposób prowadzony jest ruch na odcinku Szczecinek - Słupsk, tyle że przebiegi nastawiane są nie przez maszynistów a automatykę (np. przebieg wjazdowy nastawi się sam, ale maszynista może wjechać dopiero po otrzymaniu pozwolenia), tak samo automatycznie realizowane jest śledzenie biegu pociągów przy pomocy czujników torowych, nie mniej jednak maszyniści mają obowiązek zgłaszać wjazd/wyjazd z mijanek (http://www.kontrakt-bhp.com.pl/paul/kolej/srk_kapsch.php)
-
Mam taki wizjonersko nierealny pomysł: wygenerować plik graficzny (ot taki obraz jak generuje STV) umieścić go na serwerze. Wysyłać z exe'ka (układ X, Z [jeśli dobrze pamiętam Z w symku to nie jest wysokość ale jeśli się mylę proszę to zweryfikować]) dane o pozycji lokomotyw i umieszczać je na wygenerowanym wcześniej obrazie jako dynamicznie przesuwającą się kropkę (coś jak w Hard Truck'u). Dynamika to dla mnie aktualizacja co 30 sekund. Nie wiem na ile to możliwe ale wydaje mi się, iż Ajax by się spisał.
-
Same kropki nic Ci nie dadzą :] Poza tym antywstrząs powoduje, że pozycja to max 10km od środka (0;0), więc wtedy dopiero się będzie kaszanić :]
-
Ale na razie, żeby się dyżurny/dyspozytor nie nudził, to tak jak mówi @Paul, przy wyjeździe ze stacji na odcinek pomiędzy tą a następną (czyli prawie z każdej stacji) można pytać go o pozwolenie.
Na razie można tak, dopóki @Winger nie pochwali się, co testuje.
Mijanki też są na niektórych trasach.
-
Z tym można sobie poradzić, wysyłając przez sieć informacje o zajętości lub zwolnieniu toru. W najprostszym przypadku, przypisać eventy do torów i wysyłać ich nazwy. Żeby nie musieć wysyłać wszystkich, można by zdefiniować nowy rodzaj eventów, albo wysyłać tylko te o specyficznych nazwach, np. zaczynających się od znaku podkreślenia "_". Jakby jeszcze była możliwość wywoływania eventów z zewnątrz, to już byłoby takie minimum multiplayera.
-
Jakby jeszcze była możliwość wywoływania eventów z zewnątrz, to już byłoby takie minimum multiplayera.
No więc mogę zdradzić iż mam już wersję która przyjmuje z zewnątrz uruchamianie eventów (oparte na kodzie SPKS by youBy).
Pracuję obecnie nad prostą aplikacją serwerową i kliencką.
W eu07.ini jest nowy parametr, 'multiplayer', jeśli jest włączony to MaSzyna oczekuje połączeń TCP na konkretnym porcie i uruchamia eventy na podstawie komend wysyłanych z osobnej aplikacji (najlepiej odpalonej na tym samym kompie) która to znowu komunikuje się z zewnętrznym serwerem wysyłającym nazwy eventów do odpalenia. Aplikacja ta (działająca równolegle z MaSzyną) jednocześnie wysyła co kilka sekund obecną pozycję prowadzonego pojazdu do serwera, który przekazuje dane pozostałym klientom. U pozostałych klientów składy prowadzone przez innych userów będą co kilka sekund 'przeskakiwały' do aktualnej pozycji, płynnego ruchu tych pojazdów raczej nie będzie.
Całość traktuję w ramach testów różnych koncepcji multiplayerowych na potrzeby SPT; zmiany w kodzie źródłowym są minimalne.
Podejrzewam że za jakiś tydzień będzie można coś przetestować publicznie; początkowo główna aplikacja serwerowa będzie pod Windowsa i będzie jednocześnie 'konsolą sterowniczą' kontrolerów/dyspozytorów, docelowo chcę zrobić serwer działający non stop na eu07.pl (w ramach upraktyczniania świeżo nabytej wiedzy z C++ ;).
-
No to jakby robisz coś, co ja nazwałem Serwerem Ruchu.
Jakby już zadziałała komunikacja, to można pobawić się w podział scenerii na komórki. Wtedy centralna aplikacja serwera będzie miała w pamięci całą "wielką" sieć połączeń, a klienci (użytkownicy) będą mogli sobie wczytać tylko te fragmenty trasy, przez które przejadą, z odpowiednio wstawionymi i uruchamianymi pozostałymi składami. Da to również możliwość zakończenia symulacji po ukończeniu wczytanego fragmentu trasy i załadowania kolejnego... A inni będą to widzieć jako pociąg zatrzymany na S1.
-
Największy bum na TS'a już przeszedł...
-
Wszyscy pewnie czekają na cudeńko od Wingera ;-)
-
No to w przyszłym tygodniu powinniśmy je dostać.
Będzie to, można powiedzieć, przełom w MaSzynie - W końcu namiastka multiplayera.
-
Nie miałem ostatnio czasu, by siąść w nastawni, ale w ten weekend już rezerwuję sobie pare godzin po osiemnastej ;-) A opublikowanie wspomnianego dodatku na pewno doda zainteresowanych choćby z samej ciekawości. Ktoś pewnie zostanie na dłużej...
-
Istnieje już aplikacja klienta i serwer, pierwsze testy już wykonałem. Można zdalnie sterować zwrotnicami i semaforami. Wczoraj próbowaliśmy to przetestować w kilka osób, ale były z tym problemy, aplikacja kliencka nie działała poprawnie i muszę to i owo przepisać. Będę też próbował coś zrobić z ruchem składów prowadzonych przez innych userów, gdyż obecnie składy te co kilka sekund 'przeskakują' w obecną pozycję, spróbuję zrobić coś co sprawi iż będą się trochę płynniej poruszać - ale ponieważ ich prędkość będzie z góry ustalana na pewną wartość składy dalej będą skakać. Nię będą po prostu tego robić w bezruchu (o ile uda mi się to zrobić :)
Jest też prehistoryczne UI dla dyspozytora - pokazują się dwie tabelki, jedna ze zwrotnicami, druga z semaforami. Wystarczy zaznaczyć w tabelce dany wpis i odpalić prawym przyciskiem myszy menu kontekstowe; dla zwrotnic ukaże nam się wybór pozycji zwrotnicy (jazda prosto / w bok), dla semaforów lista dostępnych sygnałów do wyświetlenia, pobierana z pliku .inc danego semafora. Tabelka pokaże nam też ostatnią komendę wysłaną do danego obiektu (jak na załączonym obrazku widać - bardzo prymitywnie).
Jak testy pójdą sprawnie to przekażę specyfikację/kod klienta Ra - jeśli zechce to zintegruje klienta do swojego startera, i podejrzewam iż jego mapy scenerii generowanej przez starter można by było użyć do sterowania scenerią i sprawdzania stanu infrastruktury na bieżąco, albowiem na starcie dyspozytor będzie się musiał wykazać dobrą pamięcią i zdolnością szybkiego robienia notatek ;)
Dyspozytor będzie też oczywiście mógł wszystko widziec w swoim symulatorze, dlatego też dodam do pliku scenerii możliwość zdefiniowania do 10 pozycji do których będzie można 'przeskakiwać' w trybie freefly za pomocą kombinacji shift+cyfra (uruchamianie eventów tą kombinacją jest wyłączone w trybie multiplayer - tryb ten ustawia się za pomocą wpisu 'multiplayer yes/no' w eu07.ini).
Testy są/będą przeprowadzane na scenerii Krzyżowa 2, dobrze więc radzę by każdy kto będzie chciał wziąść udział w testach publicznych upewnił się iż sceneria ta działa.
Testy publiczne rozpoczną się kiedy będę miał pewność iż klient nie będzie wysypywał co drugiej osobie systemu %)
-
Jest też prehistoryczne UI dla dyspozytora - pokazują się dwie tabelki, jedna ze zwrotnicami, druga z semaforami. Wystarczy zaznaczyć w tabelce dany wpis i odpalić prawym przyciskiem myszy menu kontekstowe; dla zwrotnic ukaże nam się wybór pozycji zwrotnicy (jazda prosto / w bok), dla semaforów lista dostępnych sygnałów do wyświetlenia, pobierana z pliku .inc danego semafora. Tabelka pokaże nam też ostatnią komendę wysłaną do danego obiektu (jak na załączonym obrazku widać - bardzo prymitywnie).
Czy możliwa jest zmiana tego mechanizmu sterowania? Myślę, że dużo łatwiej byłoby napisać eventy wszystkich możliwych przebiegów i odpalać je jednym przyciskiem. Wtedy wystarczy, że dyżurny ma przed oczami schemat stacji i odpowiednie przycisk którymi ustawia wjazd/wyjazd na poszczególne tory. Kontrola zajętości torów ołówkiem na kartce, ewentualnie jakieś eventy warunkowe uniemożliwiające podanie wjazdu na zajęty tor.
-
Zaleznosci prawdopodobnie bedzie mozna realizowac za pomoca zewnetrzenego programu. Symek bedzie tylko wykonywal eventy i zwracal 'stan' urzadzen.
-
Czy możliwa jest zmiana tego mechanizmu sterowania? Myślę, że dużo łatwiej byłoby napisać eventy wszystkich możliwych przebiegów i odpalać je jednym przyciskiem. Wtedy wystarczy, że dyżurny ma przed oczami schemat stacji i odpowiednie przycisk którymi ustawia wjazd/wyjazd na poszczególne tory. Kontrola zajętości torów ołówkiem na kartce, ewentualnie jakieś eventy warunkowe uniemożliwiające podanie wjazdu na zajęty tor.
Nie sądzę by zdefiniowane wszystkich możliwych przebiegów i wariacji w scenerii było takie łatwe, byłoby takich eventów dziesiątki. Eventy warunkowe - to też trudne, bo tutaj trzeba by pełnej syncrhonizacji pomiędzy klientami, poza tym założenie tego prostego multiplayera jest takie że jesli dyspozytor dany event odpala to wie co robi i zostanie to u wszystkich uruchomione bez sprawdzania jakichkolwiek warunków. Wprowadzę jakąś możliwość generowania własnych skryptów będących zbiorami eventów, będzie więc sobie można tworzyć przebiegi samemu i odpalać je później paroma kliknięciami (zamiast odpalania poszczególnych pojedyńczych eventów). Takie pre-definiowane przebiegi będą zapisywane jako pliki .xml, będzie więc można je udostępniać innym.
Jeśli eventy będą zdefiniowane w scenerii to oczywiście nie ma problemu z ich odpaleniem, jest okienko w którym można wpisać po prostu nazwę eventa i jeśli takowy u kogoś istnieje to zostanie odpalony. Problem polega jednak na tym, że UI dyspozytora nie będzie wtedy znało aktualnego stanu elementów infrastruktury (stan każdej zwrotnicy/semafora), a znajomość tego stanu będzie chyba potrzebna dyspozytorowi (a na pewno bardziej zaawansowanym palikacjom które ktoś może stworzyć na potrzeby mp). Z tego też powodu z testowej scenerii usunąłem wszystkie eventy generowane w torach oprócz SBL, zamykania/otwierania przejazdów i wygaszania semaforów (S1). I tak też trzeba będzie zmodyfikować każdą scenerię na której będzie się chciało jeździć w mp.
-
Skoro będzie możliwość predefiniowania eventów to wiele osób dla własnej wygody na pewno się tym zajmie. Takie gotowe eventy mają dużą zaletę "dyżurny" nie musi się bawić każdą zwrotnicą oddzielnie i nie musi się zastanawiać jaki sygnał wyświetlić na semaforze - po prostu wybiera przycisk "wjazd z toru szlakowego na tor nr..." i już. Jeśli wszystko trzeba by było robić ręcznie spodziewam się fali nieprawidłowych sygnałów i ogólnego zamieszania (no chyba, że na nastawnie będą wpuszczani tylko najbardziej doświadczeni).
-
Co do definiowania całych przebiegów oraz eventów warunkowych po stronie klienta, to jestem przeciw.
Czy przewidujesz możliwość sprawdzania zajętych torów, np. w postaci listy torów, na których coś stoi albo jedzie? Skoro będzie synchronizacja położenia pozostałych pojazdów, to czy podawane będą współrzędne każdego pojazdu osobno, czy czoła składu? (Skąd wiadomo, gdzie jest czoło trzech wagonów na bocznicy?)
Czy będzie możliwość sprawdzenia położenia zwrotnic u konkretnego klienta?
Czy zamiast XML można dać YAML, który zajmuje mniej miejsca i jest bardziej przejrzysty?
Jeśli chodzi o mnie, to chętnie dodam odpowiednie moduły do mojego programu. Zrobię też obsługę gotowych przebiegów itp. Chociaż tu bardziej by się przydało coś, co wygląda jak OSA-H, niż podgląd całej scenerii jak w STV...
-
Jeżeli dojdzie do tego, że "dyżurnych" będzie tylu, by każdy obierał swoją nastawnię, to rozwiązanie a'la OSA-H było by niesamowite. Na dzień dzisiejszy myślę, że jak osoba siedząca na nastawni rozrysuje sobie wszystkie stacje na Krzyżowej2 (scenerii), to będzie ok. Mi to by wystarczyło, bo jak patrzę na listę ze screena Wingera, to ciężko mi jest zorientować się, czy przekładałbym właściwy rozjazd, ale gdy wypiszę sobie, gdzie który event "siedzi", to sprawa bedzie prosta :-) ...przynajmniej dla mnie, ale z czyjego punktu widzenia miałbym mówić, jak nie ze swojego.
-
Czy przewidujesz możliwość sprawdzania zajętych torów, np. w postaci listy torów, na których coś stoi albo jedzie? Skoro będzie synchronizacja położenia pozostałych pojazdów, to czy podawane będą współrzędne każdego pojazdu osobno, czy czoła składu? (Skąd wiadomo, gdzie jest czoło trzech wagonów na bocznicy?)
Raczej nie, byłoby z tym już zbyt wiele pracy biorąc pod uwagę iż nie chcę temu poswięcać więcej czasu niz potrzeba.
Synchronizacja będzie jedynie dla składów prowadzonych przez innych userów, ruch AI będzie w trybie multiplayer całkowicie wyłączony ze względu na swoją nieprzewidywalność (co prawda można by wybrać jedną z sesji jako główną i z niej pobierać pozycje pojazdów AI, ale to kolejne kombinacje i mi się tego robić po prostu nie chce :). Podawana jest lokalizacja pierwszej lokomotywy składu, zakładając że każdy klient bedzie korzystał z tej samej scenerii można dość łatwo wyliczyć długość składu i na tej podstawie lokalnie stwierdzić gdzie znajduje się ostatni wagon. Nie przewiduję raczej możliwości odczepiania/podczepiania, o ile odczepianie się jeszcze jakoś można by przekazać do innych klientów to z podczepianiem się już tak łatwo by nie było (każdy wagon wymagałby osobnej nazwy itp). Tryb multiplayer będzie bardzo prostym trybem działania symulatora gdzie wszyscy widzą te same położenie zwrotnic/semaforów (czym steruje dyspozytor) i pozycje składów sterowanych przez innych są widoczne u każdego z klientów.
Chcę natomiast zrobić coś w rodzaju udostępniania zewnętrznej aplikacji (np. symulatorowi Paula) wyzwalania pewnych eventów po najechaniu na tor w celu stwierdzenia przez zewnętrzną aplikację zajęcia/zwolnienia danego odcinka, ale takich eventów nie mogło by być zbyt wiele.
Czy będzie możliwość sprawdzenia położenia zwrotnic u konkretnego klienta?
Nie przewiduję, symulacja będzie się opierała na tym iż chętne osoby podłączą się do serwera i w pewnym momencie rozpocznie się jazda (nowi klienci nie będą przyjmowani), od tej chwili jakiekolwiek zmiany przełożenia zwrotnic mogą pochodzić jedynie od dyspozytora (chcę wyłączyć w kodzie możliwość ręcznego przestawiania zwrotnic). Ponieważ po uruchomieniu symulatora wszystkie zwrotnice sa domyślnie ustawione na jazdę wprost, a wszelkie zdefiniowane przez twórcę scenerii eventy przestawiające zwrotnice zostaną usunięte z torów, można będzie założyć iż przechowywane przez serwer/dyspozytora stany położenia zwrotnic są identyczne jak u każdego klienta.
Czy zamiast XML można dać YAML, który zajmuje mniej miejsca i jest bardziej przejrzysty?
Tak, XMLa po prostu znam, a YAMLa ledwo co. Ale nie ma problemu, w końcu muszę się nauczyć :)
Jeśli chodzi o mnie, to chętnie dodam odpowiednie moduły do mojego programu. Zrobię też obsługę gotowych przebiegów itp. Chociaż tu bardziej by się przydało coś, co wygląda jak OSA-H, niż podgląd całej scenerii jak w STV...
Miałem właśnie taką nadzieję że to zrobisz, kiedy tylko zakończę testy i będzie to jakoś w miarę działało to udostępnię Ci specyfikację.
Na dzień dzisiejszy myślę, że jak osoba siedząca na nastawni rozrysuje sobie wszystkie stacje na Krzyżowej2 (scenerii), to będzie ok. Mi to by wystarczyło, bo jak patrzę na listę ze screena Wingera, to ciężko mi jest zorientować się, czy przekładałbym właściwy rozjazd, ale gdy wypiszę sobie, gdzie który event "siedzi", to sprawa bedzie prosta :-) ...przynajmniej dla mnie, ale z czyjego punktu widzenia miałbym mówić, jak nie ze swojego.
Właśnie w ten sposób będę przeprowadzał testy, zapoznam się z Krzyżową, zrobię sobie kilka rysunków i je odpowiednio pooznaczam (numery zwrotnic, oznaczenia semaforów) i będę próbował jakoś tego pilnować bez doprowadzenia do stłuczki ;)
Ta lista z mojego screena to bardzo prymitywna wersja, docelowo będzie to jakoś lepiej wyglądało, a nawet jeśli nie to w/w listy nie są takie długie - w Krzyżowej wszystkie zwrotnice i semafory sa ładnie opisane.
-
OK. Wspomnę tylko, że z mojego programu można wydrukować układ torów przymierzony do kartki A4, przynajmniej rok temu to działało. W razie potrzeby mogę coś poprawić, np. dodać opisy zwrotnic i semaforów.
-
Pomysł wyświetlania obrazu na semaforze jest dobry, choć w realu jest to generowane zależnie od położenia rozjazdu, obrazu następnego semafora itd. Mógłby to być taki "odcinek zdalnie sterowany", a nastawnie obsadzaliby użytkownicy ze znajomością przepisów sygnalizacji.
Maszynista powinien jechać a nie ustawiać sobie drogę przebiegu więc lepiej gdyby należało to do dyżurnego. PS Ja się pisze na dyżurnego :).
Jeżeli ktoś wykonał już plany to proszę o podesłanie. Ja aktualnie będę robił wszystko na kartkach A3 w celu lepszej przejrzystości, ponieważ pracuję na nastawni wiem jak to wygląda.
Tymczasem polecam do poćwiczenia programik @ISDR dostępny na: tnij.org/isdr
Polecam bo warto!
-
Pomysł wyświetlania obrazu na semaforze jest dobry, choć w realu jest to generowane zależnie od położenia rozjazdu, obrazu następnego semafora itd.
Po pierwsze: wiemy, w dodatku to jest oczywiste.
Mógłby to być taki "odcinek zdalnie sterowany", a nastawnie obsadzaliby użytkownicy ze znajomością przepisów sygnalizacji.
Maszynista powinien jechać a nie ustawiać sobie drogę przebiegu więc lepiej gdyby należało to do dyżurnego.
Po drugie: wiemy, w dodatku to jest oczywiste.
Tymczasem polecam do poćwiczenia programik @ISDR dostępny na: tnij.org/isdr
Polecam bo warto!
Mam nadzieję, że pisząc @ISDR chodzi Ci o nazwę paczki (isdr), a nie o użytkownika...
-
Marzenia są piękne, ale można się nimi podzielić:
Ma pewną koncepcję naszego multiplayera.
Pierwszy mój pomysł dotyczy łączności. Mianowicie dyspozytorzy mogli by mnieć TeamSpeak'a odpalonego dwa razy (o ile tak sie da), lub znaleźć można program do niego podobny. Chodzi mi o tzw. łączność pociągową i łączność pomiędzy dyspozytorami i ewentualnie dróżnikami (gdyż można by było wykonać prymitywny model budki przejazdowej, w której też mogliby siedzieć userzy). Jeden TS chodziłby na kanale dla maszynistów drugi na dyspozytorskim. Maszyniści mieliby tylko kanał... "dla maszynistów". Dyspozytorzy mogliby wysyłać do przejazdów w pobliżu przyjazd lub wyjazd pociągu a dróżnik zamykałby rogatki lub włączał sygnał dźwiękowy/świetlny. Budką mogę się zająć. pod każdą z nich byłby podziemny tor i machajka, na której by się startowało i "wlatywało" do budki.
Drugi mój pomysł dotyczy ruchu na scenerii:
Na wolnych torach stacyjnych mogłyby ewentualnie stać jakieś składy. Dyspozytor danej stacji miałby je na planie, bądź zapisane na kartce na którym torze stoją. Jeśli jakiś mechanik skończył by służbę na jednym pociągu na jego stacji, mógłby odczepić się od składu i pomanewrować pod drugi, i jechać dalej. Można by było też zmieniać czoło. Służba była by dłuższa. Albo składy stałyby na bocznicach, a w scenerię wstawiłoby się lokomotywy manewrowe.
Myślę tutaj, że będą jeździć osoby przynajmniej w stopniu podstawowym znające budowę pliku SCN.
Tutaj na forum można by wystawić wpisy ze składami bądź/i lokomotywami manewrowymi dla danej stacji. Każdy by sobie nanosił te poprawki do scenerii. Manewrowi wyciągaliby na stację, lub odwrotnie (po przyjeździe składu) wagony na bocznice. Maszynista natomiast na ten czas mógłby przejechać na jakiś tor boczny lub wolny i tam poczekać 10-15 minut, aż SM-ka podstawi mu skład na peron. Potem udać się w dalszą służbę. Jednak, żeby to jak najsprawniej funkcjonowało, musiałby być rozkład jazdy dla danej stacji (coś jak rozkład dla gry "Kolejarz"), który miałby każdy dyspozytor. Wydawałby on polecenia dla manewrowego i ustalał drogi manewrów. Potem można by było połączyć wszystkie rozkłady na podstawie SRJP maszynistów, skorygować, ustalić obiegi lokomotyw między różnymi składami i zrobić jeden duży rozkład dla całej scenerii. Jednak zdaję sobie sprawę, że byłoby z tym bardzo dużo roboty. Ale wtedy służba trwałaby dłużej, nie tylko jeden przejazd pociągiem przez scenerię. I musieli by jeździć dość dobrzy maszyniści, aby robić jak najmniej opóźnień, gdyż to mogłoby się odbić na innych składach.
Przykładowo lok EU07-310 skończy służbę w Krzyżowej. Odczepi się od składu i pomanewruje na jakiś boczny tor. Manewrówka odciąga skład na bok, podrzuca drugi. Siódemka podjeżdża, oczekuje na podanie sygnału na semaforze i polecenia odjazdu i rusza w dalszą drogę.
Co do polecenia odjazdu. Jako, że kierpociów raczej nie przewidujemy, dyspozytor na każdej stacji po podaniu sygnału dla danego pociąu na podstawie swojego rozkładu jazdy, podawałby przez radiotelefon polecenie odjazdu jak kierpoć. Co się tyczy małych stacyjek, które są w Krzyżowej.scn, tam mechanicy sami by ruszali.
Na razie tyle (za chwilę dzwonek i kompa muszę wyłączyć).
-
Pierwszy mój pomysł dotyczy łączności. Mianowicie dyspozytorzy mogli by mnieć TeamSpeak'a odpalonego dwa razy (o ile tak sie da), lub znaleźć można program do niego podobny. Chodzi mi o tzw. łączność pociągową i łączność pomiędzy dyspozytorami i ewentualnie dróżnikami (gdyż można by było wykonać prymitywny model budki przejazdowej, w której też mogliby siedzieć userzy). Jeden TS chodziłby na kanale dla maszynistów drugi na dyspozytorskim. Maszyniści mieliby tylko kanał... "dla maszynistów". Dyspozytorzy mogliby wysyłać do przejazdów w pobliżu przyjazd lub wyjazd pociągu a dróżnik zamykałby rogatki lub włączał sygnał dźwiękowy/świetlny. Budką mogę się zająć. pod każdą z nich byłby podziemny tor i machajka, na której by się startowało i "wlatywało" do budki.
Bez przesady. Nie ma sensu takie rozdrabnianie. Przejazdy w tym wypadku będą jako SSP/sterowane bezpośrednio przez dyżurnego ruchu (jeśli są w obrębie stacji np).
Na wolnych torach stacyjnych mogłyby ewentualnie stać jakieś składy. Dyspozytor danej stacji miałby je na planie, bądź zapisane na kartce na którym torze stoją. Jeśli jakiś mechanik skończył by służbę na jednym pociągu na jego stacji, mógłby odczepić się od składu i pomanewrować pod drugi, i jechać dalej. Można by było też zmieniać czoło. Służba była by dłuższa. Albo składy stałyby na bocznicach, a w scenerię wstawiłoby się lokomotywy manewrowe.
Myślę tutaj, że będą jeździć osoby przynajmniej w stopniu podstawowym znające budowę pliku SCN.
Odpowiedź już masz:
Nie przewiduję raczej możliwości odczepiania/podczepiania, o ile odczepianie się jeszcze jakoś można by przekazać do innych klientów to z podczepianiem się już tak łatwo by nie było (każdy wagon wymagałby osobnej nazwy itp).
-
ciach...
Pierwszy mój pomysł dotyczy łączności. Mianowicie dyspozytorzy mogli by mnieć TeamSpeak'a odpalonego dwa razy (o ile tak sie da), lub znaleźć można program do niego podobny. Chodzi mi o tzw. łączność pociągową i łączność pomiędzy dyspozytorami i ewentualnie dróżnikami (gdyż można by było wykonać prymitywny model budki przejazdowej, w której też mogliby siedzieć userzy). Jeden TS chodziłby na kanale dla maszynistów drugi na dyspozytorskim. Maszyniści mieliby tylko kanał... "dla maszynistów". ciach..
Według mnie nie trzeba mieć odpalonych 2ch aplikacji, wystarczy na TS- ie kanał zmienić jak w radyjku i wszystko gra :)
-
Co do droznikow - w rzeczywistosci droznika zawiadamia sie o wyjezdzie pociagu poprzez centralke telefoniczna, wiec lacznosc radiowa srednio tutaj bedzie pasowala. Inna sprawa jest, ze watpie w znalezienie chetnych tylko do samej obslugi przejazdow ;)
Taka koncepcja multi jaka opisales to bedzie, ale raczej tylko w SPT :)
-
Podobno w TSie da się nadawać do wielu kanałów na raz - tutaj jest wątek: http://forum.teamspeak.com/showthread.php?t=32306
-
A, tak za pamięci - przydała by się możliwość wyświetlenia na ekranie komunikatu wysłanego przez serwer.
-
Co do rozmów na TS'ie można zrobić coś na podobieństwo tak jak to kiedyś było w wirtualnej sieci lotniczej Vatsim.
-
Podobno w TSie da się nadawać do wielu kanałów na raz
Tylko jeśli mówisz, że naraz, to będą rozmowy pomiędzy dyspozytorami słyszeć maszyniści. Ja myślałem właśnie o 2 TS'ach, żeby jeden na jeden a drugi na drugi klawisz ustawić. Żeby się nie słyszeli.
Znaczy tak wg. mnie byłoby realistyczniej:)
Po "wg" nie stawia się kropki ;P
Andrzej.
-
Ja myślałem właśnie o 2 TS'ach, żeby jeden na jeden a drugi na drugi klawisz ustawić. Żeby się nie słyszeli.
Nie jesteś w stanie odpalić dwa okna ts'a na raz, ale możnaby postawić serwer Ventrillo, i np. dyspozytorzy do maszynistow rozmawiali by na TS'ie a sami dyspozytorzy na ventrillo...
-
Jeżeli będzie taka możliwość to należałoby dołożyć do exe mały update ( to tylko moja koncepcja ). Możliwość połączenia TS'a z exe widzę następująco:
Krok 1:
- na serwerze TS musi powstać kanał np: "Radio_multiplayer",
- dalej należy tak jak w prawdziwym radiu ustawić 10 podkanałów, czyli: 1, 2... itd.,
- do luźnych rozmów inne kanały mogą pozostać
Krok 2:
- ktoś wcześniej wspominał, aby była możliwość komunikacji tekstowej w symulatorze otóż proponuję dodać konsolę jak to się ma w exe Q
- tutaj już ludzie od programowania i kodu muszą sobie poradzić jak zrobić i zsynchronizować maszynę z TS'em aby można było w konsoli za pomocą określonej komendy ( np. #R1 gdzie #R{ to ta sterująca komenda radiem} 1{numer kanału radiowego} zmieniać podkanał w kanale "Radio_mutliplayer".
-
Przypominam, mam w planach tylko lekkie modyfikacje kodu. Integracja z TS? Zapomnijcie. Konsola jak w exe Q tudzież wyświetlanie komend? Zapomnijcie, kto widział różnice pomiędzy oryginalnym kodem MaSzyny a tym autorstwa Q wie o co chodzi, queued praktycznie połowę rzeczy tam przepisał. Samo zrobienie tego co chcę osiągnąć jest wystarczająco kłopotliwe co prowadzone codziennie testy pokazują.
Jak będziemy pracować z SPT to wrócimy do niektórych z w/w pomysłów :)
-
Dać niektórym rękę, to... hehe.
Kiedy będą testy publiczne? Dawno nie siedziałem na nastawni już :P Tylko upewniłbym się, czy Krzyżowa2 chodzi u mnie ok, bo różnie z nią bywa...
-
Trudno powiedzieć, na razie chcę doprowadzić do tego żeby przy 2-3 pojazdach działało poprawnie przez dłuższy czas, z czym na razie są jajca (średnio po 2-3 minutach dzieją się cuda).
Krok po kroku znajduję i poprawiam błędy w kodzie. Mateu zrobił malutką scenerię testową w celach testowych. Zobaczymy, może coś koło weekendu w końcu zadziała.
-
A czy będzie można zmodyfikować skład (np. podmienić lokomotywę), czy będzie musiał być "oryginalny".
-
Będzie można podmieniać składy, ale ich ilość i nazwy lokomotyw muszą być u wszystkich identyczne.
Wskazane też będzie by składy miały u każdego w miarę tą samą długość.
-
Winger, a robiłeś/masz w planach zrobić to wysyłanie niektórych eventów do aplikacji nadrzędnej (zamiast wykonywania ich w eu07)? Dawałem linka do scenerii testowej o którą pytałeś, nie wiem czy dotarł.
Zrobione w ten sposób eventy zajęcia/zwolnienia z detekcją kierunku można by wykorzystać nie tylko do wygaszania sygnałów i zwalniania utwierdzeń przebiegów, ale też do prymitywnego stwierdzania zajętości torów a nawet śledzenia numerów pociągów poruszających się po scenerii. Początkowo w aplikacji SRK mamy wpisany stan zajętości torów (i ew. numery), wraz z otrzymywaniem takich eventów ten stan byłby aktualizowany na zasadzie podobnej do działania liczników osi. Np: mamy skład na torze i informacje o tym (w aplikacji SRK do toru przypisany jego numer), ustawiamy przebieg wyjazdowy, skład mija semafor i zajmuje odcinek oddziaływania za nim - na podstawie tego aplikacja SRK pokazuje że zajęta została droga przebiegu za semaforem (i wygasza semafor), zwolnienie tego odcinka - powoduje usunięcie zajętości z toru przed semaforem, zajęcie odcinka na końcu przebiegu - zaznaczenie zajętości toru za końcem przebiegu, zwolnienie odcinka na końcu - zwolnienie zajętości drogi przebiegu (i zwolnienie utwierdzenia). Potencjalne problemy - sytuacje typu najechanie na odcinek oddziaływania i cofnięcie, albo łączenie/rozłączanie składu na torze - to by wymagało ręcznego korygowania informacji o zajętości przez dyżurnego, ale skoro łączenia/rozłączania ma nie być, to jakichś skomplikowanych manewrów chyba też, więc te problemy by właściwie odpadały.
-
Da radę to zrobić, ale najpierw staram się doprowadzić do tego żeby podstawy działały, a z tym niesamowite cuda wychodzą jak na razie.