Pytania o eventy

[SKP]

Pokaż jeszcze raz dla pewności screena z Podglądu terenu, tylko pierw połącz tory.

[kamil1306]

Proszę.

[SKP]

Żadnych dziur w rozjeździe nie ma.

Dalej tak twierdzisz?

[kamil1306]

No są, jakoś nieuważnie patrzyłem, przepraszam. Jak taki nul track naprawić?

[SKP]

To na przyszłość patrz uważnie.

Punkty końcowe torów, między którymi jest NullTrack, muszą mieć takie same współrzędne. Zamień je zwyczajnie notatnikiem.

[pol102]

W tym logu nie widzę żadnych danych dotyczących wykolejenia. ZTCP to EXE 325 zapisywało takowe (derailed due np. to high speed).

Nie wiem dlaczego w logu nic nie ma. Tak się wykoleja.

Spakuj swoją scenerię z tym problemem i wstaw tu linka.

[popatrz]

Tmuszą mieć takie same współrzędne.

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: [Zaznacz]

// 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


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: [Zaznacz]

// 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

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]

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.

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.

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.

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.

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.

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.

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)?

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.

[popatrz]

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.

Ten argument przekonał mnie o niesłuszności mojego toku myślenia co do wstawiania eventów w ograniczeniach.

Mając na uwadze:

jeśli ograniczenie jest w jednym kierunku (np. ze względu na widoczność), powinno być zrobione przez PutValues z SetVelocity

i potencjalne sytuacje, gdy z uwagi na zbyt szybkie rozpoczęcie przyśpieszania bardzo długich składów, ostatnie wagony wykolejają się jeszcze na ograniczeniu, czy nie należałoby pomyśleć jednak o tej propozycji:

1) Czy docelowo możliwe jest zmuszenie AI do odpowiedniej reakcji na koniec ograniczenia?

Zmodyfikowałbym tylko mój wstępny pomysł dodając warunek minimalnej konfigurowalnej dodatkowym parametrem (albo określonej na stałe) prędkości, od której AI rozpoczynałby przyśpieszanie przy obiekcie inc.
Oczywiście pod warunkiem, że

inaczej traktować SetVelocity umieszczone w PutValues niż w komórce odczytywanej przez GetValues.

nie byłoby możliwe do wykonania.

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.

Rozumiem powody tego rozwiązania. Mała prośba o opublikowanie listy, które są skanowane a które kolejkowane.

Ogólnie, to dobrze jednak byłoby mieć wpływ na charakter eventów (np. przez dodanie prefiksu przy nazwie eventu). Po pierwsze wsteczna kompatybilność ze starszymi sceneriami (czyli mniej pracy przy przerabianiu) i określone założenia scenariusza, gdy scenarzysta chciałby mieć wpływ na np. zatrzymanie AI pod określonym warunkiem (np. zdarzenia losowe).

[Ra]

i potencjalne sytuacje, gdy z uwagi na zbyt szybkie rozpoczęcie przyśpieszania bardzo długich składów, ostatnie wagony wykolejają się jeszcze na ograniczeniu,

Przy ograniczeniu w jedną stronę nie ma raczej mowy o wykolejeniu z tego powodu.

Mała prośba o opublikowanie listy, które są skanowane a które kolejkowane.

Rozróżnienie eventów skanowanych i dodawanych do kolejki

Odkąd uruchomiono skanowanie torów w poszukiwaniu sygnałów wpływających na jazdę AI, zaistniała potrzeba odróżnienia eventów używanych podczas skanowania od tych dodawanych do kolejki. Obecnie (od wersji 361) takie rozróżnienie jest wykonywane na etapie wczytywania scenerii. Jeśli event PutValues zawiera komendę SetVelocity, ShuntVelocity albo zaczynającą się od PassengerStopPoint:, zostanie uznany jako uczestniczący w skanowaniu. Podobnie GetValues, jeśli połączona z nim komórka pamięci będzie zawierać pierwotnie komendę SetVelocity albo ShuntVelocity, nawet jeśli później komenda w komórce zostanie wymieniona na inną (jak dotąd nie używa się tego, wyjątkiem jest służba 3 na Linii 053).

