[CTR] Scenerie, wpisy, składy, zdarzenia - warto zajrzeć

[jaras]

Plik scenerii jest plikiem tekstowym, zawierającym różne komendy całkowicie definiujące wygląd scenerii, wszelkie obiekty poruszające się po torach, a także działanie tzw. zdarzeń (zjawisk, które mogą następować w ustalonej kolejności, a także w wyniku reakcji na inne zdarzenia). Szczegółowy opis tych komend czytelnik znajdzie w pliku:

http://rainsted.com/pl/Symulator/MaSzyna/Scenery.doc

Jednak co wpisać do scenerii, aby nie jechać składem zdefiniowanym przez jej autora, lecz zdefiniowanym przez siebie?

Otwórzmy plik *.scn z wybraną scenerią. Jest to główny plik, gdyż może on za pomocą komendy "include" dołączać też inne pliki. Ale nas interesuje w tym momencie tylko ten główny plik. Jeśli nie jest on zbyt duży objętościowo, można go otworzyć nawet w systemowym Notatniku. Jeśli jest większy, polecam np. WordPad z Windows 98 albo też MS Word - wówczas trzeba pilnować, aby przy późniejszym zapisie zapisać ten plik w postaci czysto tekstowej - bez żadnego formatowania, a nie jako dokument Word (który nie jest już plikiem czysto tekstowym).

Poszukajmy w tym pliku ciągu

Kod: [Zaznacz]

FirstInitsamotnie stojącego w jakimś wierszu tego pliku. W kolejnych wierszach, poniżej tego ciągu znajdują się już wpisy wszelkich obiektów ruchomych w scenerii. Nie tylko pociągów, ale też i tzw. "przeszkadzajek" czyli np. samochodów na ulicach (w scenerii "Quarkowo" po peronie łazi sobie sokista - to też jest obiekt ruchomy zdefiniowany za pomocą takich wpisów).

No, to przyjrzyjmy się tym wpisom:

Kod: [Zaznacz]

trainset none zwrotnicowo_f03 0.0 0.0
//$o Pociąg osobowy - wpierw manewruj zgodnie z semaforami Tm (wypchaj skład na boczny tor ale nie odczepiaj go). Po wyciągnięciu składu na peron odczep loka i manewruj zgodnie z Tm aby doczepić loka z drugiej strony. No a potem ..... ciuch ciuch ... uuuuuu..... uuuuuu !!! ;)
node -1 0 EU07-424 dynamic PKP\EU07 eu07-424 303E 0.0 reardriver 3 0 enddynamic
node -1 0 505120-00351-4 dynamic PKP\Adu none 112a 0.0 nobody 3 2 Passengers enddynamic
node -1 0 505120-00351-4 dynamic PKP\Bdhpumn none bdhpumn 0.0 nobody 3 20 Passengers enddynamic
node -1 0 505120-00351-4 dynamic PKP\Bdhpumn none bdhpumn 0.0 nobody 3 25 Passengers enddynamic
node -1 0 505120-00351-4 dynamic PKP\Bdhpumn none bdhpumn 0.0 nobody 3 10 Passengers enddynamic
node -1 0 505120-00351-4 dynamic PKP\Bdhpumn none bdhpumn 0.0 nobody 0 21 Passengers enddynamic
endtrainset
Tutaj podałem przykładowy wpis ze scenerii "Zwrotnicowo". Co my tu mamy?

Należy pamiętać, że cała definicja składu musi się zawierać w obrębie komendy "trainset". Komenda ta składa się z tzw. ograniczników:

Kod: [Zaznacz]

trainset ...
...
endtrainsetKomenda ta posiada swoje parametry:

[*]TrainName - jest to nazwa pociągu. W przykładzie mamy tutaj "none", co oznacza, że nie definujemy jej. Jeśli jednak występuje, symulator przy wczytywaniu scenerii będzie próbował wczytać też plik (o takiej nazwie jak zdefiniowana i rozszerzeniu .txt) z rozkładem jazdy tego pociągu. Brak tego pliku zasygnalizowany zostanie komunikatem błędu (dobrze znany Error @-8).

[*]Track - nazwa toru, na którym zostanie ustawiony skład. W naszym przykładzie jest to tor o nazwie "zwrotnicowo_f03". W scenerii niektórym torom można nadawać nazwy (odsyłam tutaj do pliku Scenery.doc). Nazwa w tym parametrze musi odpowiadać istniejącemu w scenerii torowi, gdyż inaczej symulator nie będzie mógł ustawić składu (wszak pociągi jeżdżą po torach, nie? ;-) i pojawi się wówczas komunikat błędu.

[*]Dist (ang. distance - odległość) - odległość od początku toru. Każdy tor w scenerii ma swój początek i koniec - zdanie to wydawałoby się banalne, gdyby nie to, że w przypadku naszego symulatora, tor nie jest kijem (który zawsze ma dwa końce ;-), zatem tutaj początek nie jest tym samym co koniec (znowu odsyłam do Scenery.doc - opis parametrów komendy "node ... track ... "). A parametr ten określa odległość pojazdu od początku toru w metrach. W powyższym przykładzie skład będzie stał na samym początku toru (odległość 0.0 m). Oczywiście ten parametr jest wymagany, gdyż symulatorowi musi być znana dokładna lokalizacja składu.

[*]Vel (ang. velocity - prędkość) - prędkość początkowa składu. Tutaj mamy wartość 0.0. Za pomocą tego parametru można zdefiniować skład, który zaraz po załadowaniu scenerii od razu porusza się z podaną prędkością wyrażoną w km/h. Jasne chyba jest to, że wartość 0.0 tutaj powoduje, że skład nie porusza się.[/list]To wszystko, jeśli chodzi o parametry komendy "trainset". A co mamy w jej "wnętrzu"?

W przytoczonym przykładzie napotykany na taki oto zapis:

Kod: [Zaznacz]

//$o Pociąg osobowy - wpierw manewruj zgodnie z semaforami Tm (wypchaj skład na boczny tor ale nie odczepiaj go). Po wyciągnięciu składu na peron odczep loka i manewruj zgodnie z Tm aby doczepić loka z drugiej strony. No a potem ..... ciuch ciuch ... uuuuuu..... uuuuuu !!! ;)Z uważnej lektury pliku Scenery.doc wynika, że w kolejnych wierszach pliku scenerii wszystko, co znajduje się za znakami "//" stanowi tylko komentarz i jest ignorowane przez symulator. Wszystko się zgadza - powyższy zapis również jest ignorowany przez symulator. Jednak, gdy zechcemy wystartować symulator za pomocą dołączonego startera (start.exe), to po zaznaczeniu w jego okienku tej scenerii zobaczymy taki oto opis:

Pociąg osobowy - wpierw manewruj zgodnie z semaforami Tm (wypchaj skład na boczny tor ale nie odczepiaj go). Po wyciągnięciu składu na peron odczep loka i manewruj zgodnie z Tm aby doczepić loka z drugiej strony. No a potem ..... ciuch ciuch ... uuuuuu..... uuuuuu !!! ;)

Wygodnie zatem jest tutaj, po znakach "//$o " umieścić opis, który potem pozwoli przypomnieć sobie podczas startu symulatora, jaki jest wybierany w okienku startera skład i jaką "misję" nalezy nim wykonać. Opis ten powinien być w jednym wierszu, choćby nie wiem, jak by był długi - nie można go kontynuować w wierszu następnym.

Po wpisie definiujemy już skład. Mogą to być samotnie stojące gdzieś na bocznicy wagony, może to być lokomotywa "luzem", a może to być też cały pociąg (także z więcej niż jedną lokomotywą i tzw. sterowaniem ukrotionym).

Przytoczę tutaj dwie pierwsze jednostki z przykładu "Zwrotnicowa" - lokomotywę i wagon:

Kod: [Zaznacz]

node -1 0 EU07-424 dynamic PKP\EU07 eu07-424 303E 0.0 reardriver 3 0 enddynamic
node -1 0 505120-00351-4 dynamic PKP\Adu none 112a 0.0 nobody 3 2 Passengers enddynamicJak widzimy, jest to zwykła komenda "node ... dynamic ... " służąca do umieszczenia w scenerii obiektu ruchomego. W zależności od tego, czy komenda ta jest albo nie jest w kontekście komendy "trainset" - istnieją dwie, nieco od siebie się różniące wersje tej komendy.

Tutaj jednak mamy ją w kontekście "trainset". Zatem parametry tej wersji komendy "node ... dynamic ... " zostaną omówione poniżej:

