Symulator EU07 (i nie tylko) > Pomoc w tworzeniu
Pytania o eventy
Ra:
--- Cytat: popatrz w 25 Września 2012, 15:54:02 ---OK. Z moimi "małymi" potrzebami nie mam szans.
--- Koniec cytatu ---
Na co?
--- Cytat: popatrz w 25 Września 2012, 15:54:02 ---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ż.
--- Koniec cytatu ---
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
--- Cytat: Ra w 25 Września 2012, 16:08:51 ---Być może W9 na końcu ograniczenia powinien mieć komendę np. SetVelocity 40 -1
--- Koniec cytatu ---
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.
Nawigacja
[#] Następna strona
Idź do wersji pełnej