Ogólnie, to dobrze jednak byłoby mieć wpływ na charakter eventów (np. przez dodanie prefiksu przy nazwie eventu). Po pierwsze wsteczna kompatybilność ze starszymi sceneriami (czyli mniej pracy przy przerabianiu) i określone założenia scenariusza, gdy scenarzysta chciałby mieć wpływ na np. zatrzymanie AI pod określonym warunkiem (np. zdarzenia losowe).

Moim zdaniem nie ma to sensu użytkowego. Konieczność dostosowania się do błędów i udziwnionych rozwiązań w istniejących sceneriach mnie nie przekonuje. Komenda SetVelocity jest ma charakter sygnałowy i trudno jest jednoznacznie określić, jak miałoby się zachować AI dostając taką komendę. Czy np. SetVelocity 20 20 wysłane nagle z kolejki eventów miało by wdrożyć nagłe hamowanie AI w celu jak najszybszego uzyskania zadanej prędkości?

Moim zdaniem system sterowania powinien być wewnętrznie spójny oraz umożliwiać uzyskanie potrzebnych efektów (np. manewry) możliwie małym kosztem dodatkowych wpisów. A to, że ktoś coś tam kiedyś zamieszał z komórkami pamięci stojącymi w przypadkowych miejscach i dziwnym trafem dawało to pożądane rezultaty w zachowaniu AI nie oznacza, że trzeba się tego trzymać.

[popatrz]

Przy ograniczeniu w jedną stronę nie ma raczej mowy o wykolejeniu z tego powodu.

Żeby nie wymyślać już konkretnych sytuacji, to po prostu sprowadzę tu podstawowy argument ważny przy symulatorach - realizmu. Dziwnie i "nieedukacyjnie" wygląda jak obserwujemy pociąg kierowany przez AI łamiący ograniczenie prędkości.

Dziękuję. Przyznam się bez bicia, że zajrzałem ale przeoczyłem to.

Moim zdaniem nie ma to sensu użytkowego. Konieczność dostosowania się do błędów i udziwnionych rozwiązań w istniejących sceneriach mnie nie przekonuje.

No tak, tworzone były różne obejścia bo "było tak łatwiej" albo nie było innych możliwości. Pierwszym przypadkiem bym się faktycznie nie przejmował. W drugim przypadku, gdy jest jakiś pomysł w głowie i inaczej nie da się tego zrobić, to szuka się różnych "furtek". Np. żeby zatrzymać AI trzeba schować semafor pod ziemię...

Komenda SetVelocity jest ma charakter sygnałowy i trudno jest jednoznacznie określić, jak miałoby się zachować AI dostając taką komendę. Czy np. SetVelocity 20 20 wysłane nagle z kolejki eventów miało by wdrożyć nagłe hamowanie AI w celu jak najszybszego uzyskania zadanej prędkości?

Służbowe. A gdy np. SetVelocity 20+ 20+ to nagłe.

[Ra]

Żeby nie wymyślać już konkretnych sytuacji, to po prostu sprowadzę tu podstawowy argument ważny przy symulatorach - realizmu. Dziwnie i "nieedukacyjnie" wygląda jak obserwujemy pociąg kierowany przez AI łamiący ograniczenie prędkości.

AI ma przede wszystkim jeździć i nie sprawiać problemów, a nie być wzorem do naśladowania. Jak dotąd, z jednostronnym ograniczeniem spotkałem się tylko na odcinku Kozłów - Psary, ze względu na słabą widoczność z przejazdu na łuku. Poza tym, metodologia mojej pracy jest następująca: przysyłasz mi scenerię, na której AI się zachowuje nieprawidłowo, ja poprawiam kod, aż zacznie działać, albo dochodzę do wniosku, że coś trzeba zrobić w inny sposób. Jednocześnie zmiany będą weryfikowane na scenerii o znacznym ruchu AI (jazda z rozkładami, skomplikowane manewry).