[*]Najpierw są parametry wchodzące w skład każdej komendy "node" bez względu na jej rodzaj:

[*]MaxDistance - parametr ten określa maksymalną odległość, z jakiej obiekt będzie widoczny. Wartość -1 nie określa tej odległości - obiekt będzie widoczny wówczas z każdej odległości. Polecam do przeczytania rozpoczęty przez mnie wątek o tym parametrze i jego wpływie na wydajność grafiki w symulatorze.

[*]MinDistance - jest to najmniejsza odległość, z jakiej obiekt będzie widoczny. Nie widzę sensu dawać tutaj innej wartości, niż 0.0, aby obiekt ten (tu: jednostka) był widoczny też z bardzo bliska.

[*]Name - nazwa obiektu. Można tutaj wpisać nazwę pojazdu, np. EU07-424. Nie ma ona zbyt wielkiego znaczenia, jednak program start.exe robi z niej użytek taki, że potrafi w swoim oknie, przy pomocy małych obrazków wyświetlić poszczególne pojazdy w składzie. Dobrze jest więc każdej jednostce nadać nazwę.

[*]Type - tutaj następuje ciąg "dynamic" określający, że chodzi o obiekt ruchomy.[/list]
[*]Dalej są już właściwe parametry komendy:

[*]Directory - podkatalog w obrębie podkatalogu dynamic katalogu z symulatorem (a konkretnie, z plikiem eu07.exe), w którym znajduje się definicja obiektu zawarta np. w plikach *.mmd. Zapewne trochę zamieszałem, więc już spieszę z wyjaśnieniami. W przykładzie ze "Zwrotnicowa" lokomotywa ma tutaj wpisane "PKP\EU07". Oznacza to, że definicji obiektu reprezentującego lokomotywę EU07 w tym składzie należy szukać (symulator ma szukać) w podkatalogu dynamic\PKP\EU07 katalogu z symulatorem.

[*]ReplacableSkin - ten parametr sprawia użytkownikom taki kłopot, że po niewłaściwym jego ustawieniu często mamy białe (bez tekstur) wagony lub lokomotywy. A sprawa jest bardzo prosta. O ile w pliku określającym budowę modelu pojazdu (plik *.t3d w katalogu określonym w wyżej omówionym parametrze Directory) tekstury z nadwoziem pojazdu określone są przy pomocy zapisu "replacableskin.bmp", można (a właściwie trzeba) wówczas w tym parametrze podać nazwę pliku z teksturą, która ma stanowić elementy nadwozia pojazdu. W przypadku, gdy plik z tą teksturą jest typu *.bmp, można już nie pisać tego rozszerzenia, dla np. *.tga - trzeba ją wpisać. Jeśli zaś w pliku *.t3d tego pojazdu "na sztywno" zostały podane tekstury nadwozia, wówczas ten parametr niczego nie zmieni i można tutaj wpisać "none". Autorzy modeli pojazdów coraz częściej odchodzą od tego, by ustawiać te tekstury na stałe w modelu. Na przykład tutaj mamy podane "eu07-424". Wszak różnych lokomotyw EU07 jest cała masa - mają inne malowanie, inne szczegóły nadwozia itp. Jednak autorowi scenerii "Zwrotnicowo" chodziło konkretnie o lokomtywę EU07-424, dla której tekstura nadwozia zawarta jest w pliku dynamic\PKP\EU07\eu07-424.bmp. Zatem ten parametr służy rozróżnieniu wyglądu tych pojadów od siebie.

[*]Type - charakterystyka pojazdu. Jest to nazwa pliku o rozszerzeniu .chk zawartego w podkatalogu określonym parametrem Directory omówionym powyżej. Ważne: samego rozszerzenia (.chk) nazwy tego pliku nie piszemy. W naszym przykładzie dla lokomotywy EU07, jej charakterystyka będzie wczytana z pliku dynamic\PKP\EU07\303E.chk.

[*]Dist - odległość od początku toru (według dokumentacji w pliku Scenery.doc). Mam jednak tutaj pewne wątpliwości co do sensu istnienia albo funkcjonalności tego parametru (przecież istnieje już taki parametr w komendzie "trainset"). Nie jestem pewny, czy nie chodzi tutaj o odległość danego pojazdu od pojazdu bezpośrednio go poprzedzającego. W każdym razie, jak zauważyłem, zawsze ten parametr ma wartość 0.0.

[*]CabOccupancy - tutaj określamy, jaką w danym pojeździe funkcję może pełnić użytkownik tego składu. Na przykład w lokomotywie można być maszynistą, a w wagonie pasażerem. Implementacja tego parametru prawdopodobnie jest wciąż jeszcze nie dokończona. W każdym jednak razie może on przyjmować następujące wartości:

[*]nobody - brak jakiejkolwiek obsługi tego pojazdu;[*]headdriver - maszynista w tej kabinie lokomotywy, która skierowana jest w kierunku początku toru (co to jest początek i koniec toru - opisałem przy okazji omawiania parametru "Dist" komendy "trainset");[*]reardriver - maszynista w drugiej kabinie (czyli tej, która skierowana jest w kierunku końca toru);[*]passenger - pasażer (można sobie po prostu jechać w wagonie);[*]conductor - (wg Scenery.doc) konduktor - znaczenie tego również nie jest dla mnie jasne.[/list]Jedna sprawa: gdy startujemy symulator za pomocą programu start.exe, na skutek błedu, nie uwzględnia on obsługi (definiowanej tym parametrem) innej niż pierwsza jednostka - "daje" on symulatorowi tylko pierwszy taki możliwy pojazd. Konsekwencją tego błędu jest to, że nie można np. jechać sobie jako pasażer ("passenger") w wagonie pociągu, który ma być sterowany przez maszynistę ("headdriver" lub "reardriver"), gdyż przecież lokomotywa jest przed wagonem. Jeśli jednak umieścimy odpowiedni wpis w pliku eu07.ini, będzie można sobie jechać w dowolnej zdefiniowanej jednostce.

[*]Coupler - typ sprzęgu z następną jednostką. Wartość ta jest liczbą, lecz będącą tzw. kombinacją bitową. Ustalamy więc najpierw, czym nasz pojazd będzie sprzężony z kolejną jednostką w składzie. Wybrać można spośród następujących pozycji:

[*]1 - hak spinający z sobą jednostki;[*]2 - przewód pneumatyczny (służący do hamowania składu);[*]4 - przewód do sterowania ukrotnionego;[*]... - ten dokument defniuje jeszcze inne rodzaje sprzęgów, jednak pierwsze trzy są najczęściej używane;[/list]a potem dodajemy do siebie liczby stojące przy wybranych pozycjach. Na przykład w "Zwrotnicowie" w omawianym składzie lokomotywa EU07-424 połączona będzie ze stojącym za nią wagonem Adu przy pomocy haka i przewodu pneumatycznego (3=1+2). Nie jestem pewny, ale nie widzę sensu ustawiać tego parametru na wartość inną niż 0 (co oznacza brak sprzęgu) dla ostatniej jednostki w składzie - nie wiem, czy nie jest to przyczyną kłopotów z ruszeniem "kibelkiem" (EN57) w niektórych seceneriach (wykorzystują one sprzęg ukrotniony - wartość 7=1+2+4, a wtedy ostatni człon jest połączony z... niczym i symulator nie może nim sterować - to taka moja nie sprawdzona hipoteza).

[*]Load - ładunek dla danej jednostki. Jest to ilość ładunku w tej jednostce wyrażona w jednostkach określonych w pliku *.chk (określonym w parametrze Type wymienionym wcześniej - patrz: opis parametru LoadType poniżej). Oczywiście 0 określa, że jednostka jest pusta (nie załadowana) - wówczas nie ma też kolejnego parametru: LoadType. Dla pasażerów ("Passengers" w LoadType) w pierwszym wagonie składu w "Zwrotnicowie" ustawiona została wartość 2 (zatem w tym wagonie jedzie dwóch pasażerów), a dla drugiego wagonu - wartość 20 (dwudziestu pasażerów); dla lokomotywy zaś jest 0 - nie ma ona więc żadnego ładunku (przyjmując, że maszynisty nie uwzględniamy jako "ładunek" ;-). Parametr ten jest o tyle ważny, że symulator na jego podstawie może wyliczyć wagę składu i zastosować wszystkie wynikające z tej wagi konsekwencje w fizyce ruchu tego składu. Inaczej przecież prowadzi się cięższy skład, a inaczej lżejszy.

