Symulator EU07 (i nie tylko) > Pomoc w tworzeniu
Pytania o eventy
pol102:
--- Cytat: kamil1306 w 22 Września 2012, 17:22:50 ---
--- Cytat: szogun w 20 Września 2012, 15:39:30 ---W tym logu nie widzę żadnych danych dotyczących wykolejenia. ZTCP to EXE 325 zapisywało takowe (derailed due np. to high speed).
--- Koniec cytatu ---
Nie wiem dlaczego w logu nic nie ma. Tak się wykoleja.
--- Koniec cytatu ---
Spakuj swoją scenerię z tym problemem i wstaw tu linka.
popatrz:
--- Cytat: SKP w 22 Września 2012, 17:48:36 ---Tmuszą mieć takie same współrzędne.
--- Koniec cytatu ---
I przechyłki też (ważne przy zakrętach).
SKP:
Przechyłki są w tej samej linii co X Y Z, więc z reguły kopiuje się wszystko i nie ma z tym problemu.
popatrz:
Zgadza się. Czasami jednak w "ferworze walki" można namieszać i zaczyna się debuging :)
Dodano: 25 Września 2012, 09:34:15 Mój problem dotyczy ograniczeń prędkości dla AI.
Dążę do tego, żeby nie wstawiać Velocity w torach. W zamian tego chciałbym ograniczać prędkość przez zdarzenie PutValues z parametrem SetVelocity umieszczone w inc'u przypisanym do toru gdzie ma się zaczynać i kończyć ograniczenie prędkości.
Rozwiązanie to ma taką zaletę, że nie trzeba używać n-razy tego samego wpisu dla całej grupy torów. Potrzebne są tylko 2 wpisy w torach.
Jako, że _distinfo przestał działać, zmodyfikowałem więc odpowiednio w9.inc:
--- Kod: ---// ograniczenie prędkości, parametry:
//---------------w9---------------
//param: textura, x, z, y, kat
//początek ograniczenia
event (p1)_wja putvalues 0.0 none (p2) (p3) (p4) SetVelocity (p8) (p8) endevent
//minięciu końca ograniczenia
event (p1)_wyj putvalues 0.0 none (p2) (p3) (p4) SetVelocity -1 -1 endevent
origin (p2) (p3) (p4)
rotate (p6) (p5) (p7)
node 400 0 none model 0 0 0 0 ip/pkp/w9.t3d none endmodel
rotate 0 0 0
endorigin
--- Koniec kodu ---
Zdarzenie ogr1_wja podpięte do toru, przy którym stoi w9 o nazwie ogr1.
Zdarzenie ogr2_wyj podpięte do toru, przy którym stoi w9 o nazwie ogr2.
1. Wjazd AI na ograniczenie.
W exe 355 były problemy ze zbyt gwałtowną reakcją - opisywałem to tu: http://eu07.pl/forum/index.php/topic,22058.msg307544.html#msg307544.
W exe 372 @Ra znacząco poprawił hamowanie - teraz wygląda to naprawdę dobrze. Siła hamowania jest tak dobrana, żeby płynnie osiągnąć właściwą prędkość przy ogr1.
2. Wyjazd z ograniczenia.
W exe 355 AI zaczynał przywracać prędkość rozkładową już kilkadziesiąt metrów przed ogr2. Ratowałem się takim rozwiązaniem:
--- Kod: ---// ograniczenie prędkości, parametry:
//---------------w9---------------
//param: textura, x, z, y, kat
//komorka do warunku zawsze spelnionego
node -1 0 DoNiczego memcell 111.0 111.0 111.0 Wait_for_orders 0 0 none endmemcell
//poczatek ograniczenia w9:
event (p1)_wja putvalues 0.0 none (p2) (p3) (p4) SetVelocity (p8) (p8) endevent
//
//koniec ograniczenia - ominiecie zbyt wczesnego przyspieszania wywolanego
//skanowaniem torow przez dodanie zawsze spelnionego warunku
//teraz AI nie widzi wczesniej predkosci przy skanowaniu
//i dowiaduje sie o niej dopiero gdy najezdza na tor z eventem
event (p1)_wyj multiple 1.0 DoNiczego (p1)_y condition memcompare * 0 0 endevent
event (p1)_y putvalues 0.0 none (p2) (p3) (p4) SetVelocity -1 -1 endevent
origin (p2) (p3) (p4)
rotate (p6) (p5) (p7)
node 400 0 none model 0 0 0 0 ip/pkp/w9.t3d none endmodel
rotate 0 0 0
endorigin
--- Koniec kodu ---
I to działało całkiem dobrze.
W exe 372 nie zmieniło się zachowanie AI dla pierwszego przykładu inc'a, ale niestety przestał działać zabieg z przykładu drugiego- zdarzenie się wywołuje, ale AI nie reaguje na nie.
W związku z powyższym mam 2 pytania (wiedząc że 372 jest wersją do testowania):
1) Czy docelowo możliwe jest zmuszenie AI do odpowiedniej reakcji na koniec ograniczenia?
Widziałbym to tak: gdy AI wyskanuje zdarzenie PutValues z parametrem SetVelocity nakazujące zwiększyć prędkość, AI czeka aż do wjechania na tor do którego to zdarzenie jest przypisane. W przypadku zdarzenia nakazującego zmniejszenie prędkości nic zmieniać nie trzeba, bo jest OK.
2) Jeśli odp. na pytanie pierwsze jest negatywna, to czy jest szansa żeby docelowo zdarzenie PutValues z parametrem SetVelocity działało też w przypadku wywołania go z innego zdarzenia condition (tak jak to było w 355)?
Ra:
--- Cytat: popatrz w 22 Września 2012, 18:33:33 ---Dążę do tego, żeby nie wstawiać Velocity w torach. W zamian tego chciałbym ograniczać prędkość przez SetVelocity umieszczone w inc'u przypisanym do toru gdzie ma się zaczynać i kończyć ograniczenie prędkości. Rozwiązanie to ma taką zaletę, że nie trzeba używać n-razy tego samego wpisu dla całej grupy torów. Potrzebne są tylko 2 wpisy w torach.
--- Koniec cytatu ---
To nie jest dobry kierunek. Jeśli jest ograniczenie (dla obydwu kierunków ruchu), powinno być ono wpisane w tory. Tylko jeśli ograniczenie jest w jednym kierunku (np. ze względu na widoczność), powinno być zrobione przez PutValues z SetVelocity. Używanie eventów tego typu jest "rozwiązaniem komplikującym" (nadmiarowym), natomiast każdy tor i tak ma parametr Velocity i umieszczenie go we wpisie nie powoduje zwiększenia ilości danych (jest bardziej "naturalne"). Innym argumentem jest np. to, że jeśli AI zostanie "zresetowane" na takim odcinku (pomiędzy W9), to nie będzie wiedziało o ograniczeniu.
--- Cytat: popatrz w 22 Września 2012, 18:33:33 ---W exe 372 nie zmieniło się zachowanie AI dla pierwszego przykładu inc'a, ale niestety przestał działać zabieg z przykładu drugiego- zdarzenie się wywołuje, ale AI nie reaguje na nie.
--- Koniec cytatu ---
Obecnie eventy są klasyfikowane jako skanowane albo kolejkowane. Jeśli PutValues zawiera SetVelocity w momencie wczytywania scenerii, zostanie zakwalifikowany jako skanowany i nie doda się do kolejki.
--- Cytat: popatrz w 22 Września 2012, 18:33:33 ---1) Czy docelowo możliwe jest zmuszenie AI do odpowiedniej reakcji na koniec ograniczenia?
Widziałbym to tak: gdy AI wyskanuje zdarzenie z SetVelocity nakazujące zwiększyć prędkość, AI czeka aż do wjechania na tor do którego to zdarzenie jest przypisane. W przypadku zdarzenia nakazującego zmniejszenie prędkości nic zmieniać nie trzeba, bo jest OK.
--- Koniec cytatu ---
SetVelocity jest standardowo używane w semaforach. Załóżmy taką sytuację: AI stoi przed semaforem mając prędkość startową 0.1. Semafor oddalony o 200m ma komendę SetVelocity 40 40. Wg tego, co napisałeś, AI ma czekać aż do wjechania na tor, do którego to zdarzenie jest przypisane. AI będzie więc czekać w nieskończoność, bo z aktualną prędkością 0.1 nie dowlecze się bliżej semafora. Być może trzeba by inaczej traktować SetVelocity umieszczone w PutValues niż w komórce odczytywanej przez GetValues.
--- Cytat: popatrz w 22 Września 2012, 18:33:33 ---2) Jeśli odp. na pytanie pierwsze jest negatywna, to czy jest szansa żeby docelowo SetVelocity działało też w przypadku wywołania go ze zdarzenia typu condition (tak jak w 355)?
--- Koniec cytatu ---
Nie. Eventy zakwalifikowane jako skanowane są odczytywane podczas skanowania i nie da się ich wywołać. Poza tym dodawanie takiego condition nie ma sensu, efekt będzie identyczny, jeśli da się od razu endevent.
Nawigacja
[#] Następna strona
Idź do wersji pełnej