W drugim przypadku, gdy jest jakiś pomysł w głowie i inaczej nie da się tego zrobić, to szuka się różnych "furtek". Np. żeby zatrzymać AI trzeba schować semafor pod ziemię...

Wirtualne semafory są OK, pod warunkiem, że są zrobione zgodnie z zasadami, tzn. komórka pamięci jest przy torze, którym ma sterować, a nie w OXYZ, a komendy do niej wpisywane pokrywają się ze sterowaniem semaforem. Natomiast jeśli wstawia się wirtualne semafory przy peronie na każdej stacji, bo się komuś nie chce pisać rozkładu, to już poniekąd przegięcie jest.

Służbowe. A gdy np. SetVelocity 20+ 20+ to nagłe.

Nie spotkałem się z taką postacią liczb zmiennoprzecinkowych.

[popatrz]

OK. Z moimi "małymi" potrzebami nie mam szans.

Nie spotkałem się z taką postacią liczb zmiennoprzecinkowych.

Ja też nie. :D
Są w C możliwości zmiany typu zmiennych na string i konwersji na int/long.
Te "20+" było propozycją rzuconą na poczekaniu. Nie znam typów argumentów tej funkcji w C.
Bez takich ingerencji w kod można zrobić np 100020 i już.
 

[Ra]

OK. Z moimi "małymi" potrzebami nie mam szans.

Na co?

Są w C możliwości zmiany typu zmiennych na string i konwersji na int/long. Te "20+" było propozycją rzuconą na poczekaniu. Nie znam typów argumentów tej funkcji w C. Bez takich ingerencji w kod można zrobić np 100020 i już.

Raczej chodzi o to, że argumenty liczbowe komend są przechowywane jako liczby zmiennoprzecinkowe. Informacje o jakiś tam plusach trzeba by rozpoznawać i umieszczać osobno. I nie było by to zgodne wstecz. Poza tym, czy na pewno to, co chcesz osiągnąć nie da się zrobić inny, prostszy sposób?

Być może W9 na końcu ograniczenia powinien mieć komendę np. SetVelocity 40 -1, gdzie 40 jest przykładową prędkością ograniczenia. Aczkolwiek rozważania teoretyczne bez scenerii testowej nie mają dużej wartości, a ja na preparowanie scenerii testowych nie mam specjalnie czasu.

[popatrz]

Rozwinę ten skrót myślowy: Na początku budowania scenerii zauważyłem coś, co mi przeszkadza w AI i to opisałem (warunki dla setvelocity i zbyt szybkie przyspieszanie). Dla mnie to dosyć ważne, być może dla większości nie.
Jednocześnie wiem, że nie powinienem zbyt mocno nakłaniać do korygowania rzeczy, które nie są dla innych ważne bo sam jeszcze nie zrobiłem wystarczająco dużo.
Zadowolę się więc tym co jest, postaram się rozwiązać to inaczej. Dzięki za wyjaśnienia.
  Dodano: 25 Września 2012, 17:00:32

Być może W9 na końcu ograniczenia powinien mieć komendę np. SetVelocity 40 -1

Sprawdziłem na swojej scenerii testowej. Niestety nie.

[Ra]

Być może trzeba by tak zrobić z SetVelocity, że pierwszy parametr określa dozwoloną prędkość przed semaforem (eventem/komórką pamięci), a drugi po jego przekroczeniu. Ale może się pojawić konieczność poprawienia wszystkich semaforów, bo teraz przy S1 jest wpisywane SetVelocity 0 0, co uniemożliwiło by dojechanie do semafora i AI stawało by już w momencie pierwszego zobaczenia takiej komendy podczas skanowania. Być może dla S1 należało by wpisywać SetVelocity -1 0, czyli zezwolenie na jazdę przed semaforem i zakaz dalszej jazdy. Ale wtedy pierwsza prędkość danego semafora powinna być ustawiana przez wcześniejszy semafor w momencie zezwolenia na jazdę... W każdym razie, jest pewien problem koncepcyjny w zakresie ustalania prędkości AI przed miejscem eventu/komórki pamięci.

[popatrz]

