Strefa OMSI - polskie forum o OMSI i OMSI 2 - Budowa pojazdów

Textfeldy - od A do Z - tekst w OMSI

Wed, 16 Apr 2025 05:38:07 +0200

Nie wiem czy już taki poradnik istnieje, ale postanowiłem napisać własny.

Textfeldy

z niemieckiego pola tekstowe - służą do wyświetlania zmiennego tekstu. Nie ma zbyt wielu różnić między tekstem na obiektach scenerii a tych w pojazdach. Jedno i drugie, może być kontrolowane przez skrypt, przy czym w obiektach scenerii możemy wpisać sobie w obiekt co ma na nim być, np nazwa przystanku czy ulicy. Po pierwsze, to od czego musimy zacząć to dobrać odpowiedni font.

Font

inaczej czcionka dla mówiących mniej cool młodzieżowo. OMSI ma podfolder Fonts w którym możemy znaleźć wszystkie dostępne dla OMSI fonty, tak jak wskazuje nazwa. Font w OMSI składa się z 2 plików - .oft i .bmp. Plik .oft jest plikiem konfiguracyjnym fontu, gdzie wyznaczone są koordynaty wszystkich znaków, jakie są odległości między znakami w pixelach, jego nazwę oraz nazwę pliku bitmapy. Plik .bmp jest bitmapą gdzie mamy zapisane wszystkie dostępne znaki dla danego fontu. Nie muszą to być koniecznie znaki ABCDE, bo można tu zrobić nawet jakieś szlaczki. Ważnym jest, aby zgadzały się koordynaty, oraz żeby nie dublowały się znaki, jak i również żeby nie było spacji za znakami. Ostatnią istotną rzeczą jest to, żeby plik .bmp był zapisany jako 24-bitowy, inaczej OMSI nie odczyta poprawnie fontu. Mając to za sobą, przejdźmy do struktury plików fontów i spójrzmy na nie dokładnie. To ważne, aby zrozumieć jak najlepiej robić własne fonty.

Pliki .bmp

24-Bitowe bitmapy zawierające 'mapę' wszystkich znaków dla danego fontu, lub fontów. Na jednej bitmapie możemy mieć zmapowanych kilka różnych fontów, co polecam robić, jeżeli mówimy o fontach na matrixy.

Przykładowe bitmapy wyglądają tak:

Kolor niebieski (R:0 G:0 B:255 / HEX 0000FF) wyznacza obszar który nie jest używany do mapowania znaków, ułatwia to pracę w przypadku gdy mapujemy plik .oft ręcznie. Zacznim zaczniemy, w przypadku gdy robimy zwykły font pokroju Ariala, NIGDY, podkreślam N I G D Y nie używajcie zbyt dużego rozmiaru czcionki. Według mnie, optymalnym jest całkowity rozmiar wysokości w okolicach 40-60 pikseli. Używając większej rozdzielczości, to tekst pokroju zegarka który odświeża się co sekundę, zagwarantuje czkawkę całej gry. Ładny i ostry font brzmi fajnie na papierze. Jeżeli zrobicie zbyt duży font i zorientujecie się że powoduje on problemy z wydajnością, to całą pracę trzeba wykonać de facto od nowa. Dlatego sam fakt dobrania odpowiedniej wysokości dla znaków jest tak istotny. Do edycji polecam Paint.net, chociaż możecie korzystać z czego chcecie i w czym wam się pracuje najwygodniej. Tutaj mówię o przypadku programu graficznego obsługującego warstwy.

Mając przygotowany plik, pora przygotować sobie zestaw znaków. Polecam użyć poniższego:

Kod:
0123456789 ABCDEFGHIJKLMNOPRSTUWYZXQV abcdefghijklmnoprstuwyzxqv !?:;.,%^&*()-_'"/\<>+ ÄÖÜäöüß ĄĆĘŁŃÓŚŻŹ ąćęłńóśżź

Możemy podejść do tego na 2 sposoby - albo zrobić kilka linijek znaków, albo zrobić jedną długą linijkę ze wszystkimi znakami. Polecam zostawić rezerwę miejsca na wypadek gdybyście kiedyś chcieli dodać jakiś dziwny znak, bo będziecie mieli taki kaprys.

Jak widać na załączonym obrazku, wysokość naszej bitmapy niekoniecznie musi oznaczać wysokość tekstu który wpisujemy. Musimy mieć na uwadze znaki szczególne takie jak Ą czy Ć, które będą wykorzystywać więcej marginesu górnego/dolnego niż pozostałe znaki.

Następnie na warstwie pod czcionką ale nad niebieskim tłem, wyznaczamy obszary dla znaków. Musi się on pokrywać na szerokość znaków. Odstępami między znakami w OMSI się nie przejmujcie, ponieważ to rozwiąże plik .oft . W przypadku gdyby jakieś znaki były 'sklejone ze sobą', to przesuńcie dalszą część znaków o 1-2 pixele w bok, aby zachować odstęp między 'czarnymi' polami.

Mając gotową bitmapę, zapisujemy ją jako 24-bitową.

Pliki .oft

Pliki te mówią OMSI gdzie znajduje się jaki znak, ich wysokości, odstępy i nazwę.

Kod:
[newfont] <- Nagłówek pliku .oft 

Moj_super_font <- nazwa fontu którą później wpisujemy w plikach modeli

Moj_super_font_bitmapa.bmp <- nazwa bitmapy

Moj_super_font_bitmapa.bmp <- nazwa bitmapy od alphy, ale to jest zagmatawne, wpiszcie to samo

16 <- wysokość znaków w pixelach (nie mylić z wys. bitmapy!)

1 <- odległość pomiędzy znakami w pixelach

[char] <- nagłówek dla wpisu kolejnego znaku

0 <- dany znak

9 <- koordynaty X początku znaku (idąc prawo tym większe)

16 <- koordynaty X końca znaku

1 <- koordynat Z znaku (góra-dół)

[char]

1

17

21

1

Obrazując o co chodzi z koordynatami:

Alternatywnie można użyć tej strony LINK która je dla nas wygeneruje, ale trzeba mieć na uwadze to że wysokość znaku utnie, oraz że czasami potrafi dostać padaczki przy większych plikach, oraz jak jest kilka linijek ze znakami. Trzeba robić 'po linijce', ale nie zmieniając wysokości bitmapy. Ergo zakryć inne linijki niż ta którą obecnie chcemy żeby ta strona nam zmapowała.

Struktura modelu 3D

Aby tekst nam się gdzieś pojawił, musi mieć się na czym pojawić.

Mając nas wymarzony plane na którym chcemy żeby pojawiały się jakieś bzdury, musimy go zmapować oraz dać mu odpowiedni materiał z teksturą. Nie będę się do tego zagłębiał tutaj, bo tu trzeba znać podstawy blendera lub innego programu do edycji 3D którego używacie.

Teraz tak, żeby odpowiednio to potem wpisać w model.cfg/.sco, polecam zrobić sobie screena naszego plane'a tak aby mieć go na wprost od kamery. Następnie ucinamy screen do samej planszy. Rozdzielczość tego co nam zostało, to mamy współczynnik proporcji. Jak jesteście leniwi jak ja, to zmieńcie sobie jego rozdzielczość do takiej jaką mamy w wysokości fontu jaki chcemy użyć (załóżmy 50 pikseli). W tym wypadku wychodzi nam 191 na 50 pikseli. To będzie rozdzielczość którą wpiszemy w konfiguracji modelu.

Wpisy w model.cfg / obiekt.sco

Wpisy gdzieś u góry w model.cfg:

Kod:
makdolan <- dowolny tekst, możemy sobie tu wpisać własne notatki

1 <- nie obowiązkowe, indeksowanie texttexture, polecam aby wiedzieć co mamy wpisać potem przy modelu, liczymy od 0

[texttexture_enh] <- nagłówek

Gorba_Text <- nazwa zmiennej string / w plikach scenerii .sco może tu być wpisane 0, 1, 2 itd.

Sobol_Gorba_LCD_Breit <- nazwa fontu

1536 <- rozdzielczość X (szerokość)

110 <- rozdzielczość Z (wysokość)

0 <- zostawcie to na 0

208 <- kolor R (czerwony)

219 <- kolor G (zielony)

0 <- kolor B (niebieski)

0 <- Orientacja 0 wyśrodkowany / 1 do lewej / 2 do prawej

0 <- coś tam o siatce ale to zostawcie na 0

Wpisy dla naszego modelu .o3d:

Kod:
[mesh]

Moj_plane_z_bzdurami.o3d

[matl]

textfeld.tga <- nazwa tekstury ustawionej w materiale

0 <- indeks materiału z tą nazwą tekstury

[matl_alpha] <- ustawia przeźroczystość

2

[useTextTexture] <- ustawia, że to jest mesh z tekstem

1 <- indeks texttextre liczony od 0

W przypadku pojazdów i obiektów scenerii wygląda to tak samo.

Uwaga odnośnie zmiennych string

Podstawową podstawą podstawy - miejcie poprawnie przypisany plik stringvarlist.txt! W nim musi się znaleźć nazwa tego co wpisaliśmy wcześniej w texttexture. W plikach scenerii można wpisać 0.

Dykty (SteckSchilder) - działa czy nie działa?

Wed, 02 Apr 2025 09:57:39 +0200

Ostatnio podczas zabawy funkcją SteckSchilder odkryłem to, co wszyscy którzy chcieli się bawić w dodawanie dykt do hofu - nie działa.
Po dogłębnym przestudiowaniu skryptów odpowiedzialnych za działanie tej funkcji, doszedłem do wniosku, że to skrypty są źle napisane, a nie funkcja źle działa. Po jakiejś godzinie zabawy skryptami udało mi się skutecznie to naprawić. Tutaj chciałbym zaprosić do przeanalizowania funkcjonowania dykt w OMSI, dlaczego nie działały i jak sprawić żeby to naprawić.

1. Ustawienie dykt w hofie
Aby ustawić dykty w pliku .hof (mówię to na podstawie notatek z hofu grundorfu) należy ustawić odpowiednią liczbę w stringcount_terminus oraz ewentualnie zdefiniować podfolder w Anzeigen/SteckSchilder, tak samo, jak robi się to w przypadku bitmap i zapowiedzi. Następnie należy zdefiniować nazwę pliku bitmapy dla dykty w odpowiednim wpisie [addterminus].

Kod:
[addterminus]

001

PKS WEGLIN

PKS WEGLIN

PKS WEGLIN

PKS WEGLIN

PKS WEGLIN

2_001.bmp <- w tej linijce znajduje się wpis do dykty

