Strefa OMSI

Plik options.cfg znajduje się w naszym głównym folderze z grą. W OMSI i OMSI 2, pliki o rozszerzeniu .cfg informują edytor lub grę o podstawowych ustawieniach i konfiguracji całej gry jaki również jej poszczególnych elementów.

Pliki .cfg również funkcjonują, według jednej zasady i jednego modelu - program jedynie odczyta i pobierze informacje z linijek które posiadają jedno lub więcej słów lub nazw kluczowych po swoim tytule, np.

Wpis zostanie odczytany :

Wpis nie zostanie odczytany :

Warto również zaznaczyć że jeśli gra nie będzia w stanie przeczytać podanego słowa kluczowego - najczęściej dlatego że jest ono niepoprawne - gra przestanie działać częściowo lub całkowice. Dzieje się to bowiem interpretator kodowy gry jest na tyle mało rozwinięty że nie przewiduje innych scenariuszy i nie zapewni gracza z opdowiednim, zrozumiałym komunikatem. Dlatego, warto się upewnić że wszystko jest zgodne z możliwymi wpisami używanymi w grze.

Rozpoczynając od pliku options.cfg - w którym są zapisywane wszelkie opcje związane z grą, niezależnie od tego czy zostały ustawione tekstowo czy poprzez interfejs graficzny gry - chciałbym Wam wytłumaczyć za co jest odpowiedzialna każda linijka i jakie są możliwe wpisy, które mogłyby się zgodnie tam pojawić, nie wywołując większych komplikacji i błedów.

Oto plik options.cfg :


Możecie zapewne zauważyć że mój plik został już w niektórych miejscach zedytowany. Chciałbym również Was zaopatrzyć w najczęstsze wpisy w różnych przypadkach :

- 0 lub 1 oznaczające nie (brak zgody) i tak (zgoda)
- on lub off oznaczające włączonce i nie włączone
- liczba lub ciąg liczb reprezentujące wartość w jednostkach tj. metry, sekundy, minuty
- link lub ścieżka do pliku/strony np. link do podkładów satelitarnych

A więc wiecie już teraz jakie wpisy można spotkać w plikach .cfg., a teraz poprzeglądajmy różne funkcje plików .cfg, poczynając od pliku options.cfg, o którym najpierw wspominaliśmy. Mogliście zauważyć że plik jest podzielony w wyraźne sekcje, oddzielone przez tytuł sekcji - wypisany drukowanymi literami - a następnie ciągem kilkunastu myślników. Plik jest dosyć czytelny iż każdy wpis jest oddzielony linijką a więc jest przejrzysty a zarazem dosyć zrozumiały, dzięki używaniu krótkich skrótów z angielskiego.

Wpis [last_map] podaje ścieżkę do pliku global.cfg mapy na której ostatnio graliśmy. Warto zaznaczyć że wpisy podające ścieżkę do pliku znajdującego się w folderach gry, rozpoczynają się po folderze w którym znajduje się modyfikowany plik .cfg.

Wpis [last_driver] również podaje ścieżkę do pliku w folderze gry, lecz tym razem do ostatniego kierowcy - plik o rozszerzeniu .odr.

Linijka [currWeather_ICAO] jest mniej przydatny, jeśli chodzi o zapewniania gracza informacjami nt. rozgrywki, jednakże może się przydać. Podaje on kod wewnętrzny pliku odpowiadającego za poprzednio załadowaną pogodę, która również łączy się z wpisem [last_map]

