Symulator EU07 (i nie tylko) > Poradniki
[CTR] Scenerie, wpisy, składy, zdarzenia - warto zajrzeć
jaras:
Po naprawieniu polskich liter na forum poznikały różne posty. Zaś ja sobie zachowałem wątek o zdarzeniach *_sem_info.
--- Cytat: pewien człowiek ---witam
Tworząc trasę natknąłem się na dziwny problem. SM03 napotykając na war_G_sem_info przejeżdża tak, jakby go nie było. Według programu EU07.exe zdarzenie się wyzwala. Czytałem scenery.doc, ale tam nie opisano tego problemu. Gdy próbowałem wstawić sem_info gdzie indziej to działało bez błędu.
Czy coś jest nie tak z eventem czy trzeba użyć czegoś jeszcze, żeby się zatrzymał? (war_G pokazuje sr1)
--- Koniec cytatu ---
Są różne sposoby przypisania zdarzenia do toru:
* event0 - wyzwalany, gdy pojazd z obsługą (np. lokomotywa) stoi na torze;
* event1 - wyzwalany, gdy pojazd z obsługą wjeżdża na tor od punktu końcowego (Point2) w kierunku punktu początkowego (Point1) toru;
* event2 - wyzwalany, gdy pojazd z obsługą wjeżdża na tor od punktu początkowego (Point1) w kierunku punktu końcowego (Point2) toru;
* eventalln - (n=0, 1, 2) - wyzwalany podobnie, jak powyżej, lecz zdarzenie wyzwala dowolny pojazd (zatem także np. wagon).Trzeba więc dobrze zwrócić uwagę na to, z której strony ma nadjeżdżać pociąg i, w związku z tym, z której strony ma "działać" zdarzenie.
Jednak pisząc tamtą odpowiedź pomyliłem z sobą event1 i event2. Scenery.doc zresztą ma to też niezbyt dokładnie wyjaśnione - stąd moja pomyłka.
Dlatego postanowiłem to sprawdzić doświadczalnie, aby móc to lepiej zapamiętać. Dzięki temu jednak, być może i pozostałe osoby lepiej zrozumieją przypisywanie zdarzeń do toru.
Wziąłem "pod lupę" plik *.inc pewnej trasy: było tam torowisko, zwrotniki i sygnalizatory. Nie ma sensu mówić co to za trasa, choć jej autor pewnie zaraz pozna, że to jego dzieło ;-).
Oto co znalazłem.
--- Kod: ---node -1 0 none498 track normal 100.0 1.435 0.15 25.0 20 0 flat vis
Rail_screw_used1 4 TpBpS-new2.tex 0.2 0.5 1.1
-35781.7 0.2 -3155.37 0.0 //point 1
-31.0898 0.0 -9.03052 //control vector 1
32.6016 0.0 5.74976 //control vector 2
-35877.3 0.2 -3177.6 0.0 //point 2
900.0
event1 podgdroginia_E_sem_info
event2 60n_s1
endtrack
--- Koniec kodu ---
To, oczywiście, jest definicja pewnego toru none498 w tej trasie.
Oto ten tor widoczny w scenerii, w Jet'cie i w symku:
(zaznaczony na czerwono)
Jak widać, przypisane są tutaj oba zdarzenia: event1 i event2. Popatrzmy do czego się one odnoszą:
--- Kod: ---include;SS5zpcpbY.inc;podgdroginia_E;-35795.7;0.0;-3156.63;-105.0;E;72;end
--- Koniec kodu ---
--- Kod: ---include;SBL3YN-pierwszy.inc;60n;-35785.5;0.0;-3153.02;73.721;A;podgdroginia_d;end
--- Koniec kodu ---
Zatem, podgdroginia_E jest zwykłym semaforem, a 60n - SBL-em. Widać je nawet na tym drugim screenie.
Zdarzenia
--- Kod: ---event1 podgdroginia_E_sem_info
event2 60n_s1
--- Koniec kodu ---
odnoszą się więc do:
* semafora podgdroginia_E - jest to informacja dla AI o stanie semafora, więc zdarzenie na torze musi się znajdować PRZED semaforem;
* SBL-a 60n - jest to zdarzenie podające S1 na SBL-u, więc zdarzenie to musi znajdować się ZA SBL-em.Wiemy ponadto, że współrzędna x "rośnie" z prawa na lewo scenerii, a kąt określa obrót w kierunku przeciwnym do wskazówek zegara.
Po współrzędnych oraz kącie obrotu widać, że:
* semafor podgdroginia_E jest obrócony w prawo (kąt: -105.0°) i stoi (xsem=-35795.7) bliżej punktu 1 toru none498 (x1=-35781.7);
* SBL 60n jest obrócony w lewo (kąt: 73.721°) i stoi (xsbl=-35785.5) bliżej punktu 1 toru none498 (x1=-35781.7), i po lewej stronie od semafora podgdroginia_E (xsem=-35795.7).Jest tu zatem sytuacja podobna do pokazanej na schemacie:
--- Kod: --- 60n =| |= E
| |
1____________________________________________2
--- Koniec kodu ---
Zatem, zgodnie z tym co zostało wcześniej napisane i co napisał twórca Scenery.doc, a także z tym, co podpowiada logika:
* Pociąg wjeżdżający na tor none498 od strony punktu 1 w kierunku punktu 2 powinien uaktywnić zdarzenie
--- Kod: ---event2 60n_s1
--- Koniec kodu ---
Inaczej mówiąc: zjeżdżając z toru po lewej stronie od none498 i wjeżdżając ZA SBL-a 60n powinien zmienić na nim sygnał na S1;
* Pociąg wjeżdżający na tor none498 od strony punktu 2 w kierunku punktu 1 powinien uaktywnić zdarzenie
--- Kod: ---event1 podgdroginia_E_sem_info
--- Koniec kodu ---
Inaczej mówiąc: wjeżdżając na tor none498 PRZED semaforem podgdroginia_E powinien otrzymać od niego informację o sygnale czyli prędkości jazdy.
Myślę, że teraz nie powinno być już kłopotów z odróżnieniem od siebie zdarzeń event1 (eventall1) oraz event2 (eventall2).
jaras:
Nie zdążyłem jednak zachować innego ciekawego wątku, w którym pojawił się problem, jak używać plików *.inc z semaforami.
No cóż... trzeba będzie więc to dokładniej opisać. To jak, moi Drodzy, rozbieramy semafor? ;-)
Nie nie, spokojnie, nie namawiam nikogo do niszczenia mienia kolei, lecz do zanalizowania jakiegoś pliku z przykładowym semaforem. :-)
Weźmy sobie dla przykładu plik SS5zpcpbI.inc, zawierający definicję semafora pięciokomorowego, który trzeba połączyć z poprzedzającą go tarczą ostrzegawczą. Taki semafor może zostać użyty np. jako wjazdowy do posterunku ruchu.
Już pierwsze komentarze zawarte w tym pliku:
--- Kod: ---// semafor 5-komorowy: p1=nazwa p2,p3,p4=lokacja, p5=rotacja, p6=symbol, p7=nazwa tarczy ostrzegawczej
//semafor ten stosuje sie jako wjazdowy, UWAGA - (p7) jest nazwa poprzedzającej tarczy ostrzegawczej sprzężonej z tym semaforem!
--- Koniec kodu ---
wiele wyjaśniają, ale wyjaśnimy też pozostałe rzeczy.
Jednak trzeba pamiętać o jednym. Wszędzie tam, gdzie w pliku *.inc pojawia się napis "(pn)" - zostanie on zastąpiony odpowiednim n-tym parametrem podczas wywoływania tego pliku komendą include:
--- Kod: ---include plik.inc par_1 par_2 par_3 ... par_n ... end
--- Koniec kodu ---
Pamiętajmy też, że do oddzielania od siebie parametrów mogą służyć: spacja, średnik, przecinek lub dowolny tzw. "biały znak" (np. tabulacja).
Zajrzyjmy więc do pliku SS5zpcpbI.inc.
--- Kod: ---origin (p2) (p3) (p4)
rotate 0 (p5) 0
--- Koniec kodu ---
Komenda origin powoduje, że wszystko co od tej pory zostanie umieszczone w scenerii będzie odnosiło się nie do globalnych współrzędnych w scenerii, lecz do współrzędnych względem parametrów (p2), (p3) i (p4). Zaś komenda rotate powoduje tymczasowy obrót całego układu współrzędnych o zadane kąty. Mogą to być wszystkie trzy płaszczyzny kątów (a więc i osie obrotów) w przestrzeni trójwymiarowej, lecz zwykle (tutaj także) chodzi tylko o obrót wokół osi pionowej.
--- Kod: ---//model semafora 5komorowego prostego:
node -1 0 (p1) model 0 0 0 0 PKP/head5_gyryw.t3d (p6) Lights 0 0 1 0 0 endmodel //glowica
node -1 0 none model 0 0 0 0 PKP/post-straight.t3d PKP/pkplight_manpost.tga endmodel //slup
node -1 0 none model 0 0 0 0 PKP/post-ladder-h56.t3d PKP/#pkplight_board.tga endmodel //drabinka
--- Koniec kodu ---
Tutaj, w wyznaczonym przez wspomniane parametry (p2), (p3) i (p4) punkcie wstawiany jest model semafora wraz ze wszystkimi jego składnikami. Oczywiście współrzędne teraz odnoszą się do tymczasowo wyznaczonego komendami origin i rotate nowego środka układu współrzednych, dlatego zamiast tych współrzędnych podane są same zera.
--- Kod: ---node 800 150 none lines 100 50 20 100.0 //linia zeby byl maszt widoczny z daleka
0.0 0.0 0.0 0.0 4.0 0.0
endline
--- Koniec kodu ---
Dodatkowo rysowana jest linia, która zapewni, że przy dalekiej odległości od semafora, mimo, że nie będzie widać jego słupa, bedzie widać choć cienką linię, dzięki czemu wiadomo będzie, że "jakiś" semafor tam stoi i trzeba uważać na sygnał na nim. Zauważmy tutaj parametry MaxDistance i MinDistance określające maksymalną i minimalną odległość, z której ta linia będzie widoczna.
--- Kod: ---rotate 0 0 0
endorigin
--- Koniec kodu ---
Koniec "rysowania" elementów semafora. Wracamy więc do globalnego układu współrzednych w scenerii, a także likwidujemy obrót i wracamy do pierwotnego położenia.
To były elementy graficzne, jednak w pliku *.inc zdefiniowane są niemniej ważne rzeczy, które sterują całym działaniem semafora i umożliwiają to, że np. pociąg sterowany przez AI bedzie odpowiednio reagował na podawane sygnały, czy też to, że sprzężona z semaforem tarcza ostrzegawcza będzie podawać sygnały odpowiednie do sygnału na tym semku.
Ja może teraz nie będę przedstawiał tych elementów kolejno, jak pojawiają się w pliku SS5zpcpbI.inc, lecz tak, jak będzie lepiej do wytłumaczenia ich działania. Każdy bowiem ma oczy oraz ten plik na dysku i może sobie samodzielnie zlokalizować omawiane przeze mnie sprawy.
--- Kod: ---//memcell do pamietania predkosci:
node -1 0 (p1)_sem_mem memcell (p2) (p3) (p4) SetVelocity 0.0 0.0 none endmemcell
--- Koniec kodu ---
To właściwie jeden z podstawowych elementów każdego sygnalizatora. Jest to komórka pamięci (o nazwie <nazwa_semafoara>_sem_mem), w której przechowywana będzie komenda dla AI, po której dostosuje on swą prędkość jazdy. Pamiętamy bowiem, że na PKP jest stosowana sygnalizacja prędkościowa, a wszystkie sygnały Sn, to nic innego jak informacje o nakazywanej prędkości jazdy.
Widać tutaj, że początkowo wpisana do tej komórki została komenda dla AI SetVelocity z parametrami: 0.0 i 0.0. Zajrzyjmy teraz tutaj, gdzie dowiemy się, jakie są w ogóle komendy oraz jakie mają parametry. Widzimy, że parametry te określają prędkość przy tym, a także przy następnym semaforze.
A kiedy ta komenda zostanie wydana przejeżdżającemu pojazdowi sterowanemu przez AI?
--- Kod: ---//odczyt z pamieci (zdarzenie przypisane do toru przy ktorym stoi semafor):
event (p1)_sem_info getvalues 1.0 (p1)_sem_mem endevent
--- Koniec kodu ---
Wtedy, gdy do toru, przy którym stoi semafor przypiszemy zdarzenie <nazwa_semafora>_sem_info. Bowiem zdarzenie typu getvalues, jak podaje Scenery.doc, odczytuje dane z komórki pamięci i wysyła je do obiektu dynamic (czyli pojazdu), który wywołał to zdarzenie.
I to już wszystko? Tak, bo to wystarczy do tego, aby semafor był "widoczny" przez AI.
Zatem pozostają teraz tylko zdarzenia sterujące jego działaniem.
--- Kod: ---//stany semafora:
event (p1)_s1 multiple 0 none (p1)_sem_ligh1 (p1)_sem_info_stop (p7)_os1 endevent
event (p1)_s2 multiple 0 none (p1)_sem_ligh2 (p1)_sem_info_vmax (p1)_sem_distinfo_vmax (p7)_os2 endevent
event (p1)_s3 multiple 0 none (p1)_sem_ligh3 (p1)_sem_info_vmax (p1)_sem_distinfo_v100 (p7)_os2 endevent
event (p1)_s4 multiple 0 none (p1)_sem_ligh4 (p1)_sem_info_vmax (p1)_sem_distinfo_v40 (p7)_os2 endevent
event (p1)_s5 multiple 0 none (p1)_sem_ligh5 (p1)_sem_info_vmax (p1)_sem_distinfo_stop (p7)_os2 endevent
event (p1)_s10 multiple 0 none (p1)_sem_ligh10 (p1)_sem_info_v40 (p1)_sem_distinfo_vmax (p7)_os4 endevent
event (p1)_s11 multiple 0 none (p1)_sem_ligh11 (p1)_sem_info_v40 (p1)_sem_distinfo_v100 (p7)_os4 endevent
event (p1)_s12 multiple 0 none (p1)_sem_ligh12 (p1)_sem_info_v40 (p1)_sem_distinfo_v40 (p7)_os4 endevent
event (p1)_s13 multiple 0 none (p1)_sem_ligh13 (p1)_sem_info_v40 (p1)_sem_distinfo_stop (p7)_os4 endevent
event (p1)_ms2 multiple 0 none (p1)_sem_lighs2 (p1)_sem_info_shunt2 endevent
event (p1)_sz1 multiple 0 none (p1)_sem_lighz1 (p1)_sem_info_v20 endevent
--- Koniec kodu ---
Te zdarzenia umożliwiają podanie na semforze dowolnego sygnału, jaki może być na nim ustawiony. Jak to się dzieje?
Widzimy, że każde z tych zdarzeń jest typu multiple co oznacza, że jest ono takim jakby zbiorczym wywołaniem poszczególnych zdarzeń składowych. No to popatrzmy z czego się te zdarzenia składają:[*](p1)_sem_ligh* - sterowanie światłami w komorach semafora,[*](p1)_sem_info_* - ustawienie informacji o prędkości przy tym semaforze,[*](p1)_sem_distinfo_* - ustawienie informacji o prędkości przy następnym semaforze,[*](p7)_* - ustawienie sygnału na sprzężonej z semaforem tarczy ostrzegawczej.[/list]Oczywiście pojęcie "ustawienie informacji o prędkości" oznacza właśnie omówione już wpisanie odpowiedniej komendy do zdefiniowanej komórki pamięci.
--- Kod: ---//zdarzenia wpisujace w memcell predkosci przy tym (info) i przy nastepnym (distinfo) semaforze:
event (p1)_sem_info_stop updatevalues 10.0 (p1)_sem_mem SetVelocity 0.0 0.0 endevent
event (p1)_sem_distinfo_stop updatevalues 1.0 (p1)_sem_mem SetVelocity * 0.0 endevent
event (p1)_sem_info_vmax updatevalues 1.0 (p1)_sem_mem SetVelocity -1 * endevent
event (p1)_sem_distinfo_vmax updatevalues 0.0 (p1)_sem_mem SetVelocity * -1 endevent
event (p1)_sem_distinfo_v100 updatevalues 1.0 (p1)_sem_mem SetVelocity * 100 endevent
event (p1)_sem_info_v40 updatevalues 1.0 (p1)_sem_mem SetVelocity 40 * endevent
event (p1)_sem_distinfo_v40 updatevalues 0.0 (p1)_sem_mem SetVelocity * 40 endevent
event (p1)_sem_info_v20 updatevalues 1.0 (p1)_sem_mem SetVelocity 20 0 endevent
// dziala tylko na pojazdy w trybie manewrowym:
event (p1)_sem_info_shunt2 updatevalues 1.0 (p1)_sem_mem ShuntVelocity 40 0 endevent
--- Koniec kodu ---
Tu zaś wpisywane są właśnie te komendy dla odpowiednich sygnałów.
Pamiętajmy, że w zdarzeniu typu updatevalues ostatnie trzy parametry określają co ma być wpisane do komórki pamięci. Komórka pamięci zaś może zapamiętać trzy wartości: jeden ciąg znaków oraz dwie liczby. Pamiętajmy też, że znak "*" w jednym z parametrów oznacza, że dana wartość już zapamiętana w komórce nie ma być zmieniana. Wszystko to zostało opisane w Scenery.doc.
Widzimy tutaj też, że dla zdarzenia ustawiającego sygnał Ms2 ("jazda manewrowa dozwolona") zastosowana jest inna komenda ShuntVelocity. Powoduje ona, że pojazdy pracujące w trybie jazdy manerwowej (przełącza je na ten tryb komenda Shunt) będą jechać obok tego semafora z prędkością podaną w pierwszym parametrze komendy. Wszystkie te komendy oraz ich parametry zostały opisane we wspomnianym pliku RFC-commands. Warto więc sobie ściągnąć ten plik i posługiwać się nim przy analizowaniu lub układaniu zdarzeń do scenerii.
--- Kod: ---//zdarzenia sterujace swiatlami:
event (p1)_sem_ligh1 lights 0.0 (p1) 0 0 1 0 0 endevent
event (p1)_sem_ligh2 lights 0.0 (p1) 1 0 0 0 0 endevent
event (p1)_sem_ligh3 lights 0.0 (p1) 2 0 0 0 0 endevent
event (p1)_sem_ligh4 lights 0.0 (p1) 0 2 0 0 0 endevent
event (p1)_sem_ligh5 lights 0.0 (p1) 0 1 0 0 0 endevent
event (p1)_sem_ligh10 lights 0.0 (p1) 1 0 0 1 0 endevent
event (p1)_sem_ligh11 lights 0.0 (p1) 2 0 0 1 0 endevent
event (p1)_sem_ligh12 lights 0.0 (p1) 0 2 0 1 0 endevent
event (p1)_sem_ligh13 lights 0.0 (p1) 0 1 0 1 0 endevent
event (p1)_sem_lighs2 lights 0.0 (p1) 0 0 0 0 1 endevent
event (p1)_sem_lighz1 lights 0.0 (p1) 0 0 1 0 2 endevent
--- Koniec kodu ---
Oczywiście sygnały te muszą być widoczne na semaforze, zatem tutaj są zapalane światła w odpowiednich komorach.
Zdarzenie typu lights powoduje ustawienie świateł w modelu głowicy semafora, to znaczy zmiany ich tekstur na powierzchniach nazwanych w pliku *.t3d jako Light_On00, Lignt_Off00, Light_On01, Light_Off01 itd. Tych parametrów definujących stany świateł powinno być tyle, ile jest takich powierzchni w pliku *.t3d. I teraz:[*]parametr o wartości 0 ustawia teksturę zdefiniowaną na powierzchni o nazwie Light_Offnn - czyli zgaszenie światła;[*]parametr o wartości 1 ustawia teksturę zdefiniowaną na powierzchni o nazwie Light_Onnn - czyli zaświecenie światła;[*]parametr o wartości 2 powoduje cykliczne przełączanie raz powierzchni o nazwie Light_Onnn, a raz o nazwie Light_Offnn - czyli migotanie światła.[/list]Oczywiście, jeśli mowa o pliku *.t3d modelu głowicy semafora - ma się na myśli model wstawiany do scenerii przez jedną z podanych na samym początku definicji:
--- Kod: ---node -1 0 (p1) model 0 0 0 0 PKP/head5_gyryw.t3d (p6) Lights 0 0 1 0 0 endmodel
--- Koniec kodu ---
No, teraz to już wiemy naprawdę wszystko co jest potrzebne. Daruję sobie omawianie zdarzeń które tworzą zależność semafora z SBL-ami, gdyż nie chcę nikomu namieszać w głowie, lecz zachęcam do samodzielnego zanalizowania tego.
Pamiętamy więc, że do toru przy semaforze przypisujemy zdarzenie <nazwa_semafora>_sem_info. Dodatkowo także warto przypisać do toru za semaforem zdarzenie <nazwa_semafora>_s1, co ustawi sygnał S1 po przejechaniu pociągu. Oczywiście to czy trzeba użyć zdarzenia event1 czy event2 zależy od kierunku jazdy pociągu i kierunku, dla którego obowiązuje semafor, co zostało opisane w poprzednim poście.
Spróbujmy już sami zanalizować w podobny sposób pliki *.inc dla tarcz ostrzegawczych lub manewrowych i popatrzeć jakie komórki pamięci one definiują, co do nich będzie wpisywane w zależności od sygnału, a także jakie zdarzenia do przypisania ich do toru są tam zdefiniowane.
Życząc zaś wszystkim przyjemnego rozbierania semaforów, przesyłam serdeczne pozdrowienia ;-).
Nawigacja
Idź do wersji pełnej