- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Poszukuję, chcę zrobić => Wątek zaczęty przez: Ra w 17 Sierpnia 2010, 13:11:56
-
W związku z pracami nad uruchomieniem multiplayera, zgłaszam zapotrzebowanie na sporządzenie dodatkowych informacji dla istniejących scenerii. Na chwilę obecną trudno powiedzieć, jakie dokładnie dane będą potrzebne i w jaki sposób mają być zorganizowane. Mniej więcej widzę to tak:
1. Lista nazw stacji z podaniem współrzędnych w scenerii. Potrzebna będzie do szybkiego przemieszczenia podglądu do wybranej stacji. Tu proponuję zrobić plik CSV o postaci:
nazwa scenerii,nazwa stacji,wsp. X,wsp. Z,północ,południe,wschód,zachód
gdzie ostatnie cztery wartości są współrzędnymi prostokąta obejmującego stację (łącznie z semaforami wjazdowymi, ewentualnie pobliskim przejazdem, jeśli taki jest). Współrzędna X ze scenerii powinna być podana z przeciwnym znakiem.
2. Lista semaforów dla każdej stacji. Typy semaforów da się odczytać automatycznie z nazw INC, potrzebny jest tylko spis nazw. Jeśli każda głowica miała by być obsługiwana osobno, albo stacja posiada oddzielone od siebie części, trzeba by zrobić osobny spis dla każdej z nich.
3. Lista zwrotnic dla każdej stacji. Z podziałem podobnym jak dla semaforów.
4. Lista dodatkowych urządzeń (wykolejnice, przejazdy) dla danej stacji lub jej części.
5. Propozycja typu sterowania dla danej stacji - od tego będzie zależeć budowa pulpitu sterującego (np. pulpit kostkowy, OSA-H).
6. Lista przebiegów - tabela zależności. Pozostaje w związku z typem sterowania. Nazwy przebiegów są tworzone z nazwy semafora i położenia kolejnych zwrotnic za nim, aż do kolejnego semafora, np. E3-111, Tm34-22 (1 - zwrotnica na wprost, 2 - zwrotnica na bok). Dla każdego przebiegu należy podać stan poszczególnych urządzeń (plus albo minus, wykluczenie dla semaforów z przeciwnej strony - dwa plusy). Do tego jakiś opis tekstowy (z którego toru na który). Najlepiej dla każdej stacji (części) oddzielny plik typu INI.
7. Układ dla pulpitu kostkowego. To raczej najbardziej skomplikowana część, bo nie wystarczy narysować obrazek, ale trzeba podać typ kostki na każdej pozycji. Na chwilę obecną nie są mi znane nazwy kostek, jakich można by używać. Ewentualnie rozrysowany pulpit mógłby posłużyć do dalszych prac.
8. Rozkłady jazdy - czas przejazdu pomiędzy poszczególnymi stacjami dla pociągów osobowych i towarowych. Osobno dla zatrzymania na obu stacjach, przelotu przez jedną z zatrzymaniem na drugiej i przelotu przez obie.
Proponuję zacząć od scenerii Krzyżowa, z uwagi na możliwość prowadzenia ciągłego ruchu bez manewrów i dużą popularność.
-
6. Lista przebiegów - tabela zależności. Pozostaje w związku z typem sterowania. Nazwy przebiegów są tworzone z nazwy semafora i położenia kolejnych zwrotnic za nim, aż do kolejnego semafora, np. E3-111, Tm34-22 (1 - zwrotnica na wprost, 2 - zwrotnica na bok).
Mam pewna watpliwosc. Przykladowo dwa rozne przebiegi:
- semafor wjazdowy to "A", pierwsza zwrotnica na wprost, druga na bok (zmiana toru), trzecia na wprost i zatrzymanie przy peronie; oznaczenie wygladaloby tak A-121
- semafor wjazdowy to "A", pierwsza zwrotnica na wprost, druga na wprost, trzecia na bok i zatrzymanie przy peronie; oznaczenie wygladaloby tak A-112
I teraz czy takie rozroznienie jest wystarczajace dla programu, ktory bedzie te pliki przetwarzal. Chodzi o to, czy program bedzie wiedzial, ze zwrotnica trzecia z przebiegu A-121, to nie jest ta sama, ktora wystepuje jako trzecia w przebiegu A-112?
-
Program będzie wiedział, bo dany przebieg będzie przypisany do dwóch punktów na torach stacji. Chodziło mi głównie o jednoznaczną nazwę przebiegu, a taki zapis jest wystarczający. Ustawienie poszczególnych zwrotnic i tak trzeba wypisać, bo oprócz zwrotnic po których jest jazda ustawia się również te uniemożliwiające kolizyjny wjazd z innych torów (przynajmniej dla przebiegów pociągowych).
-
Aha. A jak nazwac angliki?
-
Identycznie jak w przypadku zwrotnic, bo wjeżdżasz zawsze z którejś strony (od semafora) i jedziesz albo na wprost, albo na bok. W symulacji są traktowane jako cztery oddzielne zwrotnice (różniące się ostatnią literą) i tak będą sterowane.
-
Jak rozumiem sterowanie na stacjach będzie się odbywało na pulpitach kostkowych, czyli takich jak z symulatora E1 Osielec? Postaram się pomóc w robieniu spisu semaforów, zwrotnic. Proponuję aby każdy pisał jaką stację spisuje, aby nie było że jedna stacja będzie trzy razy spisana a inna wcale.
-
No jest taka opcja. Sensowniej będą wyglądały pulpity kostkowe, niż klikanie na zwrotnice albo wybieranie z listy, co ma semafor wyświetlić.
-
Też tak sądzę, wydaje mi się że było by to łatwiejsze w obsłudze.
-
Pulpity łatwiejsze w obsłudze chyba nie są, sądząc po tym symulatorze. Ale jest to bardziej realistyczne.
-
Postaram się dziś wieczorem wykonać odpowiednie pomiary dla stacji (a także pomiędzy nimi): Drawowo Główne - Markowo Dolne, Markowo Górne, a także zapiszę wszystkie inne potrzebne informacje.
EDIT: Udostępniam narazie punkty 1-4 dla w.w. stacji.
-
Ja mogę zrobić pulpity kostkowe.
-
Ja mogę zrobić pulpity kostkowe.
Obawiam się że to będzie na czymś innym polegać niż plik bmp z painta wklejony po prostu do programu.
tu wypowiedź @Ra na temat pulpitów/sterowania : 7. Układ dla pulpitu kostkowego. To raczej najbardziej skomplikowana część, bo nie wystarczy narysować obrazek, ale trzeba podać typ kostki na każdej pozycji.
-
Ale układ w bmp też będzie potrzebny.
Przy okazji, jeżeli np. na stacji w Krzyżowej są dwie nastawnie, to będą tworzone dwa pulpity?
-
Układ się sam wygeneruje, jak będzie spis kostek i oznaczeń. Chyba że chcesz zrobić fototekstury pojedynczych kostek…
-
Ale w takim wypadku po co fototekstury?
-
Fototekstury po to żeby było widać kostki. Proste -> Jest zdjęcie kostki, łączysz je z innymi kostkami np. w gimpie i zapisujesz jako jpg lub bmp i podkładasz jako plan. Na nim operujesz przebiegami.
-
Po co? Przecież jest program "Kostki" autorstwa Paula.
http://www.kontrakt-bhp.com.pl/paul/epk.rar Można go pobrać stąd.
-
Po co? Przecież jest program "Kostki" autorstwa Paula.
Właśnie oto mi chodzi.
-
Też myślę że lepiej za pomocą tego programu robić, zrobić pulpit stacji to max 30 minut.
-
Też myślę że lepiej za pomocą tego programu robić, zrobić pulpit stacji to max 30 minut.
Po co robić, skoro kolega @Ra mówi, że jest w stanie napisać generator? Potrzebuje tylko spis kostek i ich oznaczeń.
-
Ale po co kolega @Ra będzie się męczyć z generatorem, skoro kilka osób może zrobić pulpity.
Ja aktualnie tworze pulpity dla Krzyżowej.
-
Po co mamy się bawić w tworzenie planów i tracić czas skoro będzie generator który załatwi sprawę w dosłownie minutkę? Teraz są ważniejsze rzeczy do zrobienia takie jak lista przebiegów i rozkłady jazdy. Wy chcecie się na siłę bawić w jakieś kostki..., bo myślicie że jak coś takiego zrobicie to zabłyśniecie jako developerzy? ;] (kieruję to szczególnie do @epoka9.24).
-
Zgaszę zapędy co niektórych - sama bitmapa z kostkami nie wystarczy. W końcu jakiś program musi wiedzieć, że w danym punkcie jest lampka taka i taka, w innym innych rozmiarów, gdzieś indziej jest szczelina, a jeszcze gdzie indziej jest przycisk wciskany lub wyciągany...
-
Ja tu jeszcze może trochę odejdę od tematu ale... @Ra a jak chcesz załatwić prowadzenie AI na czyimś kompie? bo skoro to ma być multiplayer to warto by było wiedzieć, a raczej widzieć że się z kimś np mijamy ;)
-
Jest już zrobiona możliwość wysyłania rozkazów do AI. Zamierzam synchronizować położenie pociągów odcinkami, czyli jeśli użytkownik sterujący wyjeżdża na szlak, to u pozostałych wypuszczane wszystkie AI. Gdy wszystkie dotrą do miejsca docelowego, można uznać przejazd za zakończony. Ewentualnie trzeba będzie czekać, aż wszystkie AI dojadą. Tor będzie uznany za wolny, jeśli u wszystkich podłączonych do serwera użytkowników będzie zwolniony.
Odnośnie pulpitu - narysować w edytorze Paula można, niemniej edytor ten nie zapisuje symboli kostek, więc potem ktoś będzie musiał "zdekodować" rysunek na opis zrozumiały dla programu obsługującego pulpit. Samo graficzne rozmieszczenie kostek jakimś pozytywnym wkładem pracy będzie i też się przyda.
-
Po co mamy się bawić w tworzenie planów i tracić czas skoro będzie generator który załatwi sprawę w dosłownie minutkę? Teraz są ważniejsze rzeczy do zrobienia takie jak lista przebiegów i rozkłady jazdy. Wy chcecie się na siłę bawić w jakieś kostki..., bo myślicie że jak coś takiego zrobicie to zabłyśniecie jako developerzy? ;] (kieruję to szczególnie do @epoka9.24).
No tak, najlepiej za przeproszeniem, zje..ć kogoś kto chce coś zrobić dla symulatora, i nie chodzi mi o developowanie bo głupiej bitmapy nie można porównywać z np. nowym 4E. Nie znam się na pisaniu eventów dlatego chcę zrobić coś co potrafię, jeśli mnie nauczysz pisać eventy to z chęcią pomogę w innych rzeczach.
Uważaj na słowa! Pierwsze zdanie można przedstawić w bardziej łagodniejszy sposób.
/ Żuk
-
A więc rozumie się że sprawa AI jest już załatwiona. Okej więc EOT.
A tu udostępniam paczkę z opisem/spisem prawie wszystkich* urządzeń dla Krzyżowej i Chełminowa.
*Brakuje przejazdów.
-
Witam
Jakiś czas temu zabrałem się za tworzenie programu, który mógłby służyć do sterowania ruchem w EU07. Program ma dosyć duże możliwości, jest prosty jeżeli chodzi o "programowanie scenerii" i uwzględnia podstawowe zasady prowadznia ruchu, ale z braku zainteresowania zarówno użytkowników jak i developerów, moich ograniczeń sprzętowych (które praktycznie wykluczają zabawę w EU07), poważnych ograniczeń możliwości sterowania w EU07 oraz pracy nad własnym symulatorem zawiesiłem prace nad nim. Tak więc wychodzi na to że powstał bardziej jako eksperyment i dla własnej satysfakcji, niż jako praktyczne zastosowanie. W razie czego mogę jednak do niego wrócić.
Idea jest taka, że mamy zewnętrzny program który wysyła nazwy eventów do odpalenia w EU07 (przestaw zwrotnicę, wyświetl sygnał), natomiast EU07 odsyła do programu meldunki o stanie urządzeń w scenerii (odpalono event przestawiania zwrotnicy, wyświetlono sygnał, wjechano na odcinek). Interfejs programu wygląda tak jak typowy komputerowy system SRK. Układ torów, urządzeń i ich parametry edytowane są graficznie i jednocześnie pełnią funkcję zależnościową - program sam wyszukuje i nastawia przebiegi według podanych punktów początkowych i końcowych. Jednocześnie program śledzi ruch poszczególnych pociągów, co pozwoliło by na pewną automatyzację prowadzenia ruchu (nastawianie przebiegów według informacji o położeniu pociągów i rozkładzie jazdy).
Program powstał raczej jako próba rozwiązania problemu sterowania ruchem w EU07, a nie robienia "multi" - jak wiadomo eventy są rozwiązaniem kłopotliwym i mają bardzo ograniczone możliwości, więc program miał by być uruchamiany "w tle" razem z symulatorem i przejąć funkcję eventów, zostawiając je jedynie w roli "warstwy wykonawczej". Nie mniej jednak myślę że dało by się go wykorzystać do tzw. "multi", łącząc się przez sieć z kilkoma symulatorami jednocześnie, wysyłając polecenia do wszystkich i odpowiednio analizując przysyłane zgłoszenia.
Poważnym problemem jest wykrywanie zajętości w EU07, a właściwie jej brak - rozwiązane to zostało poprzez rozmieszczenie w poszczególnych miejscach krótkich odcinków torów, które wysyłają zdarzenia zajęcia i zwolnienia, na podstawie czego program zaznacza zajętości między tymi odcinkami (np. tor stacyjny, tor szlakowy, tor między semaforem wjazdowym a głowicą rozjazdową, głowica rozjazdowa), ale jest to metoda zawodna i nieodporna na wjazd i cofnięcie z odcinka (łatwo można doprowadzić do sytuacji polegającej na stwierdzeniu zwolnienia niezajętości, mimo że tor faktycznie jest zajęty, bądź na odwrót) - żeby to w miarę działało, potrzebne było by dodanie nowych eventów dla toru (zajęcie w kierunku 1/2, zwolnienie w kierunku 1/2), a i tak będzie problem przy łączeniu i rozłączaniu (każda taka operacja będzie wymagała poprawienia informacji o zajętości toru, inaczej znowu może powstać fałszywa niezajętość). Problem może być jeszcze z właściwą interpretacją sygnałów przez AI - tu nie ma ustalonych misji i dokładnie przetestowanego ruchu pociągów kierowanych przez program, jeździmy dowolnie, tak jak pozwala układ torowy. Błąd AI rozwali całą zabawę.
Poniżej screen z programu - widoczne nastawione przebiegi a także wspomniane odcinki służące do śledzenia ruchu (małe trójkąty). Oczywiście program nie współpracuje z EU07 - zrobione jest jedynie "symulowanie" wykonywania eventów i odsyłania meldunków.
-
Na chwilę obecną jestem w trakcie przerobienia sposobu wyświetlania grafiki w Symku i jeszcze mi na to zejdzie. Jak dojdę z tym do ładu, mogę coś zrobić w kierunku sprawdzania zajętości odcinków.
Zamierzam dodać eventy wyzwalane przy zajęciu i zwolnieniu toru. Nazwy tych eventów nie będą podawane wprost, jak to jest obecnie, ale tworzone niejawnie z nazwy toru. Przykładowo, jeśli tor ma nazwę t_11534, to eventy będą nazwane odpowiednio t_11534:busy oraz t_11534:free. Jeśli wpisy eventów o takich nazwach nie zostaną znalezione, to eventy się nie będą wykonywać. Również, jeśli tor będzie miał nazwę none. Trzeba będzie unikać nadawania tej samej nazwy różnym torom, gdyż spowoduje to zamieszanie. Rozwiązanie takie nie wymaga modyfikacji w istniejących sceneriach.
Osobną kwestią jest sprawdzanie zajętości toru złożonego z kilku odcinków. Najlepiej by było je jakoś zgrupować i zajętość sprawdzać na zamówienie (żeby nie robić tego niepotrzebnie). Tu można by pokombinować z nazwami torów - na użytek edytora opracowałem nazewnictwo z kropką, np. TG_t100.2, gdzie TG to kod stacji, t - litera pomocnicza, 100 - numer toru i 2 - numer odcinka (nazwy w tym formacie są kodowane jako liczby 32 bitowe). Tory z identyczną nazwą przed kropką znajdowałyby się automatycznie we wspólnej grupie. Zakładając, że ilość torów w grupie nie przekroczy 63, można by zrobić maskę bitową zajętości poszczególnych odcinków, a co za tym idzie generować eventy zajętości i zwolnienia takiej grupy.
W temacie AI do prześledzenia jest obsługa sprzęgów. AI nie może ich zrywać. Nie powinno być też możliwości ciągnięcia taboru, który pojechał po innym torze. Chcę również sprawdzić możliwość usuwania i wstawiania taboru podczas symulacji.