[*]LoadType - określamy tutaj typ ładunku. Bardzo ważnym jest to, że ten parametr nie występuje, gdy wartość parametru Load równa jest 0. Jako typy ładunku można podawać zwykle: "Passengers" (pasażerowie), "Coal" (węgiel), "Lumber" (drewno) itp. A konkretnie, to co można podawać w tym parametrze, zależy od definicji z pliku *.chk, określonego w parametrze Type (omówiłem go wcześniej). W tym pliku trzeba odszukać linijkę rozpoczynającą się od "Load:", a dalej wpisane są w niej, po kolei:

[*]MaxLoad= maksymalna wielkość ładunku;[*]LoadQ= jednostka dla ilości ładunku (z moich obserwacji: "pieces" - sztuki, np. pasażerowie, "tonns" - tony, np. węgiel);[*]LoadAccepted= wymienione wszystkie rodzaje ładunku, oddzielone od siebie przecinkami;[*]LoadSpeed= szybkość załadunku (w jednostkach z "LoadQ=" na sekundę);[*]UnLoadSpeed= szykość rozładunku (j. w.).[/list]Dzięki temu łatwo zorientować się, jakimi dopuszczalnymi typami oraz wielkościami ładunków można załadować daną jednostkę.[/list]
[*]Na końcu jest ciąg "enddynamic" oznaczający koniec komendy "node ... dynamic ... ".[/list]Oto wymieniłem wszystkie parametry komendy "node ... dynamic ... " użytej w kontekście komendy "trainset". W kolejnych wierszach pomiędzy "trainset" a "endtrainset" podajemy więc wpisy dla kolejnych jednostek naszych składów, oczywiście może być ich wiele.

Plik ze scenerią zapisujemy i... w drogę :-).

Pozdrawiam wszystkich serdecznie i życzę zielonego na szlaku ;-).

[jaras]

Postanowiłem któregoś pięknego dnia zająć się plikami scenerii. Niestety, mimo różnych prób nie potrafię skorzystać z programu gmax, a programu 3D Studio Max (który nie jest darmowy) z pewnych względów nie mogę używać.

Ale, oprócz tak przez wielu ludzi chwalonego Notatnika, znalazłem jeszcze jedno użyteczne narzędzie, mogące, jeśli nie zastąpić, to przynajmniej pomóc w tworzeniu scenerii. Programem tym jest Jet 1.0 beta napisany w Javie.

Jego autorem jest Adam Domański, a strona domowa tego programu jest tutaj:
http://af186.internetdsl.tpnet.pl/doman/jet/

Początkowo może sprawiać problem samo uruchomienie programu. Nie wystarczy bowiem ściągnąć z powyższej strony programu i go uruchomić. Co prawda, na tej stronie wymienione są niezbędne składniki, z których korzysta Jet 1.0 beta, jednak pozwolę sobie je tutaj zebrać:

[*]Program Jet 1.0 beta;[*]Środowisko uruchomieniowe Java: J2SE 1.4.2 Runtime Environment;[*]Biblioteka Java 3D API.[/list]Nieistotne jest, czy bibliotekę Java 3D API ściągniemy i zainstalujemy w wersji dla DirectX (4,22 MB, bajtów: 4 427 612) czy OpenGL (4,13 MB, bajtów: 4 335 289). Wielkości plików instalacyjnych podałem dla wersji 1.3.1. Nasz system musi mieć możliwość wyświetlenia ekranu w rozdzielczości 800×600 pikseli.

No, to instalujemy po kolei: J2SE Runtime Environment, Java 3D API, i potem program Jet 1.0 beta. Instalacja tego ostatniego polega na rozpakowaniu po prostu pliku ZIP do jakiegoś katalogu.

Kolejnym problemem, na który można napotkać jest niewłaściwie ustawiona zmienna środowiskowa CLASSPATH, na której Java się opiera przy wyszukiwaniu plików klas (*.class) programu.

Ja, w swoim systemie, poczyniłem następujące ustawienia:

Kod: [Zaznacz]

set PATH=%PATH%;C:\j2sdk1.4.2_06\bin
set CLASSPATH=.
set J2D_D3D=true
Mówiąc krótko: binaria Javy (np. java.exe) są objęte systemową ścieżką wyszukiwania (zmienna PATH). Zmienna CLASSPATH zawiera wartość będącą bieżącym katalogiem ("."), gdyż w nim właśnie znajdzie Java potrzebne programowi pliki klas. Ostania zaś zmienna J2D_D3D określa, że będziemy używać biblioteki DirectX Java 3D API.

W katalogu z rozpakowanym programem jest plik jet.bat ułatwiający uruchomienie programu. Nieco go poprawiłem, przez co u mnie ma on teraz taką treść:

Kod: [Zaznacz]

@echo off
start java -cp . org.jet.Jet

W przypadku niejasności odsyłam zainteresowanych do tego wątku, szczegółowo wyjaśniającego instalację i uruchomienie programu Jet 1.0 beta.

Nie będę tutaj wyjaśniał obsługi programu. Wydaje mi się, że program jest wystarczająco dobrze udokumentowany. Również na wyżej wymienionej stronie projektu jest instrukcja obsługi.

Oto, co mi się udało stworzyć przy pomocy tego programu:


Jest to ot, taka sobie mała mijanka, czyli prosty tor z odgałęzionym drugim torem, połączone z sobą za pomocą zwrotnic. Jak widać na obrazku, niektórym odcinkom zostały nadane nazwy. Niedługo dowiemy się, po co.

Tu znajduje się gotowy wynik mojego działania: plik scenerii. Proponuję go sobie ściągnąć, gdyż w całym dalszym opisie będę odwoływał się do jego zawartości.

Lecz nie wyprodukujemy go całkowicie za pomocą programu Jet 1.0 beta. Po zapisaniu pliku otrzymamy następującą zawartość:

Kod: [Zaznacz]

// Scenery generated by jET
// Date: Thu Jan 27 20:38:31 CET 2005

description

enddescription

node -1 0 none track normal 200.0 1.435 0.25 20.0 20 0 flat vis
Rail_screw_used1 4.0 TpBpS-new2.tex 0.2 0.5 1.1
  0.0 0.0 433.23 0.0 // Point 1
  0.0 0.0 0.0 // Control vector 1
  0.0 0.0 0.0 // Control vector 2
  0.0 0.0 633.23 0.0 // Point 2
  0.0
endtrack

. . . [pominąłem tu cały środkowy fragment pliku]

node -1 0 zw2 track switch 33.23 1.435 0.25 20.0 20 0 flat vis
Rail_screw_used1 4.0 Rail_screw_used1 0.2 0.5 1.1
  0.0 0.0 666.46 0.0 // Point 1
  0.0 0.0 0.0 // Control vector 1
  0.0 0.0 0.0 // Control vector 2
  0.0 0.0 633.23 0.0 // Point 2
  0.0
  0.0 0.0 666.46 0.1 // Point 3
  0.0 0.0 -11.079 // Control vector 3
  1.225 0.0 11.012 // Control vector 4
  -1.838 0.0 633.298 -0.1 // Point 4
  -300.0
endtrack

firstinit
Aby otrzymać z tego gotowy plik scenerii, trzeba będzie go nieco jeszcze uzupełnić. Najlepszym podręcznikiem jest tutaj oczywiście wspominany przeze mnie wciąż plik Scenery.doc

A jak uzupełnić nasz plik, aby stanowił on poprawną scenerię do symulatora?

Po pierwsze: gdziekolwiek w scenerii powinien być ustawiony skład, aby można było jeździć. Mój poprzedni tutaj post dokładnie wyjaśnia jak tego dokonać. W przykładowym pliku zawarłem taki oto zapis:

Kod: [Zaznacz]

FirstInit

trainset none start 100.0 0.0
//$o Lokomotywka :-)
node -1 0 EU07-424 dynamic PKP\EU07 eu07-424 303E 0.0 headdriver 3 0 enddynamic
node -1 0 505120-00256-5 dynamic PKP\Bd Bdu-0.tga 111a 0.0 nobody 3 10 Passengers enddynamic
node -1 0 505120-00256-3 dynamic PKP\Bd Bdu-0.tga 111a 0.0 nobody 3 10 Passengers enddynamic
node -1 0 505120-00256-1 dynamic PKP\Bd Bdu-0.tga 111a 0.0 nobody 0 5 Passengers enddynamic
endtrainset
Jest więc tu lokomotywa EU07-424 wraz z trzema doczepionymi wagonami 2 klasy.