Ma Kolega w mojej osobie  "gorącego orędownika" tego pomysłu. Jeśli będzie potrzeba i zapadnie odpowiednia decyzja, podejmuję się zmiany obecnych inców, w których występuje SetVelocity.

[Ra]

Popatrzyłem sobie na przykłady semaforów, m.in. SBL. Tam wygląda to tak, jakby pierwszy parametr określał prędkość za semaforem, natomiast drugi zapamiętywał stan następnego i służył do warunkowego wyświetlenia sygnału. Czyli tak naprawdę dla AI istotny jest pierwszy, a drugi nie przedstawia żadnej wartości. Wyjątkiem jest SetVelocity 0 20 w SBL, który oznacza "zatrzymaj się i rusz". Z drugiej strony, pierwszy parametr w semaforze powoduje wysłanie wewnętrznej komendy SetVelocity, która powoduje m.in. ustawienie trybu jazdy pociągowej i maksymalnej prędkości (VelActual).

I teraz dalej widzę dwa rozwiązania. Albo inaczej interpretować parametry dla PutValues (niż dla semaforów z GetValues), albo po prostu rozpoznawać PutValues i traktować je niczym ograniczenie wpisane w tor. Na pewno jeśli koniec ograniczenia będzie sygnalizowany przez SetVelocity -1 -1, to AI nie będzie miało informacji o prędkości na ograniczeniu, jeśli nie "zachowa w pamięci" momentu wjazdu. I na pewno wpisywanie prędkości w tory jest najpewniejszą metodą uzyskania odpowiedniej prędkości przez AI.

[popatrz]

AI można uruchomić przez SHIFT+q albo z eventa (jeśli są inne możliwości to proszę mnie oczywiście poprawić).
Jeśli nie zdarzają się sytuacje (też nie jestem tego pewien), że AI sam z siebie się wyłącza to może:
W pierwszym przypadku ustalenie VelActual mogłoby następować przez ustalenie prędkości przed uruchomieniem AI. Wydaje mi się to logiczne - przekazujemy "pałeczkę" w ustalonym stanie jazdy, a dodatkowo możemy stosować jako autopilot na odcinkach między semaforami prowadząc sami pociąg.
Drugi przypadek to po prostu przekazanie prędkości w nowy-zwykły sposób przez SetVelocity v_do_1sem v_po_1sem i/lub prędkość w trainset.

Sam już nie wiem, czy to nie typowa sytuacja w stylu "zamienił stryjek siekierkę na kijek".
Może jakaś ankietka dla developerów, czy to w ogóle przydatne?

[Ra]

W pierwszym przypadku ustalenie VelActual mogłoby następować przez ustalenie prędkości przed uruchomieniem AI. Wydaje mi się to logiczne - przekazujemy "pałeczkę" w ustalonym stanie jazdy, a dodatkowo możemy stosować jako autopilot na odcinkach między semaforami prowadząc sami pociąg.

To się nie sprawdzało. Wystarczyło włączyć jazdę na pierwszą pozycję, następnie uaktywnić AI i dalej się wlokło z prędkością 2km/h. Teraz, po włączeniu AI dodałem reset skanowania na wszelki wypadek. Zdarzało się bowiem, że przy ręcznym prowadzeniu udało się przejechać jakieś sygnały, które potem wisiały i nie szło ich skasować z tabelki mimo przejechania paru kilometrów.

Może jakaś ankietka dla developerów, czy to w ogóle przydatne?

Słabo to widzę.

[firleju]

A może po prostu nowa komenda do określania prędkości na szlaku?

[SKP]

Hmmm, ZTCW to na niejednej misji od dawna są wykorzystywane eventy LineInfo.

[Sawi]

Są owszem, ale jak dobrze kojarzę, to tylko przy użyciu wskaźnika W5 http://eu07.pl/forum/index.php/topic,4591.msg45701.html#msg45701 Jeśli nie, to proszę mnie popraw.

[SKP]

Zawsze możesz mieć niewidzialny wskaźnik W5 ;) Zresztą to i tak tylko do określenia prędkości drogowej, robienie tą metodą zwykłych ograniczeń jest niewykonalne.