Dalej, inne istotne wpisy tj. [ticketselling który działa na zasadzie 0 lub 1 oznacza czy mamy włącząną funkcję sprzedawanie pasażerom bilety i wpis [radio], w którym zapewniamy grze link do radia, który będziemy chcieć używać podczas rozgrywki.

Wpis [font_typewriter] decyduje o czcionce używanej w edytorze i grze. Możliwe czcionki są następujące :

- Courier
- Courier New (domyślny)
- Arial
- Arial Black

Wybór nie jest zbyt wielki, lecz przeglądając oficjalne forum można natknać się na informacje od autorów o poszerzenie ilości możliwych czcionek, po narzekaniu osób z krajów ze specjalnymi znakami, np. nasze - polskie znaki też czasami wymagają innej czcionki.

Kto zna dobrze angielski, ten będzie wiedział że linijka [language] jest odpowiedzialna za zapewnienie grze informacje ws. tego jaki język będzie używany. Jest tutaj konieczność podawania skróconych form tych języków - kilka przykładów :
Niestety, nieoficjalne paczki językowe czasami nie zawierają takiego kodu bądź skróconej formy przez co czasami tworzą całą listę problemów, czy to na mapach, w grze czy ustawieniach.

Pomijając sekcję MULTITHREADING, przechodzimy do następnej sekcji, czyli GRAPHICS, w której mieszczą się wszelkie informacje i opcje związane z grafiką.


Pierwszy wpis, mianowicie [perfomance_realreflexions], jest opdowiedzialny za ustawienie drastyczności a przez to ogólnie realistyczności odskoków i odbić podczas jazdy i różnych sytuacji pogodwych bądź klimatycznych, mających miejsce w grze, podczas rozgrywki. Możemy tu wybrać z wpisu none, economy lub full. Takie wpisy będą również używane w innych wpisach, dalej w tym pliku jaki również innych plikach konfiguracyjnych.

Następnie, mamy do czynienia z wpisem [performance_reflTexSize], który łączy się z poprzednim [perfomance_realreflexions]. Jest to bowiem rozmiar tekstury (rozdzielczość) odbić, o którym wspomnieliśmy w [perfomance_realreflexions]. Podajemy tutaj wartość liczbami 1-10, jedynka będać najniższej jakości a dziesiątka najwyższej. Wartość nie ma zastosowania w grze, jeśli w [perfomance_realreflexions] zapiszemy plik z wpisem none.

Wpis [no_stencilbuffer] jest opdowiedzialny za włączanie lub wyłączanie funkcji buforu szablonu tekstur obiektów, spline`ów i innych elementów gry. Jest to dosyć rzadko używana opcja, jednak jest do dyspozycji graczy. Jego działanie jest dosyć niezrozumiałe, lecz podsumowując co inni piszą, chodzi tu o zmniejszanie zużycie zasobów przez krańce tekstur elementów ładowanych podczas rozgrywki. Jest ona jedynie przydatna przy obiektach większego formatu, np, most, pojazd, centrum handlowe itp. Używami tutaj wpisów zmiennych, liczbowych wprowadzając 0 (nie) lub 1 (tak).

[no_humans_on_rain_refl] jest wpisem odpowiedzialnym za wprowadzenie wartości, mówiącej czy funkcja odbicia ludzi ma być włączona czy wyłączona w grze. Ponownie, wprowadzamy wartości 0 lub 1.

Wpis [sunglow] jest opdowiedzialny za uruchomienie lub wyłączenie grafiki mającej wpływ na widok elementów gry w sposób taki że widać na nich odbicie słońca pod danym kątem. Tutaj, w odróżnieniu do dwóch poprzednich wpisów, używamy wartości off lub on (wyłączone / włączone).

[shadow_stencil to funkcja umożliwianie lub wyłączanie działania funkcji podkreślenia szablonu (zarysu) cieniu. Podobnie do innych wpisów, [shadow_stencil] dzieli brak zastosowania jeśli cienie są wyłączone. Tutaj regulujemy działanie za pomocą wpisów off i on.

Przed przejściem do kolejnego wpisu ([performance_tiledistmax]) pragnę zaznaczyć że niektóre wpisy są podzielone jeszcze w inne grupy poza sekcjami tj. GRAPHICS. Są tutaj jeszcze przedrostki w samych wpisach np. [performance_...] :


Wpisy w tej samej grupie często partycypują w stosunku do gry w podobne sposoby, w przypadku grupy [performance_... wpisy mające bardziej znaczący wpływ na wydajność i wagę działalności gry i poszczególnych jej elementów.

Następujący wpis to [performance_tiledistmax], w którym podajemy wartość w jednostkach kafli (czyli 300x300 m). Wartość tego wpisu decyduje o polu widzenia sąsiadujących kafli (tiles).

[performance_maxObjDist] jest odpowiedzialny za zapewnienie grze wartości związaną z polem widzeniem obiektów, tym razem podanych w metrach.

Wpis [performance_minObjSize] decyduje o minimalnej widoczności rozmiaru obiektu. Aby nikt mnie źle nie zrozumiał, nie chodzi tu o rzeczywisty rozmiar modelu obiekty lecz o to jak my - podczas rozgrywki - go widzimy i dostrzegamy. Wartość jest podana w metrach, i jest to wysokość obiektu.

Następnie mamy do czynienia z wpisem odpowiedzialnym za minimalną widoczność rozmiaru odbicia budynku podczas rozgrywki : [performance_minObjSizeRefl]. Poraz kolejny, nie chodzi tu o rzeczywisty rozmiar i wymiary lecz o widoczność.

Wpis [maxcomplexity decyduje o maksymalnej złożoności (zawiłości) możliwej w grze (obiekty, spline`y itp.). Możliwe wpisy to 0 - elementy najważniejsze a wpis 3 to najmniej ważne. Więcej informacji o złożoności w moim poradniku : http://strefa-omsi.pl/Watek-OMSI-1-2-Opt...ktow--9690 , punkt 2. Podobnie, wpis [maxcomplexity_map decyduje o maksymalnej złożoności samej mapy. Jest to bardzo rzadko używana opcja, i ja sam za bardzo jej w pełni nie rozumiem...