Jeśli jednak uruchomimy symulator z tą scenerią, owszem, będzie może i pociąg, tory i zwrotnice, lecz zamiast nieba cała reszta będzie zielona.

Zatem potrzebna jest też definicja oświetlenia. Z uważnej lektury pliku Scenery.doc wynika, że do tego służą komendy atmo i light, a z innych scenerii można je sobie skopiować wraz z gotowymi parametrami:

Kod: [Zaznacz]

atmo 0.6 0.7 0.9 0 1600 0.6 0.7 0.8 endatmo
light -500 500 200  0.3 0.33 0.35  0.70 0.65 0.6  0.75 0.74 0.70 endlight

Gdy uzupełnimy jeszcze nasz plik o następujące komentarze:

Kod: [Zaznacz]

//$n Prosta sceneria
//$d Przykład pokazuje jak stworzyć małą, nieskomplikowaną scenerię.
to podczas uruchamiania scenerii przy pomocy programu start.exe, zobaczymy następujący obraz:


OK, uruchamiamy symulator, mamy tory, mijankę, możemy jeździć, ale... tylko po torze prostym. Na zwrotnicach nie ma tekstur podsypki. No, a czemu w ogóle zwrotnice nie działają? Ano, dlatego, że nie są one przestawiane. A co zrobić, żeby były?

Popatrzmy na nasze zwrotnice w pliku:

Kod: [Zaznacz]

node -1 0 zw1 track switch 33.23 1.435 0.25 20.0 20 0 flat vis
Rail_screw_used1 4.0 Rail_screw_used1 0.2 0.5 1.1
  0.0 0.0 400.0 0.0 // Point 1
  0.0 0.0 0.0 // Control vector 1
  0.0 0.0 0.0 // Control vector 2
  0.0 0.0 433.23 0.0 // Point 2
  0.0
  0.0 0.0 400.0 0.1 // Point 3
  0.0 0.0 11.079 // Control vector 3
  1.225 0.0 -11.012 // Control vector 4
  -1.838 0.0 433.162 -0.1 // Point 4
  300.0
endtrack

node -1 0 zw2 track switch 33.23 1.435 0.25 20.0 20 0 flat vis
Rail_screw_used1 4.0 Rail_screw_used1 0.2 0.5 1.1
  0.0 0.0 666.46 0.0 // Point 1
  0.0 0.0 0.0 // Control vector 1
  0.0 0.0 0.0 // Control vector 2
  0.0 0.0 633.23 0.0 // Point 2
  0.0
  0.0 0.0 666.46 0.1 // Point 3
  0.0 0.0 -11.079 // Control vector 3
  1.225 0.0 11.012 // Control vector 4
  -1.838 0.0 633.298 -0.1 // Point 4
  -300.0
endtrack
Możemy sobie wyobrazić zwrotnicę "zw1" jak dwa tory: jeden prosty, drugi łukowy, które mają jeden punkt wspólny. Oto współrzędne tych punktów:

Kod: [Zaznacz]

Punkt 1: [0.0, 0.0, 400.0], punkt 2: [0.0, 0.0, 433.23];
Punkt 3: [0.0, 0.0, 400.0], punkt 4: [-1.838, 0.0, 433.162].
Widać tutaj, że punkt o współrzędnych [0.0, 0.0, 400.0] jest wspólnym punktem tych torów w rozjeździe. I właśnie ten punkt będzie punktem umieszczenia definicji zwrotnicy z pliku zwrP34R300.inc. Dlaczego akurat to ma być ten plik? Bo jest to rozjazd prawy ("P"), o długości toru prostego 33.23 m (~34 m) i promieniu toru łukowego 300 m. Z usytuowania zwrotnicy w scenerii wynika, że jej kąt wynosi 0.0°. Druga zwrotnica ("zw2") jest podobna, tyle, że jest ona lewa ("L"), a jej kąt wynosi 180.0° (bo jest zorientowana przeciwnie w stosunku do tej pierwszej).

Postępując tak z obiema zwrotnicami, otrzymujemy następujące wpisy, którymi trzeba będzie uzupełnić scenerię:

Kod: [Zaznacz]

include;zwrP34R300.inc;zw1;0.0;-0.200012;400.0;0.0;zwrot34r300pods-new.tex;;;;end

include;zwrL34R300.inc;zw2;0.0;-0.200012;666.46;180.0;zwrot34r300pods-new.tex;;;;end
Zapis "zwrot34r300pods-new.tex" jest jednym z wymaganych przez definicję zwrotnicy parametrów i określa teksturę, która zostanie użyta na podsypkę.

W ten sposób "wyposażone" zwrotnice dodatkowo otrzymują jeszcze latarnię zwrotnika, pokazującą wskaźniki Wz1, Wz2 i Wz3. To już coś, ale wciąż te zwrotnice nie działają - dlaczego?

Dlatego, że nie ma tu jeszcze "mechanizmu", który by je przestawiał. Tym "mechanizmem" w symulatorze MaSzyna są zdarzenia (ang. events).

Jednak użycie zdarzeń w scenerii powinno być starannie przemyślane. Najlepiej po prostu zaplanować sobie "co ma się dziać, kiedy coś innego się stanie" - to takie łopatologiczne stwierdzenie doskonale przybliża istotę ich funkcjonowania.

A tutaj zaplanujemy sobie, że gdy na torze przed mijanką przez 10 sekund będzie stał jakiś pojazd, to zwrotnice przestawią się tak, żeby pociąg mógł ominąć tor prosty, a kiedy przez 10 sekund będzie stał za mijanką, wówczas zwrotnice przestawią się tak, że będzie można przez nią przejechać po torze prostym (według scenariusza, w którym po zatrzymaniu się za mijanką chcemy tyłem wymanewrować na tor prosty).

Czytamy sobie dokument Scenery.doc i czytamy... Znajdujemy tam opis toru (node ... track ... ), a w nim klauzulę "event0", powodującą zadziałanie zdarzenia, gdy na torze, do którego jest ono przypisane stoi pojazd obsadzony przez załogę (czyli np. lokomotywa - sam wagon już nie).

Zatem do toru przed mijanką przypiszemy zdarzenie: "event0 mijanka_bok", a do toru za mijanką - zdarzenie "event0 mijanka_wprost". Oto, co uzyskujemy:

Kod: [Zaznacz]

node -1 0 pocz track normal 200.0 1.435 0.25 20.0 20 0 flat vis
Rail_screw_used1 4.0 TpBpS-new2.tex 0.2 0.5 1.1
  0.0 0.0 200.0 0.0 // Point 1
  0.0 0.0 0.0 // Control vector 1
  0.0 0.0 0.0 // Control vector 2
  0.0 0.0 400.0 0.0 // Point 2
  0.0
  event0 mijanka_bok
endtrack

node -1 0 koniec track normal 100.0 1.435 0.25 20.0 20 0 flat vis
Rail_screw_used1 4.0 TpBpS-new2.tex 0.2 0.5 1.1
  0.0 0.0 666.46 0.0 // Point 1
  0.0 0.0 0.0 // Control vector 1
  0.0 0.0 0.0 // Control vector 2
  0.0 0.0 866.46 0.0 // Point 2
  0.0
  event0 mijanka_wprost
endtrack
Nie uda się nam jeszcze uruchomić tej scenerii tak, jakbyśmy sobie tego życzyli. Owszem, może i się ona uruchomi, lecz będą "wyskakiwać" komunikaty błędów, że "to a to zdarzenie nie istnieje", a potem zwrotnice i tak będą nieruchome.

No tak! Wszak nie zostało jeszcze zdefiniowane, co ma się stać po spełnieniu warunków na wystąpienie tych zdarzeń. Po prostu: zostało zdefiniowane, kiedy zdarzenia mają nastąpić, lecz nie zostały zdefiniowane ich konsekwencje.

A, jak wspomniałem wcześniej, po 10-sekundowym postoju na torze przed mijanką, obie zwrotnice trzeba ustawić tak, aby wpuścić pociąg na drugi tor. Będą to ustawienia "w bok" ("zwrotnica+"), a po 10-sekundowym postoju na torze za mijanką, obie zwrotnice zostaną ustawione "na wprost" ("zwrotnica-"), aby wpuścić pociąg na tor prosty.

Oto co otrzymamy:

Kod: [Zaznacz]

event mijanka_wprost multiple 10.0 none zw1- zw2- endevent
event mijanka_bok multiple 10.0 none zw1+ zw2+ endevent
Zdarzenie typu multiple jest takim jakby zbiorem czynności, które po kolei trzeba wykonać. A czynności te (w obu przypadkach) zostaną wykonane po 10 sekundach trwania warunków na wystąpienie tych zdarzeń. Po szczegółowe informacje dotyczące zdarzeń odsyłam do pliku Scenery.doc.