[MasterYoda]

Kod: [Zaznacz]

event keyCtrl05 multiple 0 none losujwjazd_ir wjazd_ir jamnik_kalowo endevent 

event wjazd_ir multiple 30 none wjazd_ir1 wjazd_ir2 wjazd_ir3 endevent

event wjazd_ir1 multiple 35 none stacja_b_zwr20- stacja_b_zwr26- stacja_b_p_s13 wyjazd3 woodkid_s5 endevent

event wjazd_ir2 multiple 10 none stacja_b_p_s5 woodkid_s2  endevent

event wjazd_ir3 multiple 15 none stacja_b_p_s13 woodkid_s10 stacja_b_zwr21- stacja_b_zwr22- endevent

event wyjazd1 multiple 80 none stacja_b_c_s2 wyjazd_stacja endevent

event wyjazd2 multiple 80 none stacja_b_e_s10 stacja_b_zwr08- stacja_b_zwr09- stacja_b_zwr10+ stacja_b_zwr12+ wyjazd_stacja endevent

event wyjazd3 multiple 80 none stacja_b_g_s10 stacja_b_zwr05- stacja_b_zwr15- wyjazd_stacja endevent

node -1 0 memwjazd_ir memcell 0.0 0.0 0.0 * 0 0 none endmemcell

node -1 0 memwjazd_ir memcell 1.0 1.0 1.0 * 0 0 none endmemcell
 event up1wjazd_ir updatevalues 0.0 memwjazd_ir * 1 1 endevent
 event up2wjazd_ir updatevalues 0.0 memwjazd_ir * 2 2 endevent
 event losuj1wjazd_ir multiple 0.0 none up1wjazd_ir condition propability 0.5 endevent
 event losuj2_1wjazd_ir multiple 0.0 none  up2wjazd_ir condition propability 0.5 endevent
 event losuj2wjazd_ir multiple 2.0 memwjazd_ir losuj2_1wjazd_ir condition memcompare * 0 0 endevent
 event losujwjazd_ir multiple 0.0 none losuj1wjazd_ir losuj2wjazd_ir endevent
 event mul1wjazd_ir multiple 0.0 memwjazd_ir wjazd_ir1 condition memcompare * 0 0 endevent
 event mul2wjazd_ir multiple 0.0 memwjazd_ir wjazd_ir2 condition memcompare * 1 1 endevent
 event mul3wjazd_ir multiple 0.0 memwjazd_ir wjazd_ir3 condition memcompare * 2 2 endevent
 event wjazd_ir multiple 0.0 none mul1wjazd_ir mul2wjazd_ir mul3wjazd_ir endevent


Panowie proszę o sprawdzenie tego losowego. Za każdym razem ta sama opcja mi się pokazuje. Czy coś jest nie tak z wartościami prawdopodobieństwa?

[SKP]

Gdyby można było jednocześnie odpalić zdarzenie losujące oraz zdarzenie główne, to podpiąłbym je w generatorze pod jednego multiple. Niestety tak nie jest, w związku z tym w pomocy do generatora napisałem:

Zdarzenie losujące (podane w dolnym polu) należy koniecznie uruchomić co najmniej 10 sekund przed wykonaniem właściwego zdarzenia. W przeciwnym wypadku wynik będzie "sfałszowany". Najlepiej to uczynić od razu po uruchomieniu misji.

[MKUśniaki]

Czy jeżeli da się wyzwolenie eventu poprzez shift +... to trzeba zmieniać coś we wpisach torów tak jak to się robi przy wyzwoleniu na wjazd na odcinek izolowany?

[Benek]

Nie. Eventy przez Shift są oderwane od torów. Jednak obecne standardy mówią o tym, by rozpoczynać misję (chyba, że masz na myśli coś innego) poprzez eventlaucher odpalany o odpowiedniej godzinie.

Kod: [Zaznacz]

node -1 0 turow eventlauncher 0.0 0.0 0.0 -1 none 0130 turow_start none endZdarzenie turow załączy się, gdy zegarek w symulatorze pokaże 01:30.