2. no dobra, ale to nie działa
Problemem skryptu z podstawki jest to, że funkcja od definiowania podfolderów dla danego hofu nie działa poprawnie, bo w ogóle to nie jest sprawdzane (serio). Drugim problemem jest to, że skrypt koniecznie chce numer ziel 1xxx, a nie 3-cyfrowy. Trzecim problemem było to, że skrypt bez sensu sprawdzał czy na początku nazwy pliku dykty jest 1 czy 2. Nie wiem po co, ale teoretycznie ustawiało to różne modele dykt. Ostatnim problemem było to w jaki sposób to jest ustawiane - tylko w jakiś dziwnych przypadkach których po tych 15 linijkach kodu nawet ja nie umiałem zrozumieć. To wszystko razem wzięte daje tak absurdalne okoliczności, że nie jestem wybitnie zdziwiony, że ta funkcja nigdy nie była jakoś szczególnie używana w OMSI.

3. jak skutecznie to naprawić?
Odpowiedź jest bardzo prosta - użyć customowego skryptu który napisałem, bo bez jego podmiany się nie da tego ogarnąć, a z moim skryptem który działa niezależnie od starego kodu, nie będzie on interferował z kodem z podstawki.

Gdzieś w skrypcie w sekcji gdzie znajdują się podobne wpisy trigger, musimy dokleić ten fragment kodu - będzie on odpowiedzialny za zmiane pozycji dykty między włożoną i schowaną. Trzeba pamiętać żeby wkleić to tak, aby nie było to w środku innego triggera lub w jakimś makrze.

Kod:
{trigger:dykta_mouseevent}

    (L.L.dykta_vis) ! (S.L.dykta_vis)

{end}

Do dowolnego macra _Frame które jest zaczytywane cały czas należy dopisać ten fragment kodu. Polecam go dać dokładnie na samym początku takiego makra, ale tak, żeby nic nie usuwać, ani nie dawać go pod inne fragmenty kodu. Makro to musi być zaczytywane cały czas, więc polecam wybrać jakiś skrypt, który jest używany we wszystkich autobusach. Można go również dopisać w main.osc, pod frame.
Wpisy w script.osc:

Kod:
    (L.L.AI_target_index) (L.L.dykta_Termindex) = !

    {if}

        (L.L.AI_target_index) s0

        l0 6 (M.V.GetTerminusString) (S.$.Dykta_terminus)

        2 (M.V.GetDepotStringGlobal) (S.$.Dykta_global)

        (L.$.Dykta_global) "" $= !

        {if}

            (L.$.Dykta_global) "\" $+ (S.$.Dykta_global)

        {endif}

        (L.L.dykta_Termindex) s0

        0 >= 

        {if}

            "..\..\Anzeigen\SteckSchilder\" (L.$.Dykta_global) $+ (L.$.Dykta_terminus) $+ (S.$.Dykta_string)

        {else}

            ""  (S.$.Dykta_string)

        {endif}

        l0 (S.L.dykta_Termindex)

    {endif}

Do pliku stringvarlist.txt do dowolnego zaczytywanego skryptu należy dopisać te linijki:

Kod:
Dykta_global

Dykta_string

Dykta_terminus

Do pliku varlist.txt do dowolnego zaczytywanego skryptu należy dopisać te linijki:

Kod:
dykta_Termindex

dykta_vis

4. modele 3D i tekstury
Mając tak przygotowane skrypty, należy przygotować modele 3D.

Dykta.zip (Rozmiar: 465.71 KB / Pobrań: 18)

W tym małym archiwum znajdziecie plik .blend z modelem dykty z przygotowanym mapowaniem. Dodatkowo możecie tu też znaleźć szablon który ma wyraźnie zaznaczony obszar 'roboczy' z przodu dykty. Dolna część która nie jest zaznaczona jest tylną częścią tej dykty, jest ściśnięta, więc raczej nie ma sensu tam malować. Nadpisanie domyślnej tekstury (tej z napisem Sonderfahrt) spowoduje wyświetlenie tej tekstury na dykcie w autobusie, w przypadku gdy plik .hof nie posiada poprawnie zdefiniowanej tekstury dla dykty. Polecam sobie zdublować ten obiekt, jeżeli nie wiecie do czego przypisać triggery od dykt, bo nie znacie nazw plików. O tym poniżej. Pod tym akapitem dodatkowo dla lepszego zobrazowania możecie zobaczyć obszar roboczy na teksturze, oraz przykładowe ustawienie dykt w autobusie.

Obszar dla przodu dykty to ten zaznaczony na pomarańczowo:

Przykładowe ustawienie modeli 'schowanych' dykt:

Przykładowe ustawienie modeli 'włożonych' dykt:

Wpisy w pliku model:

Opcjonalny header dla ładniejszego rozróżnienia poszczególnych sekcji w pliku model.cfg

Kod:
###############################################################

Steckschild/Dykta:

###############################################################

ZALECANE ! - wpisy dla modelu 'schowanej' dykty, czyli takiej która nie jest aktywna. Jak wyżej - jeżeli nie znacie struktury autobusu do którego to chcecie dodać, a macie zaimportowany jego model, polecam umieścić 'schowaną' dyktę gdzieś w okolicach kabiny, tak żeby była łatwo dostępna do kliknięcia. Wpisy od tego modelu nie są wpisami od modelu 'włożonej' dykty!

Kod:
[mesh]

schildFrnt_hidden.o3d

[visible]

dykta_vis

0

[matl]

Schild_Frnt.bmp

0

[matl_freetex]

Schild_Frnt.bmp

Dykta_string

[mouseevent]

dykta_mouseevent

-----------------------------

Wpisy od modelu 'włożonej' dykty, czyli tej która jest aktywna.

Kod:
[mesh]

schildFrnt.o3d

[visible]

dykta_vis

1

[matl]

Schild_Frnt.bmp

0

[matl_freetex]

Schild_Frnt.bmp

Dykta_string

[mouseevent]

dykta_mouseevent

-----------------------------

OPCJONALNE ! - Wpisy dla ewentualnego pliku .o3d odpowiedzialnego za kliknięcie do włożenia/schowania dykty, na przykład jakiś stelaż. Nazwa pliku .o3d w tym wypadku musi być taka, jak nazwa istniejącego pliku.

Kod:
[mesh]

schildFrnt_t.o3d

[mouseevent]

dykta_mouseevent

-----------------------------

ISTOTNA UWAGA!
Dodatkowo dla osób 'mniej technicznych' od tej strony tworzenia do OMSI - jedyne co chcecie ruszać to tylko linijkę pod wpisem [mesh]. Musicie pamiętać o odpowiedniej ścieżce do ewentualnego podfolderu i o odpowiedniej nazwie zgodnej z nazwą modelu .o3d - w przeciwnym razie model przestanie się ładować w momencie gdzie znajdują się wpisy od felernego [mesh]. Jeżeli na tym etapie macie dokładnie taki problem, tj. 'częściowo załadowany autobus' sprawdźcie poprawność nazw plików .o3d od dykt które dopisaliście.
Dopisując te pliki pamiętajcie aby NIE DODAWAĆ ICH NA SAMYM KOŃCU MODEL.CFG !!! - spowoduje to problemy z ich widocznością za szybami, ponieważ struktura model.cfg musi być napisana 'od środka na zewnątrz'. Polecam dopisać te linijki gdzieś w 1/4 wysokości całego pliku cfg.

W razie pytań, chętnie pomogę.

Możliwe przyczyny źle działającego autobusu w OMSI

Sat, 05 Oct 2024 07:10:04 +0200

Krótki wątek dla osób które bawią się w modowanie/tworzenie pojazdów i zastanawiają się dlaczego po zmianie paru rzeczy w modelu OMSI świruje.

Autobus w ogóle się nie respi - widać samego kierowcę
Możliwymi przyczynami takiego stanu rzeczy mogą być błędnie wyeksportowane pliki .o3d, lub (najczęściej) wpisy [matl] + [matl_change] odwołujące się do nie istniejącej tekstury
Sprawdź przypisane materiały w obiekcie, upewnij się czy nie ma żadnych literówek na tym etapie. Ewentualnie wyeksportuj plik ponownie, dla pewności. Następnie sprawdź poprawność wpisów [matl], [matl_change], [matl_nightmap] itp. Tutaj też nie mogą występować żadne literówki.
Kolejną opcją może być brak zmiennej w varlistach. Logfile powie tylko o tym drugim, z pierwszym log nic nie pokaże.
Ostateczną opcją jest błąd w składni skryptów.

Autobus się respi, ale jest wybrakowany
Najprawdopodobniej w model.cfg jest wpis odwołujący się do nie istniejącego pliku .o3d, lub gdzieś wpisy konfigurujące model są błędnie zapisane. W większości przypadków log wskaże konkretną linijkę.

Ekrany nie działają
Brakujący wpis w stringvarliście.

Tekst pojawia się nie tam gdzie powinien
Pomieszała się kolejność [texttexture_enh]/[texttexture]. Sprawdź wszystkie te wpisy, następnie sprawdź czy wszystkie [usetexttexture] odwołują się do właściwego ID texttexture. Pamiętaj, że ID liczymy od 0.

Białe tekstury
Możliwości są dwie. Albo brak 4gb patcha - zapchanie pamięci, albo brak tekstury. O drugim powie log.

Czarne tekstury, ale z bliska się pojawiają
Upierdliwy problem silnika OMSI. Rozwiązaniem są tekstury w innym formacie niż .PNG, większość poleca .DDS, ale kompresja DDS potrafi zepsuć mocno jakość tekstur. Ja polecam .TGA.

Pasażerowie nie wsiadają pomimo odpowiedniego kierunku na matrixach
Błąd w passengercabin lub paths.cfg. Zweryfikuj, czy aby na pewno żaden pathlink nie odwołuje się do nie istniejącego ID ścieżki.

Zmodowałem animowany model X, ale dziwnie się on animuje po ponowym eksporcie
Sprawdź zapis [newanim]. Jeżeli jest tam origin_from_mesh, to musisz ustawić osie w modelu w blenderze. Domyślnie OMSI animuje modele wg osi X.

Wraz z animacją poruszają mi się wszystkie światła
Ostatni wpis [mesh] nie może być animowany. [light_enh]/[light_enh_2] animuje się razem z obiektem, w pewnych okolicznościach jest to pożądane, ale czasami robi to cyrk.

Obiekty znikają za szybami, lub przez szyby dziwnie widać obiekty
Jeżeli dodajesz jakieś obiekty, to nie powinny być one na samym końcu model.cfg. Kolejność renderowania jest taka, że silnik OMSI renderuje najpierw to co jest u góry w modelu, a to co na końcu później. Jeżeli użyjesz złej kolejności wpisów, to przez szyby może być nie widać co jest w środku. Dlatego kolejność jest taka, aby szyby były ostatnim wpisem w model.cfg (poza innymi wpisami typu light_enh, spotlight itd.). W drugim wypadku jest zła konfiguracja wpisów [matl_noZcheck]/[matl_noZwrite]. Ale jest to generalnie tak czarna magia, że tego to nawet tybetańscy mnichowie nie rozumieją.