No, to teraz już wszystko działa jak należy. Swietnie! Uruchamiamy loka, podjeżdżamy przed pierwszą zwrotnicę, stajemy na 10 sekund, zwrotka się przestawia w bok. Wjeżdżamy na mijankę, omijając tor prosty, wyjeżdżamy poza nią, znów stajemy na 10 sekund (ale tak, aby nie przestawiła się zwrotnica pod składem!). Cofamy i wjeżdżamy tyłem na tor prosty. Koniec naszych prostych manewrów :-).




Wiemy już też, do czego potrzebne są nazwy torów: do ustawiania na nich składu(-ów), a także do wywoływania na nich różnych akcji związanych ze zdarzeniami.

I takim właśnie przykładowym plikiem scenerii, stworzonym przy pomocy programu Jet 1.0 beta, oprócz tego wspomaganym też systemowym Notatnikiem wyjaśniłem, jak można bez wielkiego zachodu stworzyć sobie prostą scenerię. Jedno, czego nie da się zrobić przy użyciu wymienionych narzędzi, to pokrycie scenerii teksturą trawy, po za tym nie da się też wstawiać dróg samochodowych. Ale, jak na dobry początek, do nauki tworzenia scenerii - znakomicie te programy wystarczą.

Zatem wszystkim chętnym życzę dobrej zabawy i wielu owoców swej nauki.

Pozdrowienia dla wszystkich "kolejarzy" ;-).

[jaras]

Przy okazji testowania zwrotnika zrobionego przez @ youBy potrzebowałem malutkiej sceneryjki, w której mógłbym sobie testować położenia rozjazdu za pomocą klawiszy. Nie chciałem tracić czasu na wykonywanie misji na trasie z takim rozjazdem. Zabrałem się więc do tego, aby za pomocą łatwodostępnego narzędzia (tj. programu Jet 1.0 beta) zrobić taki rozjazd.

Nie było tak prosto, bo wszystkiego trzeba tu pilnować - nie tak, jak w skryptach 3D Studio Max. Jeden krok zrobiony nie tak i całą zwrotnicę trzeba robić od nowa :-(.

O sposobie zainstalowania programu Jet 1.0 beta napisałem w poprzednim poście.

OK, uruchamiamy program. Ustawiamy punkt bazowy (klikając na uchwyt jakiegoś toru albo przez Edycja -> Punkt bazowy) w miejscu, gdzie ma być jedna z odnóg rozjazdu krzyżowego. Ustawiamy skalę obrazu na 1:1.

W dalszej częsci zakładam, że robimy rozjazd, zaczynając od prawego bliższego toru. Dla potrzeb poniższego opisu ustawiłem punkt bazowy na współrzędnych [0.0, 0.0, 0.0] i kątach (0°00'00", 0°00'00"), a więc tak, jakby był tor prowadzący "w górę" pionowego rzutu scenerii na ekranie programu Jet.
[list=1][*]Na palecie "narzędzi" w okienku klikamy na "rozja...", a w okienku dialogowym podajemy parametry rozjazdu:

[*]Nazwa: "zw1_a",[*]Długość (tor zasadniczy i zwrotny): 8,000,[*]Promień: 300,000,[*]Rozjazd: Prawy (radiobutton),[*]Uchwyt wspólny (zakładka Uchwyty).
[/list]
[*]Zaznaczamy kliknięciem uchwyt na torze zasadniczym (prostym) w tej zwrotnicy - tak jak na poniższym rysunku.


[*]Na palecie "narzędzi" klikamy "inne" w kolumnie torów prostych, a w okienku dialogowym podajemy parametr toru:

[*]Długość: 1,000.
[/list]


[*]Mając zaznaczony uchwyt tego krótkiego toru prostego klikamy na palecie "narzędzi" "rozja...", a w okienku dialogowym podajemy parametry rozjazdu:

[*]Nazwa: "zw1_c",[*]Długość (tor zasadniczy i zwrotny): 8,000,[*]Promień: 300,000,[*]Rozjazd: Prawy (radiobutton),[*]Tor zasadniczy (zakładka Uchwyty).
[/list]
[*]Zaznaczamy kliknięciem uchwyt na torze zwrotnym (łukowym) tej zwrotnicy - tak, jak na poniższym rysunku.


[*]Na palecie "narzędzi" klikamy "inne" w kolumnie torów łukowych, a w okienku dialogowym podajemy parametry toru:

[*]Długość: 1,000,[*]Promień: 300,000,[*]Skrętność: Prawy (radiobutton).
[/list]


[*]Mając zaznaczony uchwyt tego krótkiego toru łukowego klikamy na palecie "narzędzi" "rozja...", a w okienku dialogowym podajemy parametry rozjazdu:

[*]Nazwa: "zw1_b",[*]Długość (tor zasadniczy i zwrotny): 8,000,[*]Promień: 300,000,[*]Rozjazd: Lewy (radiobutton),[*]Tor zwrotny (zakładka Uchwyty).
[/list]
[*]Zaznaczamy kliknięciem uchwyt na torze zasadniczym (prostym) tej zwrotnicy - tak, jak na poniższym rysunku.


[*]Na palecie "narzędzi" klikamy "inne" w kolumnie torów prostych, a w okienku dialogowym podajemy parametr toru:

[*]Długość: 1,000.
[/list]


[*]Mając zaznaczony uchwyt tego krótkiego toru prostego klikamy na palecie "narzędzi" "rozja...", a w okienku dialogowym podajemy parametry rozjazdu:

[*]Nazwa: "zw1_d",[*]Długość (tor zasadniczy i zwrotny): 8,000,[*]Promień: 300,000,[*]Rozjazd: Lewy (radiobutton),[*]Tor zasadniczy (zakładka Uchwyty).
[/list]


[*]Teraz dość trudny krok: użycie tzw. flexa do wstawienia brakującego toru łukowego pomiędzy torami zwrotnymi (łukowymi) zwrotnic zw1_a i zw1_d. Trudny jest o tyle, że pomiędzy uchwytami na zwrotnicach są bardzo niewielkie odległości i ciężko jest trafić we właściwe uchwyty.[list=1][*]Na palecie "narzędzi" klikamy "guma".[*]Zaznaczamy zwrotnicę, z której chcemy poprowadzić flexa (klikamy samą zwrotnicę!) - np. zw1_a.[*]Zaznaczamy uchwyt z toru zwrotnego (łukowego) na tej zwrotnicy.[*]Zaznaczamy drugą zwrotnicę, do której chcemy poprowadzić flexa (klikamy na samą zwrotnicę!) - np. zw1_d.[*]Klikamy na uchwyt z toru zwrotnego (łukowego) na tej zwrotnicy.[*]Gotowe.[/list:o]
Jeśli nam nie wyszło, nie ruszamy niczego, tylko naciskamy klawisz Delete, co usunie dopiero co wstawiony flex i powtarzamy próbę. Przyznam, że nie jest łatwo i nawet ja do tego tutorialu musiałem kilka razy próbować.[/list:o]Do zrobionego właśnie rozjazdu dorobiłem cztery tory proste po 50 m odchodzące od każdej zwrotnicy. Jeden z tych torów nazwałem "start", aby móc postawić na nim lokomotywę.


Posługując się pierwszym moim postem tutaj możemy sobie na tor "start" wstawić lokomotywę. Np. tak:

Kod: [Zaznacz]

trainset none start 10.0 0.0
//$o Test rozjazdu krzyżowego.
node -1 0 EU07-424 dynamic PKP\EU07 eu07-424 303E 0.0 headdriver 0 0 enddynamic
endtrainsetWarto też pamiętać o pozostałych elementach pliku ze scenerią, opisanych w poprzednim poście (np. atmo ... endatmo czy light ... endlight).

Teraz opiszę jak na swoim rozjeździe zrobić zwrotnik. Po uruchomieniu bowiem teraz tej scenerii, przez rozjazd będzie można przejeżdżać tylko na wprost, po torze zasadniczym.

Będzie do tego potrzebna paczka dostępna tutaj. Zawiera ona model zwrotnika oraz plik scenery\rozkrz34R150.inc sterujący zwrotnicami rozjazdu. W paczce tej jest również przykładowa sceneria testowa z tym rozjazdem do testowania jest za pomocą klawiszy Shift wraz z cyframi od 1 do 4. Polecam też do przeczytania ten wątek, w którym jest parę informacji o modelu zwrotnika autorstwa @ youBy.

Zaznaczamy jeden z krótkich torów prostych łączących zwrotnice w rozjeździe krzyżowym.


Klikamy Edycja -> Właściwości, aby wyświetlić okno dialogowe Własności toru.


Zaznaczyłem tu na czerwono pola, z których weźmiemy dane do obliczenia współrzędnych zwrotnika. Są to współrzędne [x, y, z] punktów końcowych. Sprawa jest prosta, trzeba obliczyć współrzędne środka rozjazdu, można do tego wykorzystać systemowy Kalkulator.

Liczymy więc średnią arytmetyczną:

xśr = x1 + x2
             2

yśr = y1 + y2
             2

zśr = z1 + z2
             2

Mamy więc współrzędne [xśr, yśr, zśr] środka rozjazdu krzyżowego. Sam zwrotnik jednak nie może być ustawiony w tym punkcie, bo będzie stał idealnie na środku toru :-). Trzeba go zatem przesunąć. Jeśli tor biegnie pod kątem 0° lub 180°, to można zastosować przesunięcie [2.1, -0.2, 0.0] (czyli dodać/odjąć odpowiednie wartości do obliczonych współrzędnych środka rozjazdu), wówczas zwrotnik będzie stał obok toru. To -0.2 jest po to, żeby zwrotnik nie "wisiał w powietrzu" - torowisko przez Jet domyślnie umieszczane jest na wysokości (y) 0.0, a same tory mają wysokość właśnie 0.2.

Potrzebny jest jeszcze kąt obrotu zwrotnika. Jeśli w trakcie wstawiania jednej ze zwrotnic zw1_c lub zw1_d będziemy o tym pamiętali, to wykonamy sobie takie czynności:[list=1][*]Klikamy na wspólny uchwyt zwrotnicy.[*]Wybieramy Edycja -> Punkt bazowy.
[*]Odczytujemy kąt z pola Alfa (na rysunku zaznaczyłem na czerwono).[*]Korzystając z systemowego Kalkulatora zmieniamy wyświetlone tam stopnie/minuty/sekundy na wartość dziesiętną stopni (Inv -> dms w Kalkulatorze w widoku profesjonalnym).[*]Dla zwrotnicy zw1_c dodajemy, a dla zwrotnicy zw1_d odejmujemy liczbę 1.623 (jest to połowa kąta między zwrotnicami zw1_c a zw1_d rozjazdu).[/list:o]Kiedy już mamy potrzebne dane, możemy w scenerii umieścić potrzebny wpis:

Kod: [Zaznacz]

include;rozkrz34R150.inc;zw1;2.1;-0.2;8.5;1.623;endNiestety, plik scenery\rozkrz34R150.inc nie posiada informacji o teksturach podsypki rozjazdu. Proponuję jednak poeksperymentować z innymi plikami *.inc jakie są w katalogu scenery: krzyzowy8R150L.inc oraz krzyzowy8R150P.inc mają w środku wpisane oteksturowanie torów podsypką. Prawdopodobnie mogą być też inne parametry (długości, promienie) zwrotnic, chociaż, z tego co zauważyłem wszystkie chyba mają długość 8 m, tylko nie jestem pewny co do promienia (300 m lub 150 m). Proszę nie pisać o tym w tym wątku - w razie czego zapraszam na priv.

Jeśli chodzi o nazwę rozjazdu: ja, na potrzeby tego opisu nadałem mu nazwę "zw1" - oczywiście można sobie wymyślić sobie inną nazwę. Jednak bardzo ważne jest, żeby zwrotnice składające się na cały rozjazd miały następujące nazwy:

[*]<nazwa>_a - dla toru prawego z przodu rozjazdu,[*]<nazwa>_b - dla toru lewego z przodu rozjazdu,[*]<nazwa>_c - dla toru lewego z tyłu rozjazdu,[*]<nazwa>_d - dla toru prawego z tyłu rozjazdu.[/list]<nazwa>, to wybrana nazwa dla całego rozjazdu (ta <nazwa> wtedy musi się pojawić jako parametr w komendzie include w scenerii). Wtedy dobrze będzie działał plik *.inc, a zwrotnik będzie pokazywał prawidłowe sygnały.

Aby do tej naszej scenerii dodać możliwość sterowania rozjazdem ręcznie, można posłuzyć się następującymi zdarzeniami:

Kod: [Zaznacz]

event KeyCtrl01 multiple 0 none zw1ac endevent
event KeyCtrl02 multiple 0 none zw1ad endevent
event KeyCtrl03 multiple 0 none zw1bc endevent
event KeyCtrl04 multiple 0 none zw1bd endeventPodobnie zrobiłem w scenerii testowej zawartej w pliku do ściągnięcia. Dzięki temu można sobie przestawiać rozjazd na różne położenia:

[*]Shift+1 - położenie "ac",[*]Shift+2 - położenie "ad",[*]Shift+3 - położenie "bc",[*]Shift+4 - położenie "bd".[/list]To wszystko. Rozjazd powinien działać jak należy, na co dowodem jest załączona sceneria testowa.

Miłego układania tras :-).

