Chciałbyś umieścić fizykę w klasie pojazdu?
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.
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.
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.
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..
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.
Pokaż wiadomości