Pomijając dwa przedostatnie wpisy, pragnę poinformować zę wpis [maxFPS decyduje o maksymalnej ilości FPS-ów na mapie. Jak zapewne się już domyśleliście, wartości podajemy w FPS-ach (liczby).

Pozostając w sekcji GRAPHICS przenosimy się jednak dalej wgłąb pliku. Dochodzimy do wpisów [texFilter] i [texture] które mają związek jak same nazwy mówią z teksturami. O jakie tekstury tutaj chodzi ? Wszystkie tekstury - od tekstur budynków przez tekstury pojazdów po tekstury ziemii i wody. Pierwsza z nich - [texFilter] - jest opdowiedzialna za ustawienie wartości wewnętrznych filtrowania wartości i obrazów tekstur. Zalecane jest pozostawienie domyślnych wartości. Następnie [texture] jest wpisem odpowiedzialnym za włączanie lub wyłączanie tekstur. Tekstury każdy chyba chce mieć więc zostawiamy domyślne wartości :
W OMSI i OMSI 2, wyłączone lub brakujące tekstury są zastąpione białymi 'klocami'.

We wpise [texture] może być zastanawiające pojawienie się liczby 0 opdowiedzialnej za wyłączenie tekstur jaki również liczby 1 odpowiedzialnej za wartość umożliwiająca włączenie a teoretycznie pozostawienie tekstur. Obydwie te liczby są w tym wpisie obecne dlatego że umożliwiają one za włączenie funkcji (domyślnej funkcji przy więcej niż jednym wpisie - wartości wpisu) ale również pozostawienie funkcji uzupełnienia brakujących tekstur białymi 'klocami'. Jeśli funkcji 0 gra by zwariowała i bez tekstury poprostu by poprawnie nie funkcjonowała.

Po tym raczej długim opisie dwóch poprzednich wpisów, przesuwamy się do kolejnego wpisu, również związanego z teksturami, [textmemlimit]. Tutaj ustawiamy w MB maksymalne zużycie (limit) pamięci dla poprawnego działania i ładowania tekstur. Warto zaznaczyć że i tekstury i modele budynków i innych elementów są równie ważne. Dlatego, jeśli rozpoczynają się pojawiać białe tekstury mimo wgranych plików za nie opdowiedzialne, należy zwiększać wartość. Również, jeśli gra laguje można tą wartość zmniejszyć. Domyślna wartość jest następująca :
Wartości te najczęściej oscylują między 325.0 do ok. 520.0 a przy bardzo wymagających mapach, obiektach i dobrych komputerach nawet okolicach 600.0 MB.

Potem, mamy do czynienia z wpisem [smokesystems]. Tutaj są ustawiane opcje dot. efektu dymu, który możemy np. znaleźć na domyślnych domkach z Berlin-Spandau i Grundorf. Domyślnie te wartości będą wynosiły :
Tutaj również może zdziwić obecność dwóch wartości w jednym wpise. Już tłumaczę : pierwsza linijka mówi że jeśli funkcja jest włączona (1) natężenie dymu będzie wynosiło 1000, a to się stanie jedynie wtedy kiedy wartość po wartości decydującej (1) będzie wynosiła więcej niż 0. A więc, druga część wpisu (1, 0) mówi że nawet jeśli funkcja jest włączona ale jednak dymu na mapie nie ma, nic się nie będzie działo. Jest to zrozumiałe. Jednakże, regulowanie tych wartości jest znacznie łatwiejsze poprzez graficzny interfejs ustawień. Tam mamy do czynienia z wartościami podanymi w procentach i suwakiem do regulowania natężenie dymu.

Teraz przesuwając się do sekcji SOUND, rozpoczniemy od czegoś ważnego. Większość opcji dźwiękowych znajduje się w pliku sound.cfg, lecz w centralnym pliku ustawień też jest kilka kawałków informacji na ten temat.

Pierwszy wpis jaki ujrzycie to najprawdopodobniej [sound_maxcount]. Jedynie prawdopodobnie iż w zależności od niektórych wpisach w sound.cfg wpisy w głównym pliku options.cfg mogą się lekko różnić. Jednak, pozostając w temacie, wpis [sound_maxcount] informuje gre o tym jaka jest maksymalna ilość dźwięków jednocześnie grających podczas rozgrywki. Powyżej wartości 200, mogą się rozpocząć problemy z wydajnością odgłosów pojazdów i map. Dlatego też, zalecane jest pozostanie przy domyślnej wartości.

Następnie, napotkamy się na wpis [sound_vol_master] to początkująca wartość regulatora głośności. Dla tych którzy nie wiedzą, największa wartość to 1, a najniższa to 0.

Wpis [sound_stereo]/i] jest odpowiedzialny za wartość dźwięków stereofonicznych (bądź też po prostu stereo). Najczęstsze wartości oscylują między 15 a 20, zaś domyślna wartość to [i]17 tak jak widać to tutaj :