[jaras]

Trochę zaczęło mnie denerwować to, że nie mogę w prosty sposób zrobić scenerii z jakimś normalnym terenem. Bowiem zawsze u mnie, po zrobieniu torów, "wisiały" one "w powietrzu" ;-).

A sprawa wcale nie jest taka trudna i okazuje się, że i do tego również nie potrzeba 3D Studio Max :-). Wystarczy... zwykły Notatnik!

Jak?

Najpierw należy ściągnąć sobie tą paczkę (16509 bajtów; po rozpakowaniu: 39768 bajtów), w której umieściłem "prefabrykaty" do wykonania takiego terenu. Paczkę tą trzeba rozpakować do podkatalogu scenery/ symulatora. W paczce jest również sceneria testowa, ze znaną już mijanką opisywaną "dwa posty temu" wcześniej, tym razem wykorzystująca pokrycie terenu według mojego pomysłu.

Na czym to polega?

W zasadzie wszystko zostało wytłumaczone w pliku teren_info.txt w paczce (proszę o dokładne przeczytanie). Napiszę tu tylko o idei, jaka mi przyświecała tworząc tę paczkę.

Zamiast "składać" teren z trójkątów, prościej jest budować go z prostokątnych wycinków o różnych wymiarach. Jeśli dodatkowo w takich prostokątach można sobie osobno ustawiać wysokość terenu dla każdego narożnika z osobna, to można też w projektowanym terenie stworzyć różne górki i dolinki.

Projektując sobie torowisko w programie Jet 1.0 beta i patrząc na siatkę w oknie projektu ułatwiającą orientację wpadłem po prostu na pomysł: a jakby tak trójkąty były prostokątne (patrząc na ich rzut pionowy), to można by było je łączyć w pary, aby powstały prostokąty - a z takich prostokątów łatwiej zbudować płaszczyznę terenu. Eureka! ;-)



Powyższy obrazek pokazuje właściwie wszystkie aspekty charakterystyczne dla tego projektu. Trzeba tylko mieć na uwadze, że współrzędne w symulatorze MaSzyna wzrastają następująco:

[*]X - od prawej do lewej,[*]Y - od tyłu do przodu,[*]Z - od dołu do góry.[/list]Jak wspomniałem wcześniej, każdy narożnik prostokątów osobno może mieć ustawioną inną wysokość terenu.

Budowanie terenu więc jest teraz tak proste jak komenda include. Oto wszystkie wpisy definiujące teren w zawartej w paczce scenerii testowej:

Kod: [Zaznacz]