Dodałem płotek, ale dziwnie się on zachowuje
Funkcja GetHumanCountOnPathLink jest zbugowana i nie działa poprawnie. Niestety, ale nie da się dodać poprawnie działającego płotka.
Funkcja w/w działa, ale nie jeżeli chcemy sprawdzić pathlink z indeksem 0.

Zmiana masy własnej pojazdu

Mon, 31 Oct 2016 09:31:09 +0100

Witam wszystkich.
Na pewno denerwuje was fakt, iż na FS na linii 159 czy 259 nie możecie podjechać niektórymi wozami pod górę.
Nie jest to trudno zmienić, ale dla "niedowiarków" zawsze się przyda. :p

Modyfikacja: Zmiana masy własnej pojazdu
Autor: jakubbialek2

Zatem wchodzimy w plik .bus autobusu, którym chcemy wyjechać.
Ja posłużę się MANem NG312.

Odnajdujemy w pliku wpis:

Kod:
[mass]

8

i zmieniamy na dowolną (najlepiej mniejszą jeżeli chcemy jeździć pod górę) masę.

Ja na przykład wybrałem taką:

Kod:
[mass]

5

Zapisujemy.

W pliku tylnej części autobusu (zazwyczaj oznacza się ze słowem "trail") odnajdujemy taki sam wpis, ale nie jest to już taka bułka z masłem. Żeby autobus poprawnie się zachowywał należy wykonać obliczenie:

Kod:
[mass] z pliku "tyłu" * (Masa wprowadzona z przodu / Masa przed wprowadzeniem (również z przodu)

(* - razy ; / - dzielone przez)

Po wykonaniu takiego obliczenia w moim MANie wychodzi (masa w tyle wynosi na początku 7.2):

Kod:
7.2 * (5/8) = 7.2 * 0.625 = 4.5

I wynik wpisujemy pod [mass]:

Kod:
[mass]

4.5

Zapisujemy i jedziemy.

UWAGA!!! Ważne jest, żeby wóz nie był za lekki, ponieważ będzie wam podskakiwał i nie przestanie. Wóz też nie może być za ciężki ponieważ nie ruszy wam z miejsca.

Zmiana prędkości drzwi w dowolnym autobusie.

Fri, 25 Mar 2016 19:02:55 +0100

Witam, postanowiłem napisać ten poradnik dla innych gdyż sam się z tym męczyłem.
Za przykład wziąłem niedawno wydaną Setrę S 319 UL. Oczywiście można to zrobić w każdym innym pojeździe, ponieważ skrypty się znacząco nie różnią, jednak nie wiem jak będzie w przypadku pojazdów 3-drzwiowych.

Więc rozpoczynamy!
Otwieramy plik "door_constfile" znajdujący w folderze "Script" danego pojazdu.

Na samym początku mamy:

Kod:
Front/Back Door Acceleration (100%/s˛)

[const]

fdoor_acc

0.5

[const]

bdoor_acc

0.6

Gdzie:
"fdoor_acc"- prędkość przyśpieszenia drzwi przednich
"bdoor_acc"- prędkość przyśpieszenia drzwi tylnych
Uwaga! Wszystkie wartości są w %/s

2. Określenie zmiany przyśpieszenia drzwi. W moim przypadku jest to 0.2.

Kod:
    Door Acceleration Variation (100%/s˛)

[const]

door_acc_var

0.2

Kod:
Front/Back Door Max Speed (100%/s)

[const]

fdoor_maxspeed

0.75

[const]

bdoor_maxspeed

0.8

[const]

door_maxspeed_var

0.02

Gdzie:
"fdoor_maxspeed"- maksymalna prędkość przednich drzwi.
"bdoor_maxspeed"- maksymalna prędkość drzwi znajdujących się z tyłu pojazdu.
"door_maxspeed_var"- tu nie wiem o co dokładnie chodzi ale należy tutaj przepisać wartość z "door_acc_var" znajdującego się wyżej.

4.

Kod:
Front/Back Door Damper (100%/s)

[const]

door0_damper

1

[const]

door1_damper

1

[const]

door2_damper

1

[const]

door3_damper

1

Tutaj chodzi o amortyzację drzwi, 1- aktywne, 0- nieaktywne

5. "Dämpferkennlinie über Öffnungzustand" to radzę pominąć i nic nie zmieniać bo drzwi się przestaną zamykać lub otwierać.

6.

Kod:
Door Stop Reflexion Coefficient

[const]

door_refl

0.1

Tutaj mamy doczynienia z zatrzymaniem odbijania drzwi.

7.

Kod:
    Automatic Back Door Time

[const]

doorAftOpenTime

1.5

W tym miejscu ustawiamy czas zamknięcia drzwi jeżeli nikt nie przebywa w pobliżu nich.

8.

Kod:
Busstop Brake will only be activated belov MaxKMH:

[const]

Door_Bremse_Halte_MaxKMH

2

Tutaj ustawiamy sobie przy jakiej prędkości możemy wcisnąć hamulec przystankowy.

9. Teraz trochę wyjaśnień. W wszystkich wymienionych tu przypadkach"
0- Nie
1- Tak

"[const]
door_needs_stopbrakeswitch
0"

Oznacza, że drzwi potrzebują przycisku hamulca przystankowego.

"[const]
electric_doors
0"

Elektryczne drzwi

"[const]
thinking_doors
0"

W dosłownym znaczeniu będzie to oznaczało myślące drzwi.

"[const]
door_blocking
1"

Oznacza, że drzwi mogą być blokowane.

"[const]
door_blocking_area
0.1"

Obszar blokowania drzwi.

"[const]
door_blocking_speed
0.01"

Prędkość blokowania drzwi.

-------------------------------------------------------------------------------------------

Kod:
[const]

door_0_hub_speed

2

Prędkość piasty drzwi.

Tak idąc po kolei wszystkie drzwi od 0 do 3.
Uwaga! Podajemy w centymetrach na sekundę (cm/s)

-------------------------------------------------------------------------------------------

Kod:
[newcurve]

door_0_opn_speed

[pnt]

0

0.1

[pnt]

0.2

0.4

[pnt]

0.75

0.4

[pnt]

0.8

0.4

[pnt]

1

0.1

Gdzie:

"opn"- otwieranie
"cls"- zamykanie

Cyfry: 0, 0.2, 0.75, 0.8, 1, pokazują dziesiętną liczbę zaawansowanego otwierania drzwi.
Analogicznie postępujemy z każdą połową drzwi.

To wszystko, pozdrawiam, Filop.

Tworzenie tablic kierunkowych - dykt (w systemie rollband)

Sat, 12 Mar 2016 15:14:51 +0100

W wielu pojazdach do Omsi są rollbandy, lecz nie do każdej mapy są dołączone odpowiednie pliki, by działały one poprawnie. W związku z prywatną prośbą, w tym temacie, odpowiem tutaj na to zagadnienie

1. Utworzenie odpowiednich plików, w odpowiednim miejscu.
Kierujemy się do folderu OMSI 2/Vehicles/Anzeigen. Tutaj Omsi przechowuje pliki dotyczące rollbandów (pliki konfiguracyjne i tekstury).

Większość pojazdów korzysta z folderu podstawowego MANa SD79, czyli Rollband_SD79. Są też pojazdy, które korzystają z własnego folderu (Jelcz L11 (L11), Citybus O405 (Rollband_O405 itd.). Najlepiej po prostu przekopiować pliki, które zaraz utworzymy do wszystkich folderów z przedrostkiem Rollband_* i folderów dedykowanych jak L11.

2. Przygotowanie plików do edycji.
Wchodzimy w folder z plikami, najlepiej Rollband_SD79. Stamtąd bierzemy plik blanko.tga i kopiujemy do nowo utworzonego folderu na pulpit.

3. Właściwy etap edycji.
Otwieramy plik blanko.tga programem graficznym, polecam w tym celu użycie GIMPa czy Paint.NET.
Pojawia nam się... biały prostokąt - nasza dykta.

Tutaj możemy narysować właściwie cokolwiek, OMSI załaduje to z pliku graficznego.
UWAGA! Nie można zmieniać rozdzielczości tego pliku!

Po narysowaniu/napisaniu tego co potrzebujemy, przechodzimy dalej.

4. Poprawny zapis pliku.
Otwieramy plik .hof mapy, do której utworzyliśmy teksturę. Pliki te znajdują się w folderze pojazdu, do którego robimy rollbandy. Jeśli ich tam nie ma, to trzeba je sobie zorganizować - są to podstawy działania i modyfikowania gry.
Gdy już mamy .hof otwieramy go i patrzymy w jakim systemie jest on utworzony, szukamy odpowiedniego wpisu:
(na czerwono odpowiedni wpis, na zielono interesująca nas nazwa pliku)

Gdy już mamy ten wpis, kopiujemy zaznaczoną nazwę pliku i tak nazywamy utworzoną przez nas teksturę.

(jeśli brakuje wpisów z nazwą tekstury należy go odpowiednio uzupełnić, można posiłkować się tym poradnikiem: Link)

5. Umieszczenie pliku w odpowiednim miejscu.
Ponownie patrzymy do pliku .hof, szukamy wpisu w tym stylu:

Jeśli go nie znajdujemy - plik tekstury wrzucamy bezpośrednio do folderu OMSI 2/Vehicles/Anzeigen/
Jeśli jest taki wpis - musimy stworzyć folder o nazwie pokazanej we wpisie, tam kopiujemy nasz plik.

6. Efekt końcowy.
Tu raczej to czego się spodziewaliśmy po pokonaniu tego poradnika.

Dodanie możliwości wsiadania wszystkimi drzwiami tzw "Door mod"

Thu, 31 Dec 2015 16:23:52 +0100

Witam,
jako, że większość modeli pojazdów na scene omsi wychodzi głównie z niemiec (i pochodnych) system wsiadania jest zazwyczaj właśnie typowo niemiecki czyli wsiadanie pierwszymi drzwiami tylko i wyłącznie. Przerobienie tego systemu na system wsiadania wszystkimi drzwiami jest dość banalny i aż dziwię się, że do tej pory nie było żadnego poradnika jak to zmienić.

Tak więc zaczynajmy:

1.W interesującym nas modelu autobusu otwieramy interesujący nas plik .bus i sprawdzamy tam dwie rzeczy (Dla pojazdów przegubowych trzy)

a. Jaka jest dokładna nazwa pliku passengercabin.cfg

Kod:
[passengercabin]

model\passengercabin_GN92_main.cfg

b. Jaka jest dokładna nazwa pliku door.osc

Kod:
[script]

[...]

script\door-3.osc

[...]

c1. Jaka jest nazwa pliku .bus odpowiedzialnego za sekcję B (Punkt tylko dla pojazdów przegubowych)

Kod:
[couple_back]

MAN_GN92_trail.bus

false

c2. W pliku .bus przez nas znalezionych w punkcie c1 sprawdzamy nazwę passangerscabin sekcji B.

2.Kolejny krok to otworzenie wszystkich plików przez nas szukanych w dowolnym edytorze tekstu (polecam Notepad ++) oraz wykonanie ich kopii zapasowych.

3.W plikach passangerscabin.cfg szukamy takiej sekcji

Kod:
###################################

[entry]

0

[entry]

2

{noticketsale}

[exit]

10

[exit]

12

[linkToPrevVeh]

16

###################################

Kolejne wpisy [entry] oznaczają ścieżkę wejść a wpisy [exit] ścieżkę wyjść. Należy je liczyć od góry zawsze od 0 (osobno [entry] i osobno [exit])

Pierwszym ważnym krokiem będzie dopisanie pod ostatnim [entry] kolejne takie wpisy ale z numerami ścieżek (tą cyfrą pod spodem) zgodnie z numerami ścieżek jak we wpisach [exit] Zazwyczaj wpisy są dodawane zgodnie z kolejnością drzwi w pojeździe więc nie musimy się martwić o to który numer ścieżki to które drzwi.

Przykład uzupełnionego wpisu passangerscabin:

Kod:
###################################

[entry]

0

[entry]

2

{noticketsale}

[entry]

10

[entry]

12

[exit]

10

[exit]

12

[linkToPrevVeh]

16

###################################

Przy takim wpisaniu pasażerowie będą podchodzili do pierwszych drzwi w sytuacji gdy wszystkie drzwi będą zamknięte a w sytuacji gdy któreś drzwi otwarte to pasażerowie udadzą się do najbliższych otwartych.

Można uzyskać jeszcze inną sytuacje: Pasażerowie przy zamkniętych drzwiach udadzą się do najbliższych im drzwi jednakże nie będą reagowali na inne otwarte drzwi niż te, do których się udali w pierwszej kolejności. Uzyskać to można dodając pod danymi wejściami wpisy {withbutton}:

Kod:
[entry]

0

[entry]

2

{withbutton}

Po wykonaniu przez nas zmian zapisujemy pliki ale ich nie zamykamy, jeszcze się przydadzą.

4. Kolejnym etapem będzie otwarcie szukanego przez nas wcześniej pliku door.osc
W nim szukamy czegoś takiego:

Kod:
(L.L.door_0) 0.9 > (S.L.PAX_Entry0_Open)

    (L.L.door_1) 0.9 > (S.L.PAX_Entry1_Open) 

    (L.L.door_2) 0.9 > (L.L.door_3) 0.9 > && (S.L.PAX_Exit1_Open) (S.L.PAX_Exit2_Open)

    (L.L.door_4) 0.9 > (L.L.door_5) 0.9 > && (S.L.PAX_Exit3_Open) (S.L.PAX_Exit4_Open)

Teraz sprawdzamy czy nasze ścieżki się zgadzają, mówię sprawdzamy dlatego, że nieraz skrypt (szczególnie te nowsze oparte już na manie ng czyli z omsi 2) mają już wpisane ścieżki do odpowiednich drzwi. Wytłumaczę jak sprawdzić:

Kod:
(L.L.door_0) 0.9 > (S.L.PAX_Entry0_Open) - Wpis [entry] z passangerscabin o numerze 0 (czyli pierwszy od góry, bo zaczynamy liczenie od 0)

    (L.L.door_1) 0.9 > (S.L.PAX_Entry1_Open) - Wpis [entry] o numerze 1

    (L.L.door_2) 0.9 > (L.L.door_3) 0.9 > && (S.L.PAX_Exit1_Open) (S.L.PAX_Exit2_Open) (S.L.PAX_Entry2_Open) (S.L.PAX_Entry3_Open) - wpisy [entry] 2 i 3 na drzwiach jak widać o numerach 2 i 3 czyli w tym przypadku na drugiej parze drzwi

    (L.L.door_4) 0.9 > (L.L.door_5) 0.9 > && (S.L.PAX_Exit3_Open) (S.L.PAX_Exit4_Open) (S.L.PAX_Entry4_Open) (S.L.PAX_Entry5_Open)

Przy sprawdzaniu musimy zobaczyć po prostu czy dla danych drzwi pasują wpisy z numerami odpowiadającymi im z pliku passangerscabin. Skrzydła drzwi także liczymy od 0 od przodu. W przypadku gdy nasz wpis wygląda podobnie jak w pierwszym [code] należy dopisywać dla danych drzwi kolejne wpisy (S.L.PAX_EntryX_Open) Gdzie X to numer wpisu entry liczonego od góry od zera z pliku passangerscabin. (W przypadku pojazdu przegubowego wpisy entry i exit z sekcji B będą zawsze tak jakby pod wpisami z sekcji A)

Po sprawdzeniu/dopisaniu takich wpisów (S.L.PAX_EntryX_Open) dla drzwi zapisujemy plik i cieszymy się pasażerami wsiadającymi wszystkimi drzwiami.

DRL (Day running lights/Światła do jazdy dziennej)

Wed, 12 Nov 2014 00:51:23 +0100

Modyfikacja: DRL (Day running lights/Światła do jazdy dziennej)
Autor: Mattez

Opis:
Witam,

Poniższa modyfikacja daje możliwość wyposażenia pojazdu w światła do jazdy dziennej, czyli świateł, które włączają się po uruchomieniu silnika, a wyłączają po włączeniu świateł pozycyjnych lub mijania.

Jak to zrobić?
1. Po pierwsze, otwieramy plik .bus interesującego nas pojazdu i odszukujemy skrypt świateł oraz odpowiadający mu plik varlist:

2. Otwieramy z folderu Script skrypt świateł, w tym przypadku lights.osc i przed ostatnim {end} dopisujemy poniższy wpis:

Kod:
(L.L.engine_on)

    {if}

    (L.L.lights_stand) 0 =

        {if}

        1 (S.L.DRL)

        {else}

        0 (S.L.DRL)

    {endif}

    {else}

    0 (S.L.DRL)

{endif}

3. Otwieramy z folderu Script plik varlist odpowiadający skryptowi świateł, w tym przypadku lights_varlist.txt i na dole dopisujemy DRL

W tym momencie nasz model obsługuje już funkcję DRL. Jedyne, co pozostaje, to zaimplementować tą modyfikację do odpowiednich świateł. Można to zrobić na kilka sposobów, na przykład w światłach drogowych, lub w miejscu halogenów. Najprostszym sposobem jest podłączenie DRL pod światła drogowe, więc opiszę jak to zrobić.

4. Zaglądamy w plik .bus jeszcze raz, by odszukać jak nazywa się plik konfiguracyjny model naszego autobusu:

5. Otwieramy z folderu Model plik konfiguracyjny, w tym przypadku model_O530 G 4 Doors_RB_CG.cfg oraz za pomocą wyszukiwarki systemowej (CTRL+F) szukamy wartości lights_fern i klikamy kilka razy ponowne wyszukiwanie aż znajdzie nam lokalizację punktu świateł drogowych, która wygląda mniej więcej tak:

6. Powinny być dwa takie same wpisy (lewy i prawy reflektor) różniące się pierwszą wartością o znak "-". W obydwu wpisach zmieniamy wartość pod lights_fern (moc świateł) na "3", zaznaczamy obydwa wpisy, kopiujemy i wklejamy pod spodem.

7. We wklejonych dwóch wpisach zmieniamy wartość pod lights_fern na "1" oraz obydwa lights_fern zamieniamy na drl

Efekt (oczywiście w zależności od modelu) może wyglądać następująco:
Włączony silnik i zgaszone światła

Włączony silnik i włączone światła mijania

Włączony silnik i włączone światła drogowe

Modyfikacja: DRL (Day running lights/Światła do jazdy dziennej z przygaszaniem dodatkowo kierunkowskazów)
Autor: Mattez

Rożnica polega na tym, że włączenie dowolnego kierunkowskazu przygasza nam odpowiednią żarówkę w DRL. Oto jak to zrobić:
1. przejść cały powyższy poradnik tworzenia świateł DRL, z tą róznicą, że:
- w pliku model_xxxxx.cfg nie dajemy komendy DRL dla lewej i prawej lampki, tylko DRL_L dla lewej i DRL_R dla prawej
- w pliku xxxxxx_valist.txt od świateł zamist stałej DRL dodajemy dwie: DRL_L i DRL_R
- a sam skrypt w pliku osc świateł powinien wygądać następująco:

BEZ PRZYGASANIA PRZY WŁĄCZONYCH AWARYJNYCH:

Kod:
(L.L.engine_on)

    {if}

    (L.L.lights_sw_blinker) 2 = (L.L.lights_stand) 1 = ||

        {if}

        0 (S.L.DRL_R)

        {else}

        1 (S.L.DRL_R)

    {endif}

    {else}

    0 (S.L.DRL_R)

{endif}

(L.L.engine_on)

    {if}

    (L.L.lights_sw_blinker) 1 = (L.L.lights_stand) 1 = ||

        {if}

        0 (S.L.DRL_L)

        {else}

        1 (S.L.DRL_L)

    {endif}

    {else}

    0 (S.L.DRL_L)

{endif}

Z PRZYGASANIEM PRZY WŁĄCZONYCH AWARYJNYCH:

Kod:
(L.L.engine_on)

    {if}

    (L.L.lights_sw_blinker) 2 = (L.L.lights_stand) 1 = (L.L.lights_sw_warnblinker) 1 = || ||

        {if}

        0 (S.L.DRL_R)

        {else}

        1 (S.L.DRL_R)

    {endif}

    {else}

    0 (S.L.DRL_R)

{endif}

(L.L.engine_on)

    {if}

    (L.L.lights_sw_blinker) 1 = (L.L.lights_stand) 1 = (L.L.lights_sw_warnblinker) 1 = || ||

        {if}

        0 (S.L.DRL_L)

        {else}

        1 (S.L.DRL_L)

    {endif}

    {else}

    0 (S.L.DRL_L)

{endif}

Efekt w Video:

Modyfikację udostępniam na zasadzie licencji GNU/GPL3, czyli wolna amerykanka, jednak podczas publikacji na innych forach, czy w Waszych modelach z zaznaczeniem twórcy.

Poradnik 4: Przegub

Tue, 09 Sep 2014 22:13:09 +0200

Witam ponownie
Przedstawiam wam mój 4 poradnik do OMSI w którym opiszę wam jak zrobić swój pierwszy przegubowy autobus.
Proszę o nie przenoszenie na inne serwery oraz fora.

W razie problemów piszcie na forum.

Dopisane coś o czym zapomniałem.

PORADNIK CZĘŚĆ 4.pdf (Rozmiar: 1.41 MB / Pobrań: 219694)

Tworzenie przegubu

Sat, 07 Jun 2014 21:20:37 +0200

Tłumaczenie by Invis. Oryginał: http://www.omnibussimulator.de/forum/ind...post185098

Po Pierwsze musiałem stworzyć model jak zawsze.

Następnym krokiem jest stworzenie "armatury"

Baaardzo ważne: Pierwsza "kość" musi zaczynać się w punkcie 0 sceny (0/0/0) jak pokazano. W przeciwnym razie będzie w OMSI przesunięcie. Teraz musimy przełączyć się w "edit mode" i przesunąć "czoło" pierwszej kości jak pokazano na zdjęciu, wtedy stworzyć inne kości, przy użyciu funkcji "extrude" [E]. Ważne: Pozycja kości (wyłączając pierwszą) jest nieistotna fla OMSI, więc nie musisz pracować precyzyjnie w tym punkcie. Miło jest mieć możliwość testowania animacje z "pose mode" w blenderze.

Teraz po pierwsze wybierz "miechy", potem "armature", naciśnij [CTRL]+[P] i wybierz "armature", następnie "Don't create groups".
Teraz porządek wykonywanych czynności jest bardzo istotny:
Po pierwsze wybierz "armature", kolejno "pose mode" i kliknij PPM na "miechach" ,wybierz wtedy "weight paint mode"

Teraz możesz wybrać, każdą "kość" z PPM lub malować wierzchołki z LPM. W okienku po lewej, wyższym suwakiem , możesz wybrać nową "wagę" (jaką chcesz malować, 0 = niebieski, 1 = czerwony). Z tymi "wagami", możesz wyregulować wpływ każdej kości na wierzchołki.

W "buttons window" (domyślnie na dole), możesz wybrać na panelu "rectangle with yellow dots" w zakładce "armature bones" obok "BO:" nazwę kości. To jest bardzo ważne, ponieważ musisz "powiedzieć" OMSI, któa kość powinna być poruszana jak. W moim przypadku, małe kości, mają nazwy "Gelek_A" do "Gelenk_D", duża jest nieważne, dopóki się nie rusza.
Do eksportu, musisz wyciągnąć mesh armatury i miechów w oddzielne pliki blendera. Następnie użyć "export all". Jeśli wszystko poszło dobrze, plik x powinien zawierać wszystkie nazwy kości jako nazwy grup wierzchołków. teraz skonwertuj pliki do o3d jak zawsze.

Aby zaanimować "miechy", musisz stworzyć 4 obiekty pomocnicze, które opisują ruchy jako współrzędne

Pierwsza (Dummy_A) będzie poruszać się o ćwierć, ostatnia wykona cały ruch przyczepy. Cztery obiekty pomocnicze muszą byc dodane w pierwszych punktach. co znaczy bezpośrednio za wszystkimi wpisami [texttexture] i przed pierwszym "normalnym" wpisem [mesh] i kolejność czterech wpisów jest również bardzo ważne, ponieważ połączenie do kości będzie wykonane przy użyciu wpisu [setbone] przez indeks wpisu [mesh] obiektu pomocniczego.

Poradnik tłumaczyłem dla siebie, ale postanowiłem się podzielić, może komuś się to przyda.

Budowa pojazdu - video tutoriale

Thu, 23 Jan 2014 16:16:38 +0100

Poradniki jak konwertować swój pojazd do OMSI

Odcinek 1 : Jak konwertować bryłę ?

Odcinek 2 : Koła i wycieraczki

Odcinek 3 : Drzwi
Film

Kod do drzwi

Poradnik w formie pisemnej by NickTM : http://strefa-omsi.pl/Watek-Wielki-porad...o-OMSI--79

passengercabin.cfg - pozycje pasażerów, kierowcy i innych elementów

Sat, 17 Aug 2013 00:27:15 +0200

Tym razem skupię się na opisaniu pliku passengercabin.cfg
Treść dostępna jest wyłącznie dla zarejestrowanych i zalogowanych.

W pliku tym deklarujemy pozycję kierowcy, pozycje pasażerów, wejścia i wyjścia z pojazdu, współrzędne kasowników i wydawania biletów oraz reszty.

[drivpos]
Współrzędne określające pozycję kierowcy.

Przykładowy wpis powinien wyglądać następująco:

Kod:
[drivpos]

-0.620

6.27

1.45

0.4

0

Pierwsze trzy linijki za słowem kluczowym, to pozycja hmm... powiedzmy, że miejsca między pośladkami siedzącego kierowcy (dokładnie w środku, wybaczcie trudno to inaczej wyjaśnić ). Oczywiście pierwsza współrzędna jest iksową, druga igrekową, trzecia zetową. Zgodnie z obrazkiem:
http://strefa-omsi.pl/attachment.php?aid=265
Czwarta liczba określa wysokość siedziska fotela mierząc od podłogi - jeśli tu podamy 0 kierowca będzie stał. Ostatnia natomiast to obrót podawany w stopniach. Jeśli ustawimy go przykładowo na 90 - wtedy pozycja kierowcy będzie przekręcona o 90 stopni w prawo, jeśli jednak na -45 wtedy o 45 stopni w lewo.

[passpos]
Pozycje pasażerów w pojeździe.

Przykładowa deklaracja wygląda identycznie do poprzedniej, zmianą jest tylko inne słowo kluczowe:

Kod:
[passpos]

-0.771

5.331

1.291

0.50

0

Trzy pierwsze to więc współrzędne siedzenia bądź miejsca pośrodku stóp, jeśli jest to miejsce stojące, kolejna określa wysokość siedziska ponad podłogą (jeśli miejsce jest stojące, wartość należy ustawić na 0), a ostatnia to obrót wg. reguł podanych wcześniej. Liczba powyższych deklaracji wpływa na liczbę osób, które będą mogły wsiąść do pojazdu. Jeśli wpisów [passpos] będzie załóżmy 10, to większej liczby pasażerów nie uświadczymy.

[entry]
Numer punktu ścieżki najbliższy wejścia do pojazdu.

Może troszkę zamotałem powyższy opis. Podajmy więc przykład:

Kod:
[entry]

0

[entry]

22

Takie dwa wpisy oznaczają, że chcąc wejść do pojazdu, pasażerowie muszą zbliżyć się do punktu pathpnt (patrz temat http://strefa-omsi.pl/Watek-paths-cfg-sc...ylko--2152) oznaczonego numerem 0 lub 22. Mamy zatem dwa wejścia do pojazdu Oczywiście należy pamiętać, że punkty te w pliku paths.cfg nie są numerowane, jeśli nie zrobimy tego sami. Szczegóły w podanym przed chwilą temacie.

Pod odpowiednimi wpisami [entry] można dodać słowa pomocnicze:
{noticketsale} - oznacza, że przy tym wejściu nie jest "prowadzona" sprzedaż biletów, a więc wpisanie powyższego powoduje, że do tego wejścia nie będzie podchodziła osoba, która chce kupić bilet
{withbutton} - wejście z ciepłym guzikiem z zewnątrz, oczywiście funkcję taką należy najpierw ująć w skryptach, aby zadziałała (szczegóły w temacie: http://strefa-omsi.pl/Watek-Road-to-OMSI...1-04--1088).

Kolejność wpisów [entry] jest dość ważna ze względu na skrypty. Pierwszy wpis będzie odpowiadał wyrażeniu PAX_Entry0_Open (na przykład S.L.PAX_Entry0_Open), drugi wpis - PAX_Entry1_Open i tak dalej.

[exit]
Numer punktu ścieżki najbliższy wyjścia z pojazdu.

Sytuacja adekwatna do poprzedniej, wpisujemy na przykład:

Kod:
[exit]

22

[exit]

25

Są zatem zadeklarowane dwa wyjścia z pojazdu. Pasażerowie chcący wysiąść będą kierowali się do tych właśnie punktów ustalonych przez plik paths.cfg

Pomocnicze słowa kluczowe nie mają tutaj zastosowania.

Kolejność wpisów [exit] także ma znaczenie dla skryptów. Pierwszy z nich jest opisywany wyrażeniem PAX_Exit0_Open, drugi PAX_Exit1_Open itd.
Krótki opis tych wyrażeń skryptowych (zarówno dla wejść jak i wyjść) można znaleźć tutaj: http://strefa-omsi.pl/Watek-Zmienne-syst...OMSI--1164

[stamper]
Numer punktu ścieżki najbliższy kasownikowi i jego pozycja.

Deklaracja wygląda na przykład tak:

Kod:
[stamper]

4

0.508

3.898

1.924

Cyferka po słowie kluczowym to numer punktu ścieżki pathpnt (o tym jest już kilka słów wyżej), który jest najbliższy pozycji kasownika. Tam właśnie pasażerowie będą się zatrzymywać aby "skasować" bilet. Następnie podawane są jego współrzędne - kolejno po osi X, Y i Z. Z tego co wyczytałem - kasownik może być tylko jeden. Skorzystanie z niego wyzwala także dźwięk poprzez wyzwalacz ev_Stamper.

[ticket_sale]
Punkt ścieżki odpowiadający miejscu kupna biletu.

Czyli to takie miejsce, gdzie pasażer przystaje chcąc kupić bilet u kierowcy. Jego deklaracja:

Kod:
[ticket_sale]

2

-0.189

4.519

1.614

Adekwatnie do poprzedniego - pierwsza cyfra odpowiada numerowi punktu ścieżki pathpnt w paths.cfg , a następnie podawane są współrzędne punktu (X, Y, Z), do którego pasażer sięga, by odebrać bilet. Nie jest to jednak pozycja samego biletu.

[ticket_sale_money_point]
Miejsce określające pozycję przyjmowania pieniędzy od pasażerów oraz wydawania im biletów.

W zasadzie opis już wyjaśnia wszystko, więc od razu zajmujemy się wpisem:

Kod:
[ticket_sale_money_point]

050

050

697

035

035

Pierwsze trzy linijki za słowem kluczowym to współrzędne X, Y i Z punktu, gdzie ludzie będą kładli kasiorkę, a kierowca bilecik. Dwie ostatnie to tzw. odchylenia po współrzędnej X i Y, aby to dobrze zobrazować przedstawiam mini-grafikę (mistrz Painta powraca):

passcab1.gif (Rozmiar: 7.35 KB / Pobrań: 205)
A więc wpisanie odchyleń od głównego punktu tworzy nam pole (kwadrat lub prostokąt), w którym to będą rozmieszczane pieniądze i bilet.

Podczas zakupów używane są wyzwalacze: ev_ticketsale_giveticket , ev_ticketsale_givemoney i ev_ticketsale_taketicket do obsługi dźwięków.

[ticket_sale_change_point]
Miejsce, gdzie pojawia się wydawana reszta.

Właściwie wszystko wygląda identycznie jak przy poprzednim słowie kluczowym, przykład:

Kod:
[ticket_sale_change_point]

050

050

697

035

035

Podajemy więc słowo kluczowe, następnie trzy współrzędne i odchyły po osi X i Y. Reguły są identyczne jak poprzednio. Punkt ten może, ale nie musi pokrywać się z miejscem na pieniądze od pasażerów i kupowany bilet.

[linkToPrevVeh] oraz [linkToNextVeh]
Miejsce łączące ścieżki pasażerów między członami pojazdu przegubowego.

Przykład:

Kod:
[linkToPrevVeh]

16

lub

Kod:
[linkToNextVeh]

0

Słowa [linkToPrevVeh] używamy w pierwszym członie (z kierowcą), [linkToNextVeh] w przyczepce. Pod tymi słowami wystarczy podać punkt z pliku paths.cfg, gdzie ścieżki będą się łączyć.

Poradnik został napisany wyłącznie dla Forum http://strefa-omsi.pl i nie może być rozpowszechniany we fragmentach lub w całości na innych stronach bez zezwolenia głównego Autora.

paths.cfg - ścieżki wewnątrz pojazdu i nie tylko

Mon, 12 Aug 2013 13:29:58 +0200

Czas na kolejny poradnik dotyczący tym razem plików paths.cfg
Treść dostępna jest wyłącznie dla zarejestrowanych i zalogowanych.

Za co odpowiedzialny jest ten plik? Przede wszystkim za ścieżki poruszania się pasażerów wewnątrz pojazdu, ale nie tylko. Objaśnie pokrótce wszystkie słowa kluczowe, które możemy tam umieszczać oraz dane niezbędne do ich zdefiniowania.

[stepsoundpack]
To słowo kluczowe definiuje pliki dźwiękowe odtwarzane jako dźwięki kroków po pokładzie naszego pojazdu w trakcie rozgrywki.

Struktura tego wpisy wygląda następująco:

Kod:
[stepsoundpack]

5

Step_01.wav

Step_02.wav

Step_03.wav

Step_04.wav

Step_05.wav

Pierwsza linijka to oczywiście słowo kluczowe, cyfra poniżej to liczba wpisów z nim powiązanych, czyli na chłopski rozum - liczba plików dźwiękowych. Następnie wymienione są nazwy plików tych plików. Pamiętajmy, że muszą być w formacie .wav i znajdować się w podfolderze \Sounds\Passengers głównego katalogu gry (a nie katalogu pojazdu).
Naturalnie, możemy definiować kilka takich paczek, na przykładzie standardowych MAN-ów wygląda to następująco:

Kod:
0 - Normal:

[stepsoundpack]

5

Step_01.wav

Step_02.wav

Step_03.wav

Step_04.wav

Step_05.wav

1 - Vorne oben:

[stepsoundpack]

3

Step_OV_01.wav

Step_OV_02.wav

Step_OV_03.wav

2 - Treppe:

[stepsoundpack]

6

Step_St_01.wav

Step_St_02.wav

Step_St_03.wav

Step_St_04.wav

Step_St_05.wav

Step_St_06.wav

A więc mamy tutaj trzy deklaracje paczek dźwiękowych - kroki "normalne", te na górnym pokładzie, oraz odtwarzane podczas używania schodów. Jak przypisać je do poszczególnych ścieżek? Zajmiemy się tym deczko później. Na razie zapamiętajmy, że ich numeracja zaczyna się od zera. Czyli indeks 0, odpowiada za kroki "normalne", 1 za górny pokład a 2 za schody. Oprócz tego trzeba nadmienić, że deklaracje paczek dźwiękowych powinny być na samym początku pliku paths.cfg

[pathpnt]
Te wpisy odpowiadają za deklarację punktów ścieżek pasażerów (czyli punktów, przez które będą oni przechodzić przemieszczając się w pojeździe).

Aby dokładnie ustalić te punkty, musimy mieć przede wszystkim model 3D danego pojazdu, dzięki czemu punkty możemy ustalić co do centymetra.

Sam wpis wygląda na przykład tak:

Kod:
[pathpnt]

1.25

5.018

0.46

Poruszamy się w trójwymiarowym układzie współrzędnych. Pierwsza wartość oznacza współrzędną po osi X, druga - po osi Y, trzecia natomiast po osi Z.
Zwyczajowo przyjęło się, że osie ustalane są w sposób następujący:

paths_wsp.jpg (Rozmiar: 28.56 KB / Pobrań: 807)

Każdy taki wpis warto poprzedzić cyfrą (licząc od zera), dzięki czemu późniejsze ich połączenie ich jest bajecznie proste, chodzi mi dokładnie o taką strukturę:

Kod:
0

[pathpnt]

1.25

5.018

0.46

1

[pathpnt]

0.551

5.018

0.57

2

[pathpnt]

0.223

4.608

0.57

itd...

Aby uzyskać współrzędne, należy otworzyć model w programie 3D i w zależności od tegoż - odpowiednio je "pobrać". Jeśli chodzi o Blendera - najprostszym sposobem jest chyba "rozebranie" pojazdu z karoserii i innych elementów, które będą przeszkadzać - zostawiając jedynie podłogę oraz ewentualnie inne miejsca, po których poruszać się będą pasażerowie. Następnie tworzymy sobie mały sześcianik, klikamy na niego prawym klawiszem myszy, wciskamy TAB i N, w pasku, który się nam pojawi wciskamy "Global", dzięki czemu uzyskamy punkty w odniesieniu do głównego układu współrzędnych pojazdu. Teraz wystarczy przesuwać sześcianik po miejscach, po których ludzie będą się poruszać spisywać dane i po kolei tworzyć pathpointy w pliku. Punkty, które powinniśmy brać pod uwagę, to punkty dokładnie w środku utworzonego sześcianu (więc trzeba go odpowiednio wyrównywać).

Praktyka pokazuje, że współrzędne nie muszą być super precyzyjne, chyba, że jesteśmy perfekcjonistami. Wkrótce dołączę tutaj screeny z Blendera dla "mniej kumatych"

[pathlink]
Są to po prostu "połączenia" punktów zdefiniowanych wcześniej...

...a wyglądają na przykład tak:

Kod:
[pathlink]

0

1

[pathlink]

1

2

Co to oznacza? Otóż dzięki takiej deklaracji - pasażerowie będą poruszali się ścieżką od punktu 0 do punktu 1, w punkcie 1 będą mogli przemieścić się do punktu 2 lub wrócić do punktu 0 itd. Więc taki wpis pozwala na przemieszczanie się do przodu i do tyłu wzdłuż ścieżek wyznaczonych przez wcześniej zadeklarowane punkty "pathpnt". Dlatego ważna jest numeracja tam, aby nie pogubić się w ustalaniu połączeń tutaj.

[pathlink_oneway]
Sytuacja adekwatna do [pathlink], ale tutaj możemy wskazać, że ruch po ścieżce odbywa się "jednokierunkowo".

Taki kod:

Kod:
[pathlink_oneway]

0

1

[pathlink_oneway]

1

2

spowoduje, że pasażer startując z punktu 0, będzie mógł przemieścić się do punktu 1, ale z tego punktu już się nie cofnie. Będzie mógł jedynie przejść do punktu 2, skąd także nie będzie miał powrotu. Czyli po prostu ścieżka jednokierunkowa.

[next_roomheight]
Wysokość danej przestrzeni pasażerskiej.

To słowo powinno się znaleźć przed pierwszym wpisem [pathlink] lub [pathlink_oneway] oraz przed każdym następnym, jeśli wysokość przestrzeni pasażerskiej przed daną ścieżką się zmienia. Lepiej jest to wyjaśnić na przykładzie:

Kod:
[next_roomheight]

2

[pathlink]

0

1

[pathlink]

1

2

[next_roomheight]

1.8

[pathlink]

2

3

Powyższe oznacza ni mniej ni więcej, jak to, że od punktu 0 do punktu 2 wysokość przestrzeni pasażerskiej ustalona jest na 2 metry, natomiast od punktu 2 do 3 wynosi ona już 1.8 metra. Po co te deklaracje? Otóż w przypadku, gdy mamy do czynienia z autobusem piętrowym lub niskowejściowym (czyli o zmiennej wysokości podłogi, ale z co najmniej jednym "niskim" wejściem) może się okazać, że głowy pasażerów wyglądają ponad "sufit". Wtedy wystarczy zadeklarować odpowiednią wysokość, by pasażerom wyrósł garb na plecach i nie zawadzali o górne części pojazdu.

[next_stepsound]
Przypisanie paczek dźwiękowych kroków do odpowiednich ścieżek.

Tutaj sytuacja ma się adekwatnie do [next_roomheight]. Przed danymi ścieżkami należy wskazać indeks paczki dźwiękowej kroków (zadeklarowanych na samym początku pliku), jakie mają odtwarzać się podczas przemieszczania się wzdłuż nich. Jeśli chcemy używać tylko jednej paczki - wystarczy jeden taki wpis przed pierwszym pathlinkiem. Ale możemy sytuację nieco urozmaicić:

Kod:
[next_stepsound]

0

[pathlink]

0

1

[next_stepsound]

1

[pathlink]

1

2

[next_stepsound]

2

[pathlink]

2

3

Taka struktura spowoduje, że jeśli pasażer przemieszczał się będzie z punktu 0 do punktu 1, odtwarzać się będą dźwięki o indeksie 0 (czyli z pierwszego wpisu [stepsoundpack]), podróżując z punktu 1 do punktu 2 OMSI używać będzie dźwięków z paczki o indeksie 1 (z drugiego wpisu [stepsoundpack]), a z 2 do 3 kolejnej paczki i tak dalej.

Należy tutaj uważać, bo jeśli użyjemy paczki, której wcześniej nie zadeklarowaliśmy lub pomylimy nazwy plików we wpisach [stepsoundpack], mogą pojawiać się bliżej niezidentyfikowane błędy.

Oczywiściem wpisy [next_roomheight] oraz [next_stepsound] możemy łączyć. Wygląda to na przykład tak:

Kod:
[next_stepsound]

0

[next_roomheight]

2

[pathlink]

0

1

[next_stepsound]

1

[pathlink]

1

2

[next_stepsound]

2

[next_roomheight]

1.8

[pathlink]

2

3

Poradnik został napisany wyłącznie dla Forum http://strefa-omsi.pl i nie może być rozpowszechniany we fragmentach lub w całości na innych stronach bez zezwolenia głównego Autora.

Boundingbox - obwiednia

Thu, 08 Aug 2013 00:53:16 +0200

Tym razem bardzo krótkie wyjaśnienie kwestii dotyczącej obwiedni pojazdu (ang. "boundingbox").

Otóż obwiednia jest niezbędna do odpowiednich wyliczeń dla danych geometrycznych pojazdu, a przede wszystkim - symulacji kolizji. Tworzy ona niejako prostopadłościan wokół modelu, którego ściany stanowią "granice" wykrywania kolizji.

Deklarację obwiedni można znaleźć pod słowem kluczowym:

Kod:
[boundingbox]

znajdującym się w pliku .bus lub .ovh pojazdu.

Aby odpowiednio ustawić obwiednię musimy znać przede wszystkim:
- szerokość pojazdu bez lusterek - podawaną w metrach
- długość pojazdu - także podawaną w metrach
- wysokość pojazdu - w tej samej jednostce jak wyżej

Znając powyższe, możemy zabierać się za wklepywanie odpowiednich wartości pod wcześniej wymienione słowo kluczowe. Powinny się tam znaleźć odpowiednio dane o:
- szerokości pojazdu
- długości pojazdu
- wysokości pojazdu
- przesunięciu punktu centralnego obwiedni od punktu środkowego pojazdu (niem. Nullpunkt, czyli punkt 0,0,0 w pliku 3D pojazdu) po osi X (a więc tej od szerokości) w metrach
- przesunięciu punktu centralnego obwiedni od punktu środkowego pojazdu po osi Y (od długości) w metrach
- przesunięciu punktu centralnego obwiedni od punktu środkowego pojazdu po osi Z (od wysokości) w metrach

Jeśli ktoś nadal nie rozumie trzech ostatnich myślników - wyjaśniam. Obwiednia jest tworzona wokół pewnego punktu, którą przetłumaczyłem sobie jako "punkt centralny obwiedni". Skoro operujemy w 3D, mamy trzy współrzędne tego punktu: X, Y i Z. Od niego "rozwijane" są odległości podawane wcześniej. Czyli ustawiając szerokość w pierwszym myślniku na 2 metry a w czwartym myślniku przesunięcie 0 - mamy taką sytuację:

bound1.gif (Rozmiar: 6.65 KB / Pobrań: 200)
Kolizja po tej osi zostanie wykryta, gdy jakiś obiekt znajdzie się w pasie między współrzędnymi -1 a 1 na osi X biorąc pod uwagę wartości z programu 3D.

Jeśli natomiast w czwartym myślniku podamy przesunięcie -0.5:

bound2.gif (Rozmiar: 6.9 KB / Pobrań: 158)
Tutaj kolizja po tej osi zostanie wykryta, gdy jakiś obiekt znajdzie się w pasie między współrzędnymi -1,5 a 0,5 na osi X biorąc pod uwagę wartości z programu 3D.

Adekwatna sytuacja ma się dla pozostałych osi.

Przy ustawieniu trzech ostatnich myślników na 0 - punkt centralny obwiedni = punktowi 0,0,0 w układzie współrzędnych w programie 3D.
O ile przestawianie punktu centralnego dla szerokości akurat większego sensu zazwyczaj nie ma, o tyle, żeby uwzględnić wystający przedni zderzak, zwykle wartość przesunięcia dla długości (piąty myślnik) nieco odbiega od wartości 0. Pewnikiem jest, że w 99% przypadków wymagane jest ustawienie odpowiedniego przesunięcia po osi Z, czyli dla wysokości, żeby obwiednia nie wtapiała się niepotrzebnie w ziemię oraz żeby niski autobus zmieścił się w np. tunelu bądź pod innymi obiektami.

Gotowy wpis obwiedni wygląda na przykład tak:

Kod:
[boundingbox]

2.5

11.46

3.76

0

-0.01

2.29

Niepoprawne ustawienie wartości może skutkować dziwnymi i śmiesznymi kolizjami podczas jazdy. Często winę za tzw "niewidzialne ściany" zrzuca się na twórców map, tymczasem nie wszystkie pojazdy mają odpowiednio ustawioną obwiednię i przez to wywoływane są nierealistyczne kolizje z elementami scenerii.

Poradnik został napisany wyłącznie dla Forum http://strefa-omsi.pl i nie może być rozpowszechniany we fragmentach lub w całości na innych stronach bez zezwolenia głównego Autora.

Makra systemowe OMSI

Thu, 13 Jun 2013 15:31:09 +0200

Kolejny krok przybliżający nas do opanowania skryptów OMSI to poznanie wbudowanych makr systemowych. Wersja dla niezarejestrowanych obejmuje wyłącznie makra dotyczące obiektów scenerii. Jeśli zauważyłeś błąd lub nieścisłość - napisz do mnie Prywatną Wiadomość w tej sprawie.

Obiekty scenerii
Dyrektywy zadeklarowane w pliku \program\callbacklist_scenobj.txt

GetArrBusLine
Wejściowa wartość stosu: Stack0 - indeks nadchodzącego pojazdu
Wyjściowa wartość stosu: Stringstack0 - aktualny numer linii tego pojazdu
Opis: Aby użyć tej funkcji, dany obiekt należy przypisać do przystanku (za pomocą Parent to). Zapisuje na wierzchołku stosu łańcuchowego numer linii następnego autobusu, według kolejności przyjazdów określonych przez indeks.
Przykład: 0 (M.V.GetArrBusLine) - zwraca numer linii następnego pojazdu, 1 (MVGetArrBusLine) - zwraca numer linii drugiego najbliższego wg. kolejności pojazdu

GetArrBusTerminus
Wejściowa wartość stosu: Stack0 - indeks nadchodzącego pojazdu
Wyjściowa wartość stosu: Stringstack0 - kierunek tego pojazdu
Opis: Działa na tej samej zasadzie jak GetArrBusLine, zwraca kierunek (końcowy przystanek) pojazdów
Przykład: 0 (M.V.GetArrBusTerminus) - zwraca kierunek następnego pojazdu, 1 (M.V.GetArrBusTerminus) - zwraca kierunek drugiego najbliższego wg. kolejności pojazdu

GetArrBusTimeDiff
Wejściowa wartość stosu: Stack0 - indeks nadchodzącego pojazdu
Wyjściowa wartość stosu: Stack0 - czas do przyjazdu tego pojazdu na przystanek
Opis: Działa na tej samej zasadzie jak GetArrBusLine, zwraca czas w sekundach do przyjazdu najbliższego pojazdu aż do osiągnięcia przez niego tego przystanku
Przykład: 0 (MVGetArrBusTimeDiff) - zwraca czas do przyjazdu najbliższego pojazdu na przystanek, 1 (M.V.GetArrBusTerminus) - zwraca tenże czas dla drugiego najbliższego wg. kolejności pojazdu

Pojazdy
Dyrektywy zadeklarowane w pliku \program\program\callbacklist_roadvehicle.txt

GetRouteIndex
Wejściowa wartość stosu: Stack0 - numer trasy (route) pojazdu
Wyjściowa wartość stosu: Stack0 - indeks trasy
Opis: Przeszukuje plik .HOF w celu znalezienia fragmentu kodu przynależącego do danego numeru trasy

GetBusstopString
Wejściowe wartości stosu: Stack1 - indeks przystanków oraz Stack0 - indeks łańcuchowy
Wyjściowa wartość stosu: Stringstack0 - nazwa przystanku
Opis: Dostarcza z pliku .HOF informacje dotyczące przystanku ustalanego za pomocą wyżej wymienionych danych wejściowych.
Przykład: 5 2 (MVGetBusstopString) zwraca nazwę szóstego przystanku (bo liczymy od zera) o trasie z indeksem 2.

GetTerminusString
Wejściowe wartości stosu: Stack1 - indeks kierunkowy oraz Stack0 - indeks łańcuchowy
Wyjściowa wartość stosu: Stringstack0 - nazwa kierunku
Opis: Dostarcza z pliku .HOF informacje dotyczące kierunku ustalanego za pomocą wyżej wymienionych danych wejściowych.
Przykład: 7 3 (M.V.GetBusstopString) zwraca nazwę ósmego kierunku (bo liczymy od zera) trasy z indeksem 3.

GetRouteTerminusIndex
Wejściowe wartości stosu: Stack0 - indeks trasy (licząc od zera)
Wyjściowa wartość stosu: Stack0 - indeks kierunku (licząc od zera)
Opis: Zwraca indeks domyślnego kierunku dla indeksu danej trasy.

GetTerminusIndex
Wejściowe wartości stosu: Stack0 - kod kierunku
Wyjściowa wartość stosu: Stack0 - indeks kierunku
Opis: Zwraca indeks kierunku biorąc pod uwagę aktualny jego kod.

GetTerminusCode
Wejściowe wartości stosu: Stack0 - indeks kierunku
Wyjściowa wartość stosu: Stack0 - kod kierunku
Opis: Działanie dokładnie odwrotne do GetTerminusIndex. Tutaj to kod kierunku ustalany jest za pomocą indeksu.

GetBusstopCount
Wejściowe wartości stosu: Stack0 - indeks trasy
Wyjściowa wartość stosu: Stack0 - liczba przystanków
Opis: Zwraca liczbę przystanków trasy o danym indeksie. Należy pamiętać, że ta wartość nie jest liczona od zera. Przykładowo, jeśli na trasie są dwa przystanki, wartość wyjściowa będzie wynosiła "2".

GiveChangeCoin
Wejściowe wartości stosu: Stack0 - indeks pieniężny
Wyjściowa wartość stosu: brak
Opis: Warunkuje, jaki pieniądz zostanie użyty np dla skryptów dotyczących automatów wydających resztę.
Przykład: 2 (M.V.GiveChangeCoin) oznacza użycie (np. wydanie) pieniądza o indeksie "2".

GetRouteBusstopIdent
Wejściowe wartości stosu: Stack1 - indeks trasy oraz Stack0 - przystankowy indeks trasy
Wyjściowa wartość stosu: Stringstack0 - identyfikator przystanku
Opis: Zwraca identyfikator przystanku (prawdopodobnie jest to po prostu jego nazwa lub skrócona nazwa) odpowiadający danym wejściowym.
Przykład: 3 6 (M.V.GetRouteBusstopIdent) zwraca identyfikator siódmego przystanku czwartej trasy (bo wskaźniki stosu liczone są tu od zera).

GetBusstopIndex
Wejściowe wartości stosu: Stringstack0 - identyfikator przystanku
Wyjściowa wartość stosu: Stack0 - indeks przystanku
Opis: Zwraca indeks przystanku w zależności od jego identyfikatora.
Przykład: "Reimerweg" (M.V.GetBusstopIndex) zwraca indeks przystanku o identyfikatorze Reimerweg.

GetTTBusstopCount
Wejściowe wartości stosu: brak
Wyjściowa wartość stosu: Stack0 - liczba przystanków
Opis: Zwraca liczbę przystanków dla bieżącego rozkładu jazdy.

GetTTBusstopIndex
Wejściowe wartości stosu: brak
Wyjściowa wartość stosu: Stack0 - indeks aktualnego przystanku
Opis: Zwraca indeks aktualnego przystanku dla bieżącego rozkładu jazdy.

GetTTTerminusIndex
Wejściowe wartości stosu: brak
Wyjściowa wartość stosu: Stack0 - indeks aktualnego kierunku
Opis: Zwraca indeks aktualnego kierunku dla bieżącego rozkładu jazdy.

GetTTLineString
Wejściowe wartości stosu: brak
Wyjściowa wartość stosu: Stringstack0 - numer linii
Opis: Zwraca numer linii dla bieżącego rozkładu jazdy.

GetTTDelay
Wejściowe wartości stosu: brak
Wyjściowa wartość stosu: Stack0 - spóźnienie w sekundach
Opis: Zwraca spóźnienie obliczane w sekundach dla bieżącego rozkładu jazdy.

GetTTBusstopName
Wejściowe wartości stosu: Stack0 - indeks aktualnego przystanku
Wyjściowa wartość stosu: Stringstack0 - nazwa aktualnego przystanku
Opis: Zwraca nazwę aktualnego przystanku biorąc pod uwagę zerową wartość stosu indeksu przystankowego.

GetTTBusstopDep
Wejściowe wartości stosu: Stack0 - indeks aktualnego przystanku
Wyjściowa wartość stosu: Stack0 - czas odjazdu z przystanku w sekundach
Opis: Zwraca rozkładowy czas odjazdu z przystanku w sekundach, na który to przystanek wskazuje zerowa wartość stosu indeksu przystankowego.

GetTTBusstopArr
Wejściowe wartości stosu: Stack0 - indeks aktualnego przystanku
Wyjściowa wartość stosu: Stack0 - czas przyjazdu na przystanek w sekundach
Opis: Zwraca rozkładowy czas przyjazdu na przystanek w sekundach, na który to przystanek wskazuje zerowa wartość stosu indeksu przystankowego.

GetTicketName
Wejściowe wartości stosu: Stack0 - indeks biletowy
Wyjściowa wartość stosu: Stringstack0 - nazwa biletu
Opis: Zwraca nazwę biletu w zależności od jego indeksu.

GetTicketValue
Wejściowe wartości stosu: Stack0 - indeks biletowy
Wyjściowa wartość stosu: Stringstack0 - cena biletu
Opis: Zwraca cenę biletu w zależności od jego indeksu.

GetHumanCountOnPathLink (od OMSI w wersji 1.03)
Wejściowe wartości stosu: Stack0 - indeks ścieżki (Pathlink)
Wyjściowa wartość stosu: Stack0 - liczba pasażerów
Opis: Zwraca aktualną liczbę pasażerów na konkretnej ścieżce.

NrSpecRandom (od OMSI 2)
Wejściowe wartości stosu: Stack0 - wartość początkowa ("Seed")
Wyjściowa wartość stosu: Stack0 - pseudolosowa wartość
Opis: Zwraca specyficzny, losowy numer związany z pojazdem. Sztuczka tutaj polega na tym, że kombinacja "Seed" i numeru taborowego pojazdu zawsze daje ten sam ostateczny numer losowy. Aby otrzymywać inne numery losowe dla jednego pojazdu, wystarczy zmienić wspomniany "Seed".

GetHeightAbovePoint (od OMSI 2)
Wejściowe wartości stosu: Stack2: - X , Stack1: - Y , Stack0: - Z
Wyjściowa wartość stosu: Stack0 - wysokość nad ziemią
Opis: Zwraca wysokość nad poziomem gruntu, mierzonej wzdłuż odwróconej osi Z związanej z pojazdem i określanej przez punkty X, Y, Z.

GetDepotStringGlobal (od OMSI 2)
Wejściowe wartości stosu: Stack0: - indeks łańcuchowy
Wyjściowa wartość stosu: Stack0 - globalstring pliku .hof
Opis: Zwraca łańcuch zawierający informacje spod słowa [global_strings] aktualnie używanego pliku .hof . Indeks łańcuchowy jest adekwatny do zerowej pozycji tej listy.

Tekstury skryptowe (Script-Texturen)
Tylko w OMSI 2, używane w skryptach dotyczących zarówno obiektów scenerii jak i pojazdów. Dyrektywy zadeklarowane w pliku \program\callbacklist_scripttex.txt

STNewTex
Wejściowa wartość stosu: Stack0 - indeks tekstury (kolejność z pliku .cfg pojazdu)
Wyjściowa wartość stosu: brak
Opis: Inicjalizacja tekstury skryptowej.

STLock
Wejściowa wartość stosu: Stack0 - indeks tekstury
Wyjściowa wartość stosu: brak
Opis: Blokowanie tekstury, oznaczające możliwość dostępu do odczytu i zapisu.

STUnlock
Wejściowa wartość stosu: Stack0 - indeks tekstury
Wyjściowa wartość stosu: brak
Opis: Odblokowanie tekstury, czyli anulowanie możliwości dostępu do odczytu i zapisu i przygotowanie do wyświetlenia.

STFilter
Wejściowa wartość stosu: Stack0 - indeks tekstury
Wyjściowa wartość stosu: brak
Opis: Generowanie mipmap, czyli wariantów tekstur wyświetlanych na większych odległościach. Proces ten odbywa się po odblokowaniu tekstury, ale nie w czasie jej odblokowywania. Zapobiega migotaniu i artefaktom tekstur widzianych z pewnego dystansu.

STSetColor
Wejściowe wartości stosu: Stack4 - indeks tekstury, Stack3 - alfa, Stack2 - składowa czerwona, Stack1 - składowa zielona, Stack0 - składowa niebieska
Wyjściowa wartość stosu: brak
Opis: Ustawia kolor dla wykonywanych operacji.

STDrawPixel
Wejściowe wartości stosu: Stack2 - indeks tekstury, Stack1 - X, Stack0 - Y
Wyjściowa wartość stosu: brak
Opis: Zmienia kolor (koloruje wcześniej podaną barwą) konkretny piksel o współrzędnych X, Y .

STDrawRect
Wejściowe wartości stosu: Stack4 - indeks tekstury, Stack3 - X1, Stack2 - Y1, Stack1 - X2, Stack0 - Y2
Wyjściowa wartość stosu: brak
Opis: Rysuje wypełniony prostokąt między podanymi współrzędnymi X1-Y1, X2-Y2 .

STTextOut
Wejściowe wartości stosu: Stack5 - indeks tekstury, Stack4 - X1, Stack3 - Y1, Stack2 - indeks czcionki, Stack1 - pełny kolor (lub nie), Stack0 - tracking (automatyczne regulowanie odstępów między znakami), StringStack0 - wypisywany tekst
Wyjściowa wartość stosu: brak
Opis: Wypisuje tekst na teksturze. Indeks czcionki może być zwrócony przez GetFontIndex , wartość "pełny kolor" wskazuje na to, czy ustawiać kolor zadeklarowany poprzez makro STSetColor, czy pobierać go z właściwości czcionki.

GetFontIndex
Wejściowe wartości stosu: StringStack0 - nazwa czcionki
Wyjściowa wartość stosu: Stack0 - indeks czcionki
Opis: Zwraca indeks czcionki dla makra STTextOut

TextLength
Wejściowe wartości stosu: Stack0 - indeks czcionki, StringStack0 - wypisywany tekst
Wyjściowa wartość stosu: Stack0 - długość tekstu w pikselach
Opis: Oblicza i zwraca długość danego tekstu wypisywanego wskazaną czcionką.

STReadPixel
Wejściowe wartości stosu: StringStack2 - indeks tekstury, StringStack1 - X, StringStack0 - Y
Wyjściowa wartość stosu: brak
Opis: Ustawia kolor na taki, jaki posiada wskazany piksel (nie jestem pewny, czy Autorzy nie pomylili się przy wskazaniu stosów, moim zdaniem na wejściu będzie zwykły stos a nie stos łańcuchowy).

STCopyColor
Wejściowe wartości stosu: Stack1 - indeks pierwszej tekstury, StringStack0 - indeks drugiej tekstury
Wyjściowa wartość stosu: brak
Opis: Kolor drugiej tekstury jest ustawiany na kolor, który posiada pierwsza tekstura (również tutaj nie jestem pewny, czy na drugim wejściu podawany jest stos łańcuchowy).

STLoadTex
Wejściowe wartości stosu: Stack0 - indeks tekstury, StringStack0 - nazwa tekstury
Wyjściowa wartość stosu: brak
Opis: Rysuje teksturę o określonej nazwie.

STGetR / G / B / A
Wejściowe wartości stosu: Stack0 - indeks tekstury
Wyjściowa wartość stosu: wartość koloru (składowych koloru)
Opis: Zwraca wartość koloru (poszczególnych składowych) danej tekstury.

Wszystkie indeksy są liczone od zera, chyba, że napisane jest inaczej. Nie pytajcie mnie jak to dokładnie działa, bo sam nie do końca wiem. Niestety Autorzy gry nie opisali w sposób dokładny wszystkich mechanizmów. Daję pewną podstawę do tego, by samemu kombinować - wiecie już, które makro za co jest mniej więcej odpowiedzialne. Starałem się jak najlepiej przetłumaczyć informacje, jednakże zdaje sobie sprawę, że dla niektórych nadal będzie to czarna magia. Co do makr - polecam przejrzenie sobie ich od początku do końca, wtedy stanie się jasne, że większość z nich "zazębia" się. Aby działały jedne, muszę zadziałać wcześniej inne. Po takim przestudiowaniu powyższych opisów, zrozumienie stanie się łatwiejsze

Legenda:
StackX - odpowiada X-owej komórce stosu, przykładowo Stack0 odpowiada zerowej komórce stosu;
StringstackX odpowiada X-owej komórce stosu łańcuchowego, przykładowo Stringstack0 odpowiada zerowej komórce tego stosu.

Poradnik został napisany wyłącznie dla Forum http://strefa-omsi.pl i nie może być rozpowszechniany we fragmentach lub w całości na innych stronach bez zezwolenia głównego Autora.