Symulator EU07 (i nie tylko) > Na warsztacie
Planowane zmiany w exe
youBy:
Bipa i przegubowe platformy kontenerowe też są pojazdem wielowagonowym.
AtapiCl:
ET41? ET42? etc...
tmj:
--- Cytat: firleju w 05 Lutego 2017, 21:19:11 ---Chciałbyś umieścić fizykę w klasie pojazdu?
--- Koniec cytatu ---
No raczej tak, bo w zasadzie wszelkie kalkulacje trzeba bedzie przeprowadzac na poziomie poszczegolnych czlonow/wagonow/whatever. Gdyby sie strasznie chcialo, to mozna wydzielic z tego wozek jako sub-component, i np. prowadzic wozki po torze indywidualnie, i na podstawie tego kalkulowac, gdzie jest pudlo (dopoki sie nie rozerwie jak na rozjezdzie kazdy wozek pojdzie sobie na inny tor) Ale to tak opcjonalnie.
--- Cytuj ---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.
--- Koniec cytatu ---
Ja bym to potraktowal troche bardziej ogolnie -- z punktu widzenia pociagu wszystko, co ma pod soba to zespoly, a juz tylko sam zespol obchodzi ile ma w sobie komponentow, i jakie. Tzn. mozna by sie tez alternatywnie bawic w aranzacje typu pociag -> pojazd, a dla pojazdow wyprowadzamy osobno zespol wariant, ale tego typu dziedziczenie na dluzsza mete bardziej chyba komplikuje sprawe, niz ulatwia.
--- Cytuj ---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..
--- Koniec cytatu ---
Tutaj zastanawialem sie, czy sprawy nie uproscilo by faktyczne zalozenie, ze zrodla komunikatow sa wszystkie przypisywane do konkretnych torow. Tzn masz cos w rodzaju: uklad torow dzielimy na wierzcholki (semafory) i krawedzie (odcinki torow od jednego wierzcholka do drugiego), plus trzeci element jakim jest 'skrzyzowanie' czyli krawedz laczaca kilka wierzcholkow na specjalizowanych zasadach, uzywana do realizowania zwrotnic, obrotnic, skrzyzowan drog itp. Bazujac na tym, zrodlo komunikatow jest traktowane jako punkt w danej odleglosci od konca/poczatku odcinka toru -- moze ich byc wiecej nie jeden, i tor trzyma sobie (posortowana) liste takich punktow wewnetrznie, i przekazuje zainteresowanym pociagom. W tym momencie odpada caly problem skanowania, bo po takim przekazaniu pociag wie dokladnie w jakiej odleglosci znajduja sie najblizsze komunikaty, i uaktualnia sobie te odleglosci po prostu na podstawie przejechanego dystansu.
Na potrzeby wizualizacji zrodla komunikatow powiazane sa z obiektami 3d, ktore uzytkownik ustawia sobie gdzie mu pasuje. W pewnym sensie jest to odwrocenie obecnej sytuacji, w ktore event jest wstawiany do sceny 3d a potem dopiero przypisywany luzno do toru, bez konkretnego okreslenia , gdzie.
firleju:
eventy cd.
Obecnie robię to tak, że rozdzieliłem tabelkę na dwie. Jedna trzyma informacje o zeskanowanych torach, druga o zeskanowanych wskaźnikach. W tej chwili obie to std::deque gdyż doszedłem do wniosku, że modyfikacja kolejek odbywa się raz na parenaście sekund więc narzut związany z ewentualną alokacją pamięci jest pomijalny. Takie rozbicie pozwala np. sprawdzać szybciej sobie ograniczenia ze wskaźników (tabelka jest o wiele mniejsza). Modyfikacja odległości w tabelkach odbywa się przez odjęcie odległości przejechanej przez pociąg co wszystko upraszcza. Całe clue zabawy polega na prawidłowym policzeniu odległości do obiektu podczas skanowania z czym aktualnie walczę.
Wydaje się, że sposób łączenia torów z wskaźnikami zostanie bardzo podobny do obecnego. Po prostu nie będzie uruchamiania tego punktu przez najeżdżający wózek.
Co do pojazdów z fizyką, to zważ że jeśli zmiksujesz DynamicObject z TMoverParameters ze stworzeniem tego dla każdej klasy pojazdu osobno to w przypadku jeśli zawsze pociąg będzie zawierał zespoły i te dopiero pojazdy to dla typowego składu cargo sytuacja nie rożni się od obecnej.
tmj:
--- Cytat: firleju w 07 Lutego 2017, 21:59:42 ---Całe clue zabawy polega na prawidłowym policzeniu odległości do obiektu podczas skanowania z czym aktualnie walczę.
--- Koniec cytatu ---
Z tego co pamietam, zarowno sklad jak i eventy maja zdefiniowane absolutne wspolrzedne 3d, czy nie sprowadza sie to wiec po prostu do stworzenia wektora miedzy tymi dwoma punktami, i policzenia dlugosci? Czyli cos jak distance = vector3( vehicle.position, event.position ).length().
(to sie moze rozleciec w sytuacji gdy np tor jest ostro zakrecony, i skanowany element jest na drugim koncu takiej 'podkowy', stad propozycja innego podejscia w zmienionej strukturze)
--- Cytuj ---Co do pojazdów z fizyką, to zważ że jeśli zmiksujesz DynamicObject z TMoverParameters ze stworzeniem tego dla każdej klasy pojazdu osobno to w przypadku jeśli zawsze pociąg będzie zawierał zespoły i te dopiero pojazdy to dla typowego składu cargo sytuacja nie rożni się od obecnej.
--- Koniec cytatu ---
Roznice pojawilyby sie na poziomie interakcji kontrolera ze skladem; w chwili obecnej to jest jedna wielka kupa instrukcji warunkowych -- jesli silnik typu x to zrob to, a jak y to tamto, a jak lokomotywa jest okreslonego typu.. itd. Po zmianach to wszystko byloby rozdzielone do konkretnych typow pojazdow, a obsluga zblizona do tego, co w tej chwili oferuje uklad hamulcowy. W pewnym sensie uklad zespol->pojazd(y) bylby analogiczny do biezacego ukladu pojazd->hamulec, tylko o poziom wyzej.
Nawigacja
[#] Następna strona
Idź do wersji pełnej