include;teren/p2w50x50.inc;-52.1;-17.0;0.0;-0.2;-0.2;5.0;-0.2;grass;end
include;teren/p2w50x50.inc;-102.1;-17.0;0.0;-0.2;-0.2;5.0;5.0;grass;end
include;teren/p2wP9xP10.inc;-52.1;33.0;0.0;5.0;-0.2;5.0;-0.2;grass;5;25;end
include;teren/p2wP9xP10.inc;-102.1;33.0;0.0;5.0;5.0;5.0;5.0;grass;5;25;end
include;teren/p2w50x50.inc;-52.1;283.0;0.0;5.0;-0.2;-0.2;-0.2;grass;end
include;teren/p2w50x50.inc;-102.1;283.0;0.0;5.0;5.0;5.0;-0.2;grass;end
include;teren/p2wP9xP10.inc;-52.1;333.0;0.0;-0.2;-0.2;-0.2;-0.2;grass;5;20;end
include;teren/p2wP9xP10.inc;-102.1;333.0;0.0;5.0;-0.2;5.0;-0.2;grass;5;20;end
include;teren/p2wP9xP10.inc;-52.1;533.0;0.0;-0.2;-0.2;-0.2;-0.2;grass;5;20;end
include;teren/p2wP9xP10.inc;-102.1;533.0;0.0;5.0;-0.2;5.0;-0.2;grass;5;20;end
include;teren/p1w50x50.inc;-52.1;733.0;0.0;-0.2;-0.2;5.0;-0.2;grass;end
include;teren/p1w50x50.inc;-102.1;733.0;0.0;5.0;-0.2;5.0;5.0;grass;end
include;teren/p2w50x100.inc;-52.1;783.0;0.0;5.0;-0.2;5.0;-0.2;grass;end
include;teren/p2w50x100.inc;-102.1;783.0;0.0;5.0;5.0;5.0;5.0;grass;end

include;teren/p1w50x50.inc;2.1;-17.0;0.0;-0.2;-0.2;-0.2;5.0;grass;end
include;teren/p1w50x50.inc;52.1;-17.0;0.0;-0.2;-0.2;5.0;5.0;grass;end
include;teren/p1wP9xP10.inc;2.1;33.0;0.0;-0.2;5.0;-0.2;5.0;grass;5;25;end
include;teren/p1wP9xP10.inc;52.1;33.0;0.0;5.0;5.0;5.0;5.0;grass;5;25;end
include;teren/p1w50x50.inc;2.1;283.0;0.0;-0.2;5.0;-0.2;-0.2;grass;end
include;teren/p1w50x50.inc;52.1;283.0;0.0;5.0;5.0;-0.2;5.0;grass;end
include;teren/p1wP9xP10.inc;2.1;333.0;0.0;-0.2;-0.2;-0.2;-0.2;grass;5;20;end
include;teren/p1wP9xP10.inc;52.1;333.0;0.0;-0.2;5.0;-0.2;5.0;grass;5;20;end
include;teren/p1wP9xP10.inc;2.1;533.0;0.0;-0.2;-0.2;-0.2;-0.2;grass;5;20;end
include;teren/p1wP9xP10.inc;52.1;533.0;0.0;-0.2;5.0;-0.2;5.0;grass;5;20;end
include;teren/p2w50x50.inc;2.1;733.0;0.0;-0.2;-0.2;-0.2;5.0;grass;end
include;teren/p2w50x50.inc;52.1;733.0;0.0;-0.2;5.0;5.0;5.0;grass;end
include;teren/p1w50x100.inc;2.1;783.0;0.0;-0.2;5.0;-0.2;5.0;grass;end
include;teren/p1w50x100.inc;52.1;783.0;0.0;5.0;5.0;5.0;5.0;grass;end

include;teren/pv4d2x50.inc;0.0;-17.0;0.0;-0.2;grass;end
include;teren/pv4d2x50.inc;0.0;833.0;0.0;-0.2;grass;endA oto efekt wykorzystania takiej techniki tworzenia terenu:


Proponuję porównać ten obrazek z obrazkiem na końcu mojego przedostatniego posta :-).

Niech żyje Jet i Notatnik... oraz długopis i kartka! ;-)

Pozdrawiam wszystkich serdecznie i życzę pięknych scenerii.

[jaras]

Ostatnio wśród użytkowników pojawił się pewien problem. Dostają oni jakiś nowy pojazd, wykonują sobie w scenerii odpowiedni wpis (być może korzystając z pierwszego mojego posta w tym wątku), uruchamiają program start.exe i... nie można wybrać składu z tą lokomotywą.

Dlaczego?

Zacznę może trochę z innej beczki.

Najczęściej jest tak, że uruchomienie symka z parametrami -s <sceneria> oraz -v <pojazd> daje pożądany rezultat (o ile w pliku ze scenerią pojazd został dobrze wpisany).

A jak podawać te parametry? Ogólnie postać wywołania programu EU07.exe jest taka:

Kod: [Zaznacz]

EU07.exe -s <sceneria> -v <pojazd>gdzie:

[*]<sceneria> - to po prostu nazwa pliku ze scenerią, w jakiej chcemy uruchomić symulator.[*]<pojazd> - nazwa pojazdu, który ma być aktywny po uruchomieniu symka.[/list]Co do parametru -v <pojazd>.

Celowo piszę tutaj "pojazd aktywny", a nie np. "lokomotywa do prowadzenia", gdyż pojazdem aktywnym może być również wagon, w którym można jechać jako pasażer (o ile taki wagon oczywiście posiada wnętrze). Aktywny pojazd po uruchomieniu symka pozostaje już takim aż do opuszczenia programu - nie można więc zmienić prowadzonej przez siebie lokomotywy albo też przesiąść się z lokomotywy do wagonu czy odwrotnie.

Jeśli zajrzymy do pliku ze scenerią i znajdziemy wpisy dla składu, w którym jest pojazd jaki chcemy, by był aktywny, to znajdziemy tam omiawiane przeze mnie w pierwszym tu poście komendy node wstawiające do składu kolejne pojazdy, np. to jest wpis dla lokomotywy EU07-424:

Kod: [Zaznacz]

node -1 0 EU07-424 dynamic PKP\EU07 eu07-424 303E 0.0 reardriver 3 0 enddynamic
Trzeci parametr tej komendy (Name) zawiera właśnie potrzebną nam do podania w parametrze -v <pojazd> nazwę pojazdu.

Zatem, aby uruchomić symka z tą lokomotywą jako pojazdem aktywnym, zakładając, że sceneria znajduje się w pliku zwrotnicowo.scn, jako polecenie uruchamiające symulator należałoby podać:

Kod: [Zaznacz]

EU07.exe -s zwrotnicowo.scn -v EU07-424
No dobrze, ale dlaczego zatem nie można uruchomić danej scenerii z jakimś pojazdem przez start.exe? Powiem więcej - nie da rady uruchomić przez start.exe żadnej scenerii z tym pojazdem aktywnym. Dlaczego?

Program start.exe korzysta z pliku dynamic\PKP\dynamic.dat katalogu symka. Bowiem program ten nie posługuje się nazwami pojazdów z parametru Name komend node (poza tym, że tylko wyświetla te nazwy w opisach w prawym dolnym okienku).

Program start.exe po prostu przeszukuje plik scenerii pod kątem znalezienia tam wpisów trainset ... endtrainset. Kiedy je znajduje, wówczas czyta po kolei zawarte w nich komendy node ... endnode i sprawdza, czy w składzie jest pojazd, który można by zaktywizować. Jeśli w całym składzie nie ma żadnego takiego pojazdu - taki skład nie jest pokazywany, jako możliwy do uruchomienia w scenerii. W przeciwnym razie, w lewym dolnym okienku w jednej linii wypisuje nazwy (Name) wszystkich pojazdów składu oddzielone znakiem "+", co pozwala wybrać taki skład i uruchomić z nim symulator.

A jak to sprawdza?

Aby odpowiedzieć na to pytanie muszę przedstawić format wspomnianego pliku dynamic\PKP\dynamic.dat, z którego właśnie korzysta start.exe.

Plik ten jest tekstowy, co oznacza, że podobnie jak np. pliki *.scn, *.t3d, *.chk czy *.mmd, można go otworzyć np. zwykłym Notatnikiem. Składa się on z kolejnych linijek, w których po kolei wymienieniane są różne pojazdy stosowane w symulatorze.

