Symulator EU07 (i nie tylko) > Na warsztacie
Planowane zmiany w exe
firleju:
Otwieram dyskusję o tym w których miejscach należy zmienić kod oraz jak to zrobić, żeby osiągnąć cele. Na początek szybka lista tego co moim zdaniem wymaga zmian:
* Rozbicie mover na klasy odpowiadające typom (prądu stałego, asynchrony, diesel, diesel electric, itp) a następnie poszczególnym modelom (obecnie rozróżnienie przez dt_xx). Za tym idą zmiany w parserze plików fiz, bo będzie można wywalić wszystkie niepotrzebne zmienne. Nie mówiąc już, że jakiekolwiek dodanie nowego typu pojazdu będzie łatwiejsze. Z minusów wymaga to zmian w interfejsie do pythona na pobieranie przez skrypt wybranych danych, ale samych ekranów nie jest jeszcze na tyle, żeby nie dało się tego wykonać.
* Rozbicie Driver na część tylko dla człowieka oraz tylko dla AI, być może AI dla specjalnych okazji jeśli mają być takowe.
* Implementacja protokołu do wymiany danych z SCS. Wywalenie eventów. Dość trudne, gdyż już teraz na etapie zmian w tabelce dochodzę do kwestii kompatybilności z tym co obecnie można robić, a co będzie możliwe po zmianach. Tu jest pytanie czy tylko naprawić co jest na potrzeby Kaliskiej w obecnej wersji i po prostu zrobić to od nowa, ale wtedy wszystkie scenariusze będą do zrobienia na nowo (chociaż zapewne odtworzenie będzie bardzo łatwe przy pomocy SCS).
* Serializacja danych w celu zapisu i odtworzenia stanu sesji jest możliwa, szczególnie jeśli porozbijamy monolityczne klasy jak obecnie.
tmj:
Dokleje tylko moj wczesniejszy kawalek z watku c++ zeby nie zginal
Co do grubszych zmian, zastanawiajac sie nad tym, co powinno byc zrobione, wyszla mi nastepujaca lista:
* rozdzielenie symulacji od wizualizacji. Czesc z tego jest juz chyba zrobiona, ale docelowo kompletny uklad torow i lista poruszajacych sie po nich obiektow, obsluga eventow + kalkulacje fizyki dla tych obiektow powinna pracowac praktycznie niezaleznie jako odrebny modul. Stan obiektow symulacji moze byc podawany zainteresowanym sluchaczom, a czy tym sluchaczem jest silnik graficzny (czy wrecz caly klient w systemie multiplayer), przekaznik informacji dla pulpitu, modul kontroli ruchu czy jeszcze cos innego, to juz symulacji nie obchodzi.
* powiazane z powyzszym i opcjonalna, reorganizacja sterowania symulacja na uklad dwustopniowy -- pomijajac siec trakcyjna, stopien pierwszy czyli 'swiat' symulacji zredukowany jest do ukladu torow i uniwersalnych 'punktow sygnalowych' ktore sa zrodlem instrukcji dla AI pojazdow, i z reguly umieszczone sa tam, gdzie znajduja sie fizyczne wskaznikow/sygnalow/itp. Konkretne jakie instrukcje emitowane przez punkty sygnalowe zalezy od stopnia 2-ego, tj. skryptu i/lub modul(ow) spietych z danym punktem. Uprosciloby to tworzenie scenerii -- uklad torow i wskaznikow robiony jest raz, a kontrola sygnalow zajmuje sie juz modul kontrolera, w zaleznosci od otrzymanego scenariusza. I czy tym kontrolerem jest modul AI, czy zywy czlowiek albo nawet kilku, to juz symulacji nie obchodzi.
* opcjonalne, uporzadkowanie zmiennych w glownych klasach. Te wieksze maja cos z 50+ parametrow, wszystko wrzucone na jedna kupe. Trudno dojsc co jest pobierane z plikow konfiguracji, co jest kalkulowane, co nie jest uzywane w ogole. Pogrupowanie tego w sensowne struktury ulatwiloby punkt nastepny
* krytyczne, wprowadzenie zapisu 'swiata' z poziomu symulatora, i wczytywanie tego zapisu. Glownie majace na celu uproszczenie i przyspieszenie edycji scenerii; zamiast zabawy edytorami tekstu, zewnetrznymi narzedziami itp powinno to byc cos, co robisz bezposrednio w programie i "what you see is what you get". Zamiast zgadywac, jak prezentuje sie obiekt umieszczony w scenerii, po prostu mozna to od razu zobaczyc, tak jak i wprowadzane poprawki. W polaczeniu ze zmianami powyzej pozytywnym efektem ubocznym mogloby byc tutaj przyspieszenie ladowania scenariuszy -- program moglby wczytac od razu uklad torow i zestaw pojazdow, a nastepnie doczytac sobie w locie dane potrzebne do wizualizacji.
A tak z zupelnie innej beczki, to ile dobrze pamietam Q zaczal robic jakas wersje kodu z przepisana grafika itp, tylko sie to rozbilo na przepisywaniu fizyki. Skoro fizyka w c++ teraz zaczyna jako tako chodzic, moze daloby sie to jakos polaczyc?
firleju:
Do spraw, do zrobienia jest sterowanie pociągiem. To co yB wyłuszczył jest dość istotne dla prowadzenia symulacji. Więc trzeba zaprojektować nową architekturę, która uwzględni nowe pojazdy. Może coś takiego:
Pociąg -> Pojazd / Wagon -> Fizyka
Wtedy poszczególne elementy zawierają:
* Pociąg: zawiera wszystkie pojazdy / wagony, przechowuje rozkład jazdy, przechowuje AI / człowieka dla wszystkich pojazdów, które mają sterowanie (np. podwójna trakcja).
* Pojazd / Wagon jest dość ciekawą konstrukcją. Z punktu widzenia Pociągu to to jest to samo. Z punktu widzenia Wagonu Pojazd jest pociągiem. Czyli Pojazd jest specyficzną konstrukcją, która przechowuje poszczególne Wagony oraz logikę przekazującą polecenia AI dla poszczególnych Wagonów. Pojazd byłby lepiej napisanym odpowiednikiem obecnego sprzęgu depotowego.
* Fizyka: zawiera obliczanie zmiennych fizycznych dla danego Wagonu. Np. dla wagonów to może być tylko liczenie sił na sprzęgach oraz układ hamulcowy. Dla części EZT to może być różna fizyka zależnie od posiadania lub nie odpowiednich elementów.Kwestia umiejscowienia kabiny i miejsca przechwytywania sterowania jest do rozwiązania.
tmj:
Nazwalbym to moze raczej pociag->zespol->pojazd, bo na poziomie podstawowym niekoniecznie musi byc to wagon, ale tez np. lokomotywa, ale to kosmetyka ;) a samo podejscie wyglada sensownie.
Co do kabin, chyba rozdzielibym je troche od pojazdu i uogolnil, w porownaniu do obecnego pdejscia. Konkretnie, kabina jako osobny obiekt z konfiguracja dyktujaca spis przelacznikow ktore zawiera, link do modelu podstawowego i wersji lowpoly, plus pozostale parametry. Takich obiektow 'wnetrz' mozna podlaczyc do pojazdu kilka, bez biezacego roznicowania na kabine, przedsionek itp -- tym sposobem mozna by latwo skonstruowac/obsluzyc kazdy rodzaj pojazdu, w tym kombinacje z kabinami i modulem pasazerskim w jednym pudle, nawet z indywidualnym stanem oswietlenia kazdej sekcji, widocznym w wizualizacji. Potencjalnie upraszcza tez to takie mechanizmy jak przechodzenie miedzy rolami pasazera i mechanika w skladzie, jesli kogos to bawi.
Sterowanie umiescilbym na poziomie pociagu, w calosci przy pomocy komend, odpowiednikow biezacych komend rozsylanych po skladzie. W ten sposob obsluga moze byc jednakowa bez wzgledy czy zrodlem jest uzytkownik walacy w klawisze, AI obslugujace sklad albo jakies zewnetrzne zrodlo -- otrzymane komendy sa (opcjonalnie) przepuszczane przez aktualnie obsadzona kabine, i jesli ma ona odpowiednie dzwignie/przyciski to sa wykonywane i przekazywane dalej. Tym sposobem jesli uzytkownik jest w kabinie mechanika to dostaje kontrole nad wiekszoscia funkcji, a gdy siedzi w wagonie pasazerskim to moze sobie najwyzej wlaczyc swiatlo albo pociagnac za hamulec bezpieczenstwa :d
firleju:
Chciałbyś umieścić fizykę w klasie pojazdu?
Chciałbym uniknąć niepotrzebnego tworzenia klasy zespół dla pojedynczych pojazdów. Tak naprawdę zespół jest potrzebny tylko do ezt. Cała reszta tego nie potrzebuje.
Teraz eventy. Ogólnie mamy konsensus, że trzeba to wywalić, ale na potrzeby aktualnych prac myślałem nad tym jak AI współpracuje z modelem scenerii. Wpływ na prowadzenie postrzeganie trasy mają dwie rzeczy: tory oraz wszelakiego typu wskaźniki i semafory. Obecnie AI skanuje tor przed sobą i czyta czy jest do niego przypisany event od strony od której nadjeżdża. Potem event jest sprawdzany na okoliczność uznania go za "pasywny". Do tego punktu wszystko jest ok. Następnie wszystko jest wrzucane do wspólnego worka pod nazwą SpeedTable, która ma własne algorytmy przeliczania odległości od obiektów. Niestety, te algorytmy działają tylko przy założeniu, że urządzenia są przypisane do torów przy których stoją i w kolejności w jakiej stoją. Wszelkie błędy powodują nieprawidłowe przeliczanie odległości.
cdn..
Nawigacja
[#] Następna strona
Idź do wersji pełnej