Następnie pomijając wpis bezużyteczny wpis [sound_doppler], przesuwamy się do dwóch ostatnich wpisów dźwiękowych : [sound_ai] i [sound_scenery]. Te dwa wpisy decydują o domyślnej głośności pojazdów AI ([sound_ai]) i scenerii czyli tzw. kostki dźwiękowe lub dźwięki pochodzące z innych obiektów w scenerii (na mapie) ([sound_scenery]). I w ten oto sposób zakończyliśmy naukę przy sekcji SOUND.

Czeka nas teraz dosyć krótka, przedostatnia sekcja AI. Rozpoczynamy od wpisu [AIMaxCountRandom]. Tutaj podajemy wartości liczebności pojazdów AI, w liczbach losowych. A więc teoretycznie nie podajemy, tylko te liczby są generowane w owej liście przez grę podczas ustawień map jaki również naszych ustawień w graficznym interfejsie gry - sekcja Options/Opcje.

Następnie, czekają nas wpisy [AIUnschedFactor] i [AIMaxCountParked. Wartości te są podawane w procentach czyli :
Pragnę również zaznaczyć że przy wartościach w pierwszym wpisie powyżej ok. 80 % rozgrywka staje się wręcz nie możliwa, przez nadmierną ilość samochodów. Samochodów a nie autobusów, iż ruch samochodów to ruch Unsched - Unscheduled (nieplanowany) a ruch autobusów jest oznaczony jako ruch planowany - Sched - Scheduled.

Wpis [AIPassFactor] to w luźnym przetłumaczeniu czynnik przejazdu. Czyli przy wartości o ekwiwalencie 100, ponieważ taka jest domyślna, pojazdy będą przejeżdżały. Całkowita geneza jest zbyt skomplikowana do ogólnego poradnika. Postaram się jednak o ten temat kiedyś poszerzyć mój poradnik.

Następnie, przechodzimy już do sekcji wpisów związanymi z ruchem planowanym (Sched - Scheduled), czyli autobusy jeżdzące zgodnie z rozkładem autobusów AI. Są to te pojazdy które zastąpiamy podczas rozgrywki, przy ustawieniu rozkładu jazdy. Pierwszy wpis w tej podsekcji, [AIMaxCountScheduled]. Domyślna wartość tutaj to 1000, lecz największa liczba pojazdów Scheduled AI, nie jest tak istotna, chyba że mapa miałaby z 30 linii Scheduled AI, co jest raczej rzadko spotykane z uwagi na optymalizację map spełniających dzisiejsze standardy.

Ostatni wpis w sekcji AI to [AIPriorityScheduled]. Podajemy tutaj wartość priorytetu pojawienia się tych linii AI, w sytuacji osiągania przez grę mniejszych FPS-ów niż planowany poziom skonfigurowany w opcjach OMSI/OMSI 2. Poraz kolejny odsyłam do mojego poradnik, dla osób mających problem ze zrozumieniem działania priorytetu w OMSI i OMSI 2 : http://strefa-omsi.pl/Watek-OMSI-1-2-Opt...ktow--9690 ,punkt 2.

I teraz ostatni wpis [Editor_LinkAerial] w sekcji Editor. Tutaj wpisujemy odnośnik do planowanego dostarczyciela podkładów satelitarnych. Więcej informacji o danych wysokości DEM i podkładach w poradniku NightHauler`a (http://strefa-omsi.pl/Watek-OMSI-2-Uzywa...orze--3515) i perfect`a (http://strefa-omsi.pl/Watek-OMSI-2-Tworz...EM--3487). Wprowadzamy do wpisu link do zdjęć satelitarnych. Tutaj wpisy do najczęściej używanych - Google i Bing :
Więcej informacji nt. uzyskania kodu API do utrzymania dostępu do podkładów satelitarnych Bing znajdziecie w punktach 1-1a poradnika NightHauler`a : http://strefa-omsi.pl/Watek-OMSI-2-Uzywa...rze--3515.

Poradnik nie miał jedynie na celu zaprezentowanie funkcji pliku options.cfg, lecz ważniej podstaw działania skryptów i plików z rozszerzeniem .cfg w OMSI i OMSI 2.

Pozdrawiam,
solarisjanek

Nie odbierz mnie źle ale przede wszystkim ze skryptami ma to niewiele wspólnego jednakże do czego chciał bym się przyczepić to po co roztrząsać plik options.cfg który edytuje się w ustawieniach gry?
Pod koniec napisałeś:

Cytat:Poradnik nie miał jedynie na celu zaprezentowanie funkcji pliku options.cfg, lecz ważniej podstaw działania skryptów i plików z rozszerzeniem .cfg w OMSI i OMSI 2.

Jednakże z doświadczenia ci powiem, że inne pliki cfg znacznie się różnią od tego co tutaj zaprezentowałeś.