Na opis jednego pojazdu składają się tam cztery kolejno po sobie następujące linijki:[list=1][*]Nazwa pliku *.chk/*.mmd pojazdu.
Każdy pojazd ma swoje pliki definiujące dokładnie ich fizykę (*.chk) oraz model (*.mmd). Pamiętamy już zapewne, że takiej nazwy używamy w siódmym parametrze (Type) komendy node w pliku ze scenerią, gdy chcemy użyć danego pojazdu w składzie.

[*]Nazwa pojazdu wyświetlana przez program start.exe.
W prawym dolnym okienku z opisem wybranego składu wyświetlona będzie ta nazwa - zaraz napiszę do czego się to odnosi.

[*]Liczba:

[*]0 - gdy danego pojazdu nie można aktywować (bo np. lokomotywa nie ma kabiny lub wagon wnętrza);[*]1 - gdy pojazd jest lokomotywą z kabiną i można tę lokomotywę prowadzić;[*]2 - gdy pojazd jest wagonem z wnętrzem, w którym można jechać jako pasażer.[/list]
[*]Pusta linia.
Koniecznie ta pusta linia musi być - tego wymaga program start.exe.[/list:o]Otóż program start.exe dokonuje sprawdzenia, który pojazd w składzie nadaje się do aktywizacji, na podstawie trzeciej linijki z pliku dynamic\PKP\dynamic.dat - tej, w której jest liczba 0, 1 lub 2. Oczywiście brane są pod uwagę tylko pojazdy z ustawioną tam liczbą 1 lub 2 (dla odpowiednio: lokomotyw i wagonów). Pierwszy taki znaleziony pojazd decyduje o tym, czy można tego składu użyć do wyboru w scenerii czy nie. Dalsze takie pojazdy już nie są brane pod uwagę.

Jest to, moim zdaniem, dość istotne ograniczenie programu - np. postawmy na torze skład, gdzie jakiś wagon z wnętrzem jest PRZED lokomotywą dającą się prowadzić i zobaczmy co będzie po uruchomieniu start.exe :-).

I teraz opiszę krótko tą drugą linijkę: wyświetlaną nazwę pojazdu. Jeśli pierwszy znaleziony przez start.exe pojazd w dynamic\PKP\dynamic.dat ma wpisane:

[*]1 - wówczas w prawym dolnym okienku po wybraniu tego składu napisane będzie:

Prowadzimy <nazwa_z_drugiej_linijki> (<nazwa_z_Name_w_node>)

[*]2 - wówczas w prawym dolnym okienku po wybraniu tego składu napisane będzie:

Możemy jechać jako pasażer w wagonie <nazwa_z_drugiej_linijki> (<nazwa_z_Name_w_node>)

[/list]Ot, cała filozofia ;-).

Niestety, program ma dość poważny błąd. Polega on na tym, że w przeciwieństwie do sposobu ustalania pojazdu możliwego do aktywizacji jako pierwszego takiego znalezionego w składzie, jako pojazd, z którym rzeczywiście uruchamia scenerię po wybraniu tego składu, wybiera zawsze pierwszy w ogóle pojazd w składzie.

Dość łatwo to zauważyć, kiedy zbuduje się skład złożony z lokomotywy, która nie ma kabiny (a w pliku dynamic\PKP\dynamic.dat ma wpisane 0) i z doczepionym do niej wagonem, w którym można jechać jako pasażer (dla którego w pliku dynamic\PKP\dynamic.dat wpisane jest 2). Program, po uruchomieniu, wybraniu scenerii i tego składu poprawnie w prawym dolnym oknie napisze "Możemy jechać jako pasażer w wagonie ...", lecz symulator i tak zostanie uruchomiony z aktywną lokomotywą, a nie wagonem.

I tu wychodzi śmieszny babol, gdyż, kiedy lokomotywa nie ma kabiny, to będziemy w niej siedzieć, ale widać będzie tylko jej zestawy kołowe (gdyż nie ma w pliku *.mmd informacji o kabinie), a prowadzić będzie ją AI (przez brak informacji o kontrolkach i urządzeniach sterujących w pliku *.mmd).

Aby lepiej zrozumieć, jak należy uzupełnić plik dynamic\PKP\dynamic.dat o potrzebne pojazdy, posłużę się przykładem.

Załóżmy, że ktoś z naszych zdolnych twórców wykonał całą (wraz z kabiną) przykładową lokomotywę EX99 (wiem, że takiej nie ma, ale to tylko taki przykład). Załóżmy dalej, że jej fizyka i model opisane są w plikach 99AB.chk i 99AB.mmd (to znowu przykładowe, wymyślone przeze mnie "na teraz" nazwy) w podkatalogu dynamic\PKP\EX99. Oczywiście załóżmy też, że skoro jest to lokomotywa z kabiną, to możliwe jest jej prowadzenie.

Po co to ostatnie założenie? Ano dlatego, że ktoś mógłby wykonać lokomotywę niby z kabiną, a jednak niemożliwą do prowadzenia (gdyż w pliku *.mmd nie zawarł żadnych informacji o kontrolkach itp.) - wówczas, de facto taka lokomotywa byłaby niczym innym, jak takim jakby wagonem z wnętrzem. Dlatego właśnie, do naszego przykładu zakładamy, że można ją prowadzić, bo ma ona zdefiniowane wszystko co do tego potrzebne.

Przy tych założeniach plik dynamic\PKP\dynamic.dat należałoby uzupełnić tak:

Kod: [Zaznacz]

99AB
EX99
1

(Pamiętajmy o czwartej pustej linii.)

Idźmy dalej za tym przykładem.

Powiedzmy, że ktoś inny zrobił przepiękną scenerię i postanowił tam wstawić skład, na czele którego stoi nasza lokomotywa EX99. Lokomotywę tą nazwał EX99-123 (bo wraz z wykonaniem modelu wykonana została, załóżmy, tekstura EX99-123.tga na pokrycie pudła). I powiedzmy też, że cały pociąg z tą lokomotywą ten ktoś nazwał PE123 (a w podkatalogu scenery symka jest plik z rozkładem jazdy PE123.txt).

Zatem wykonał on w scenerii następujące wpisy:

Kod: [Zaznacz]

trainset PE123 tor_pocz 0.0 0.0
//$o Opis misji.
node -1 0 EX99-123 dynamic PKP\EX99 EX99-123.tga 99AB 0.0 headdriver 3 0 enddynamic
node -1 0 ... // dla jakiegoś wagonu
...
endtrainset
Kiedy uruchomilibyśmy program start.exe, a potem wybralibyśmy tą scenerię i skład z naszą lokomotywą EX99-123, to w prawym dolnym okienku pojawiłby się napis:

Nazwa składu: PE123
Prowadzimy EX99 (EX99-123)
Opis misji.

Mam nadzieję, że ten przykład wszystko już wyjaśnił.

Aby wszelkie otrzymane lub ściągnięte pojazdy można było w ten sposób uruchamiać przy użyciu start.exe - informacje o nich trzeba aktualizować w pliku dynamic\PKP\dynamic.dat. To tak, jak przez autorów podawane są przykładowe wpisy dla pojazdów dla plików scenerii - tak i tutaj też trzeba je uzupełniać, aby móc korzystać z programu start.exe.

Myślę, że teraz nie powinno już być problemów z uruchamianiem scenerii z tego programu. Zatem nie pozostaje mi nic innego, jak tylko życzyć wszystkim zielonego światła na szlaku :-).

PS. Informacja dla czytelników moich tutoriali: prawie w każdym poście zamieszczam ukryte pod pogrubieniem linki do różnych innych miejsc (na tym forum czy gdzie indziej), które z pewnością są warte uwagi.

[jaras]

Po naprawieniu polskich liter na forum poznikały różne posty. Zaś ja sobie zachowałem wątek o zdarzeniach *_sem_info.

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)

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

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

include;SS5zpcpbY.inc;podgdroginia_E;-35795.7;0.0;-3156.63;-105.0;E;72;end

Kod: [Zaznacz]

include;SBL3YN-pierwszy.inc;60n;-35785.5;0.0;-3153.02;73.721;A;podgdroginia_d;endZatem, podgdroginia_E jest zwykłym semaforem, a 60n - SBL-em. Widać je nawet na tym drugim screenie.

Zdarzenia

Kod: [Zaznacz]

event1 podgdroginia_E_sem_info
event2 60n_s1odnoszą 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: [Zaznacz]

      60n =| |= E
           | |
1____________________________________________2Zatem, 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: [Zaznacz]
  event2 60n_s1Inaczej 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: [Zaznacz]
  event1 podgdroginia_E_sem_infoInaczej 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: [Zaznacz]

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

include plik.inc par_1 par_2 par_3 ... par_n ... endPamię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: [Zaznacz]

origin (p2) (p3) (p4)
rotate 0 (p5) 0Komenda 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: [Zaznacz]

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

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

rotate 0 0 0
endoriginKoniec "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: [Zaznacz]

//memcell do pamietania predkosci:
node -1 0 (p1)_sem_mem memcell (p2) (p3) (p4) SetVelocity 0.0 0.0 none endmemcellTo 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: [Zaznacz]

//odczyt z pamieci (zdarzenie przypisane do toru przy ktorym stoi semafor):
event (p1)_sem_info getvalues 1.0 (p1)_sem_mem endeventWtedy, 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: [Zaznacz]

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

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

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

node -1 0 (p1) model 0 0 0 0 PKP/head5_gyryw.t3d (p6) Lights 0 0 1 0 0 endmodel
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 ;-).