Autor poradnika: Zyxist

Podstawy pracy z plikami konfiguracyjnymi dodatków

W poprzedniej części artykułu zapoznaliśmy się z wybranymi informacjami dotyczącymi grafiki 3D i jej wykorzystania przez Trainz, a także nauczyliśmy się prawidłowo eksportować modele 3D z Blendera i tekstury z Substance Paintera tak, aby Trainz umiał je przeczytać. Poznaliśmy takie pojęcia, jak model, tekstura, materiał czy PBR. Teraz przychodzi czas na nauczenie się podstaw pracy z plikami konfiguracyjnymi, dzięki którym Trainz w naszym zbiorze plików graficznych zobaczy działający dodatek 🙂. Zatem do dzieła!

Uwaga: jeśli nie czytałeś części pierwszej, zapoznaj się z nią przed lekturą tej.

Potrzebne rzeczy

W poprzedniej części pracowaliśmy sporo z narzędziami do grafiki 3D, natomiast dzisiaj do pracy wystarczy nam zwykły menedżer plików i Notatnik :). W artykule będę posługiwał się następującymi zwrotami:

musi – należy tego przestrzegać, inaczej jest spora szansa, że coś się popsuje
powinien/warto – dobra praktyka, której warto przestrzegać z różnych względów, ale nikt tego na nas nie wymusi
może – nic się nie stanie, jeśli tak nie zrobimy

Do każdego atrybutu i elementu załączam także odnośniki do oficjalnej, angielskiej dokumentacji.

Plik config.txt

Plik config.txt jest “sercem” dodatku. Musi znajdować się zawsze w głównym katalogu i znajdziemy w nim niemal całą konfigurację, która mówi Trainzowi, co to jest za dodatek, co on robi i jak działa. Przechowuje on też informacje o autorze, wszelkie opisy wyświetlane np. w DLS-ie, a także wyświetlane nazwy, teksty i ich tłumaczenia.

Struktura pliku config.txt jest bardzo prosta. Zawiera on zwykłą listę par klucz – wartość w autorskim formacie i do pracy z nim nie jest potrzebna żadna znajomość programowania. Nie ma tutaj żadnych innych zaawansowanych struktur takich, jak pętle, zmienne czy funkcje. Do edycji wystarczy nam zwykły windowsowy Notatnik.

Przykłady:

opcja-1-typu-tekstowego                    "wartość tekstowa"

opcja-2-typu-liczbowego                     723

opcja-3-typu-zmiennoprzecinkowego           7.56

Dodatkowo część opcji jest zgrupowana w tzw. pojemnikach, które mają swoje nazwy i które można zagnieżdżać jeden w drugim. Po nazwie pojemnika musi znaleźć się para nawiasów klamrowych. Nawias otwierający możemy umieścić w tej samej linijce lub w linijce niżej:

pojemnik-1 {
opcja-w-pojemniku 123
zagniezdzony-pojemnik {
opcja-w-zagniezdzonym-pojemniku 123
    }
}

Tworząc plik konfiguracyjny, musimy zwracać uwagę na typy wartości oczekiwane przez atrybuty. Tekst zapisujemy w cudzysłowach, liczby całkowite – bezpośrednio, a w liczbach ułamkowych jako separatora ułamków używamy kropki. Niektóre atrybuty mają swój specyficzny oczekiwany format wartości (jednym z nich jest np. atrybut kuid), który jest wtedy opisany w dokumentacji.

Kodowanie pliku musi być ustawione na UTF-8, dzięki któremu mamy możliwość wpisywania znaków diakrytycznych dla języków innych niż angielski, a w szczególności – dla języka polskiego.

Pewnym minusem stosowania autorskiego formatu jest brak dodatkowego wsparcia w edytorach tekstu (kolorowanie składni, zwijanie nawiasów). Musimy jednak pamiętać, że kiedy powstawały pierwsze wersje Trainza, formaty takie, jak JSON czy YAML albo jeszcze nie istniały, albo znajdowały się w powijakach i tworzenie autorskich formatów plików konfiguracyjnych było wtedy powszechną praktyką.

Źródło: https://online.ts2009.com/mediaWiki/index.php/Config.txt

Przykładowy plik config.txt

Poniżej przedstawiam przykładowy plik config.txt do najprostszego dodatku typu “Obiekt scenerii”. Za chwilę omówimy sobie poszczególne opcje.

kind                                      "scenery"
kuid                                      <kuid2:160530:10000:1>
username                                  "My first asset"
username-pl                               "Mój pierwszy dodatek"
username-cz                               "Můj první přírůstek"
trainz-build                              "4.6"
category-class                            "BH"
category-region                           "PL"
category-era                              "2000s"

mesh-table {
  lod_0 {
    mesh                                  "building-lod0.trainzmesh"
    auto-create                           1
    lod-level                             0
    does-cast-shadows                     1
  }
  lod_1 {
    mesh                                  "building-lod1.trainzmesh"
    auto-create                           1
    lod-level                             1
    does-cast-shadows                     0
  }
}

mesh-table-lod-transition-distances       300,2000
enable-pfx-collisions                     0
description                               "My first Trainz asset, a simple scenery building"
description-pl                            "Mój pierwszy dodatek Trainz, prosty budynek scenerii"
contact-website                           "https://www.example.com/"
license                                   "Some license text here"

thumbnails {
  0 {
    image                               "thumbnail.jpg"
    width                               240
    height                              180
  }
}

Widzimy tutaj szereg atrybutów oraz kilka pojemników. Wartości atrybutów odseparowane są od nazw dużą ilością spacji – nie jest to wymóg, lecz użyteczna konwencja poprawiająca czytelność plików. Pora zatem dowiedzieć się, co poszczególne atrybuty robią!

KIND

Istnieje wiele rodzajów dodatków do Trainza: obiekty scenerii, spline’y, obiekty przytorowe, tory, itd. Ten atrybut mówi Trainzowi, co to jest za dodatek i jak należy go “obsługiwać”. Jeżeli tworzymy typowy obiekt scenerii bez żadnych interaktywnych elementów (np. jakiś budynek do umieszczenia na mapie), musimy ustawić tutaj wartość “scenery”. Poniżej podaję kilka przykładów innych dozwolonych wartości, których jest oczywiście dużo więcej niż to, co wymieniam:

fixedtrack – obiekt scenerii z torem lub krzywą spline, do których możemy doczepić inne tory lub spline’y
track – tory kolejowe, drogi i wszelkie inne krzywe spline
mojunction – interaktywny rozjazd
groundtexture – tekstura terenu

Wiele atrybutów używanych w plikach config.txt jest specyficznych dla określonego rodzaju dodatku. W tym artykule przedstawiam głównie uniwersalne atrybuty albo atrybuty, które wykorzystywane są w większości rodzajów dodatków.

KUID

Tutaj podajemy tzw. numer KUID, który jest unikalnym identyfikatorem dodatku używanym przez grę. Po tym identyfikatorze możemy znaleźć każdy dodatek, wewnętrznie gra także używa KUID-ów do definiowania zależności między dodatkami. KUID zapisujemy zawsze w “daszkach”, a składa się on z obowiązkowego przedrostka i trzech liczb:

<kuid2:id_autora:id_dodatku:wersja>

Objaśnienie:

id_autora – każdy nabywca Trainza przy zakładaniu konta na Planet Auran dostaje swój unikalny numer identyfikacyjny. Aby go znaleźć, na ekranie startowym klikamy “Ustawienia Trainz” i przechodzimy do ostatniej zakładki “Dev”.
id_dodatku – unikalny (w obrębie danego autora) numer dodatku, który możemy sobie sami wybrać.
wersja – numer wersji dodatku. Przykładowe zastosowania:
- znaleźliśmy błąd w dodatku i chcemy wypuścić nową wersję z poprawką,
- poprawiamy działanie w nowszych wersjach gry,
- wprowadzamy jakieś usprawnienia i optymalizacje do istniejącego dodatku, które chcemy wydać.

We wszystkich dodatkach naszego autorstwa będziemy zawsze mieć ten sam id_autora, który został nam nadany przy zakładaniu konta. Jeśli chodzi o id_dodatku, to gra wymaga tylko, aby w obrębie konkretnego autora ten numer był unikalny. Innymi słowy, nie powinniśmy wypuszczać dwóch różnych dodatków z tym samym numerem. A to, jak ten numer sobie wybierzemy, zależy już od nas. Niektórzy po prostu nadają te numery w kolejności powstawania dodatków, inni (np. ja) stworzyli sobie system numeracji. Przykładowo, do niewidzialnych stacji używam numerów z przedziału 32000-32999, a do domów: 9000-9100.

Jeśli chodzi o wersję gry, to zdecydowanie warto tym dobrze zarządzać i przy każdej zmianie zwiększać ten numer o 1:

można mieć zainstalowany ten sam dodatek w kilku wersjach, Trainz będzie używać najnowszej obsługiwanej przez dane wydanie gry,
w przypadku dodatków umieszczonych na DLS-ie Trainz może wykryć, że dostępna jest nowsza wersja dodatku i zaproponować aktualizację.

Część dodatków używa starszego formatu numerów KUID, który jest pozbawiony wersji i wygląda następująco: <kuid:id_autora:id_dodatku>.

Źródło: https://online.ts2009.com/mediaWiki/index.php/KUID

USERNAME

Nazwa tej opcji jest dość niefortunna, nie oznacza ona autora dodatku, tylko… nazwę dodatku wyświetlaną w grze oraz w DLS-ie. Nazwa ta powinna być w języku angielskim. Możemy też podać nazwy dodatku w innych językach, podając dodatkowe atrybuty username z dodanym dwuliterowym kodem języka, np.

username-pl „Nazwa w języku polskim”

Zasada wyboru wyświetlanej nazwy jest prosta. Jeżeli mamy uruchomionego Trainza w polskiej wersji i dodatek ma zdefiniowaną polską nazwę, wyświetli nam się polska nazwa. Jeżeli dla danej wersji językowej dodatek nie ma zdefiniowanej nazwy, używana jest nazwa domyślna z atrybutu username.

Źródło: https://online.ts2009.com/mediaWiki/index.php/%22Username%22_tag

TRAINZ-BUILD

Jest to numer, który w dużym uproszczeniu reprezentuje minimalną wersję gry, na której nasz dodatek można zainstalować i jednocześnie – jakie funkcjonalności silnika gry możemy wykorzystać. Lista numerów trainz-build oraz odpowiadających im wydań gry znajduje się w dokumentacji: https://online.ts2009.com/mediaWiki/index.php/%22trainz-build%22_number

Przykłady:

Jeśli chcemy mieć kompatybilność z Trainz: A New Era SP2/SP3 lub nowszymi, powinniśmy ustawić trainz-build na „4.5”
Jeśli chcemy korzystać z materiałów PBR, musimy ustawić trainz-build na wartość przynajmniej „4.6” reprezentującą Trainz Railroad Simulator 2019.

Na grudzień 2023 najwyższym numerem trainz-build jest „5.3” reprezentujący TRS22 SP2. Jeśli jednak chcemy stworzyć prosty obiekt scenerii wykorzystujący materiały PBR, wystarczy ustawić trainz-build na 4.6, ponieważ późniejsze wydania gry nie wprowadzały akurat żadnych istotnych zmian w działaniu dodatków scenerii i nie ma racjonalnego powodu, by ograniczać dostępność dodatków. Istnieją jednak typy dodatków, do których będziesz musiał użyć wyższego numerka, chcąc wykorzystać najnowsze możliwości silnika gry (np. trasy wykorzystujące teren HD muszą korzystać właśnie z numeru 5.3).

CATEGORY-CLASS, CATEGORY-REGION, CATEGORY-ERA

Te trzy atrybuty służą do wyszukiwania dodatków w Menedżerze Zawartości lub na DLS-ie po określonych cechach. Prawidłowe oznakowanie naszych dodatków pomaga później twórcom tras w znalezieniu dodatków, które pasują do rodzaju tworzonej trasy. Przykładowo, tworząc polską trasę w klimatach z lat 90-tych, chcielibyśmy znaleźć dodatki pasujące wizualnie do tego regionu i okresu. Oto, co i jak powinniśmy tu wpisać:

category-class : kilkuliterowy kod opisujący rodzaj obiektu przedstawionego w dodatku. Użyty w przykładzie „BH” oznacza budynki mieszkalne, nieinteraktywne obiekty scenerii. Pełen wykaz kodów znajdziemy tutaj: https://online.ts2009.com/mediaWiki/index.php/Category-class
category-region: kod regionu lub lista kodów regionów, do których najlepiej nasz dodatek pasuje. Jeśli podajemy kilka regionów, musimy oddzielić je średnikiem, np. „PL;DE;CZ;SK”
category-era: okres historyczny lub lista okresów oddzielonych średnikiem, do których najlepiej pasuje nasz dodatek, np. „1990s;2000s;2010s”

Źródło: https://online.ts2009.com/mediaWiki/index.php/KIND_TrainzBaseSpec#category-era

MESH-TABLE

Jest to pojemnik, w którym opisujemy wszystkie modele 3D, które wykorzystywane są w dodatku. Jak widzimy na przykładzie, każdy model to osobny zagnieżdżony pojemnik umieszczony wewnątrz mesh-table, któremu nadajemy jakąś nazwę. Nazwa ta jest absolutnie dowolna, ale musi być unikalna w obrębie konkretnego dodatku i powinna mieć dla nas sens. W przyszłości zobaczymy, że niektóre atrybuty w pliku config.txt będą odwoływać się do dostępnych modeli właśnie po ich nazwie, dlatego zdecydowanie warto nadawać te nazwy z sensem.

W zaprezentowanym przykładzie mówię Trainzowi, że dodatek będzie wykorzystywać dwa modele, które – dla odróżnienia – nazwałem sobie building_lod0 i building_lod1 od poziomu LOD (Level-of-Detail), który reprezentują.

Źródło: https://online.ts2009.com/mediaWiki/index.php/%22mesh-table%22_container

MESH-TABLE / MESH

Ścieżka do pliku z modelem 3D w obrębie naszego dodatku.

UWAGA: jeżeli wyeksportowaliśmy nasz dodatek w formacie FBX, to nie wolno podawać tu rozszerzenia .fbx, lecz .trainzmesh! Wynika to z tego, że podczas instalowania dodatku gra konwertuje sobie FBX na wewnętrzny format TrainzMesh. Po tej konwersji plik FBX nie jest nam więcej do niczego potrzebny. Możemy potem wyedytować dodatek i usunąć z niego plik FBX.

Źródło: https://online.ts2009.com/mediaWiki/index.php/%22mesh-table%22_container#mesh

MESH-TABLE / AUTO-CREATE

Ta opcja określa czy model ma zostać natychmiast załadowany, gdy użyjemy go na mapie. Domyślną wartością jest 0, czyli że nie chcemy go ładować i że obiekt ma być domyślnie niewidoczny, dlatego w 99% przypadków będziemy chcieli tu ustawić wartość 1.

Wartość przydaje się głównie w dodatkach oskryptowanych, gdzie np. pojawienie się modelu jest kontrolowane przez skrypt. Wykracza to jednak poza ramy tego artykułu.

Źródło: https://online.ts2009.com/mediaWiki/index.php/%22mesh-table%22_container#auto-create

MESH-TABLE / LOD-LEVEL

Trainz wspiera technikę Level-Of-Detail (LOD). W technice tej posiadamy kilka modeli 3D tego samego obiektu różniących się szczegółowością. Gra wybiera odpowiedni z nich na podstawie odległości obiektu od kamery. Odległe obiekty nie muszą być zbyt szczegółowe, powinny mieć zatem dużo mniej trójkątów i mniej obciążać grę.

Przy pomocy tego atrybutu mówimy Trainzowi, który poziom LOD reprezentuje dany model. 0 to model najbardziej szczegółowy, najbliżej kamery, a kolejne liczby to coraz mniej szczegółowe modele. Ile ich stworzymy – to zależy od nas. To, w jakiej odległości dany poziom będzie użyty, kontrolujemy innym atrybutem (o tym dalej).

Maksymalna liczba poziomów LOD wynosi 9, numerowanych od 0 do 8, w praktyce stosuje się ich mniej. Wartość 255 oznacza, że model powinien być używany dla wszystkich poziomów LOD.

UWAGA: gra bezwzględnie wymaga, aby każdy kolejny poziom LOD miał o przynajmniej 20% mniej trójkątów od poprzedniego. Dodatkowo ostatni poziom LOD musi mieć bezwzględnie mniej niż 500 trójkątów. Jeśli nie spełnimy tych wymagań, dostaniemy błąd podczas instalacji.

Źródło: https://online.ts2009.com/mediaWiki/index.php/%22mesh-table%22_container#lod-level

MESH-TABLE / DOES-CAST-SHADOWS

Atrybut wspierany od trainz-build „4.4” (TMR2017, T:ANE SP2/3)

Czy obiekt ma rzucać cień (0 – nie, 1 – tak). Ja wyłączam tę opcję dla dalszych poziomów LOD, gdzie i tak cienia nie byłoby specjalnie widać, nie ma zatem sensu obciążać gry jego generowaniem.

Źródło: https://online.ts2009.com/mediaWiki/index.php/%22mesh-table%22_container#does-cast-shadows

MESH-TABLE-LOD-TRANSITION-DISTANCES

Atrybut wspierany od trainz-build „4.6” (TRS2019).

Tutaj określamy, przy jakich odległościach od kamery używać których poziomów LOD. Musimy tutaj podać kilka liczb oddzielonych przecinkiem. Każda liczba to odległość wyrażona w metrach. Podajemy tu tyle wartości, ile mamy poziomów LOD w naszym dodatku. Ostatnia liczba to odległość, powyżej której przestajemy całkowicie wyświetlać obiekt. W naszym przykładzie podałem „300,2000”, co oznacza:

do odległości 300 m od kamery wyświetlaj model z lod-level = 0
w odległościach od 300 do 2000 m wyświetlaj model z lod-level = 1
powyżej 2000 m nie wyświetlaj obiektu.

Źródło: https://online.ts2009.com/mediaWiki/index.php/KIND_Mesh#mesh-table-lod-transition-distances

ENABLE-PFX-COLLISIONS

Atrybut ten przyjmuje wartości: 0 – nie, 1 – tak (domyślnie). Określa on czy obiekt ma być uwzględniany przy symulacji efektów cząsteczkowych takich, jak dym czy para wodna. Ja podchodzę do tego zdroworozsądkowo: Trainz to gra o pociągach, dymu nie ma tu dużo, dlatego domyślnie to wyłączam. Rozważyłbym włączenie tej opcji tam, gdzie rzeczywiście istnieje szansa, że obiekt wejdzie w interakcję z dymem, np. wiadukt nad torami + jadący parowóz, infrastruktura peronowa, ew. dworce.

Źródło: https://online.ts2009.com/mediaWiki/index.php/KIND_Mesh#enable-pfx-collisions

DESCRIPTION

Bardziej rozbudowany opis dodatku, wyświetlany np. w szczegółach dodatku na DLS-ie. Gra może wyszukiwać dodatki po frazach wpisanych w opisie, dlatego warto coś tutaj jednak umieszczać. Analogicznie jak w przypadku atrybutu username, tu też możemy podać opis w kilku wersjach językowych, dodając kolejne atrybuty description z doklejonym kodem języka.

Źródło: https://online.ts2009.com/mediaWiki/index.php/%22Description%22_tag

CONTACT-WEBSITE, CONTACT-EMAIL

Możemy tutaj opcjonalnie podać dane kontaktowe do nas w postaci adresu naszej strony internetowej oraz e-maila (w cudzysłowach).

AUTHOR, ORGANISATION

Te dwa atrybuty występują często w plikach konfiguracyjnych wielu dodatków, jednak w przykładzie nie podałem ich celowo. Dokumentacja mówi, że ich użycie nie jest rekomendowane, ponieważ gra jako nazwę użytkownika i tak będzie wyświetlać nasz login na Planet Auran (i po tym loginie będzie można nasze dodatki znaleźć). Nic się jednak nie stanie, jeśli je wpiszemy.

Źródło: https://online.ts2009.com/mediaWiki/index.php/KIND_TrainzBaseSpec#contact-email

LICENSE

Tutaj możemy wpisać warunki licencyjne korzystania z naszego dodatku. Atrybut ten nie wspiera wersji językowych, gra też w żaden sposób nie weryfikuje tego, co tu wpiszemy. Pole to ma zastosowanie głównie w przypadku dystrybucji dodatków poza Trainz Download Station, ponieważ dodatki znajdujące się na DLS-ie co do zasady objęte są wspólną licencją stworzoną przez twórców gry. Ja używam tego pola do dwóch rzeczy:

dystrybucja/używanie dodatku poza DLS-em
dodatkowe kwestie nieobjęte licencją (np. informacja o braku gwarancji lub o użyciu licencjonowanych tekstur, jeśli dotyczy)

Licencjonowanie i użycie DLS-a to temat na szerszy artykuł, dlatego nie będę go tutaj dalej rozwijał.

Źródło: https://online.ts2009.com/mediaWiki/index.php/KIND_TrainzBaseSpec#license

THUMBNAILS

Ten pojemnik zawiera konfigurację obrazków-miniaturek przedstawiających nasz dodatek. Wszystkie nowe dodatki muszą mieć co do zasady minimum jedną domyślną miniaturkę w postaci pliku JPG o wymiarach 240 x 180 pikseli. Nazwę pliku podajemy w atrybucie image, a plik oczywiście musi istnieć, inaczej dostaniemy błąd podczas próby instalacji.

Ja na czas tworzenia dodatku umieszczam tutaj tymczasowy pusty obrazek, natomiast tuż przed wydaniem robię po prostu zrzut ekranu ukazujący dodatek w grze i skaluję go do wymaganej rozdzielczości.

Źródło:

Pliki konfiguracyjne tekstur

Kolejną ważną częścią dodatku są pliki konfiguracyjne do materiałów i tekstur. Jak pamiętamy z poprzedniej części, do materiałów PBR potrzebujemy trzech obrazków: albedo (kolor), mapa parametrów i mapa normalnych. Podpinamy je następnie w Blenderze do shadera. To jednak nie wszystko, bowiem do każdego pliku tekstury musimy dorzucić obok dodatkowy plik tekstowy z rozszerzeniem .texture.txt. Przykładowo, jeśli mamy plik mojatekstura.png, to tworzymy mojatekstura.texture.txt.

Ja tekstury PBR nazywam wg konwencji material-albedo.png, material-parameters.png i material-normal.png. Tworzę dla nich po jednym pliku tekstowym:

material-albedo.texture.txt:

Primary=material-parameters.png
Tile=none

material-parameters.texture.txt:

Primary=material-parameters.png
Tile=none
Alpha=material-parameters.png

material-normal.texture.txt:

Primary=material-normal.png
Tile=none

Opis atrybutów:

Primary – nazwa głównego pliku z obrazkiem
Tile – sposób powielania tekstury (kafelkowania) używany, jeśli koordynaty na mapie UV w modelu wychodzą poza zakres wartości od 0.0 do 1.0. W moich modelach nie wychodzę poza ten zakres, dlatego ustawiam tu none. Po inne wartości najlepiej zerknąć do dokumentacji: https://online.ts2009.com/mediaWiki/index.php/Texture_file
Alpha – jeśli w danej teksturze używamy kanału alfa, to tu musimy podać ścieżkę do pliku zawierającego ten kanał (najczęściej będzie to ten sam plik, co w Primary).
NormalMapHint – używamy do tekstury reprezentującej mapę normalnych z wartością normalmap, aby wyłączyć pewne transformacje robione przez grę przy innych typach tekstur.

Przy pomocy plików konfiguracyjnych tekstur można też robić kilka innych interesujących rzeczy, np. włączyć dwustronne krawędzie czy technikę alpha maskingu (bardziej wydajna od alpha blendingu i zalecana w większości przypadków), ale to jest temat na inny artykuł.

Warto zauważyć, że w większości przypadków zawartość tych plików konfiguracyjnych nie zmienia się. Ja dla swojej własnej wygody w modelach używam zawsze tej samej nazwy materiału, np. wszystkie budynki mają materiał building.m.pbrmetal i tekstury building-albedo.png, building-parameters.png i building-normal.png. Dzięki temu pliki konfiguracyjne tekstur w większości po prostu kopiuję sobie bez żadnych modyfikacji między projektami.

Wgrywanie dodatku do Trainza

W tym momencie powinieneś mieć w katalogu dodatek przygotowany do eksportu do gry, na który składają się następujące pliki:

config.txt
building-lod0.fbx
building-lod1.fbx
building-albedo.png
building-albedo.texture.txt
building-parameters.png
building-parameters.texture.txt
building-normal.png
building-normal.texture.txt
thumbnail.jpg

Aby zainstalować dodatek w grze, otwórz Menedżer Zawartości i po prostu przeciągnij do niego katalog z dodatkiem. Gra rozpocznie proces walidacji dodatku, po czym go zaimportuje (o ile nie będzie błędów).

Niektóre błędy wyłapywane są dopiero, gdy gra próbuje wyświetlić dodatek, dlatego po instalacji powinieneś natychmiast kliknąć w Menedżerze Zawartości prawym przyciskiem na Twoim dodatku, a następnie z menu rozwijanego wybrać “Otwórz” > “Podgląd dodatku”. Jeśli wyświetli się podgląd, wszystko jest OK. Jeśli nie, na moment wyświetli się czarny ekran, po czym powrócisz do pulpitu. Wtedy szczegółowe informacje o błędzie pojawią się po wybraniu z tego samego menu rozwijanego opcji “Pokaż błędy i ostrzeżenia”.

Najczęstsze problemy przy imporcie:

błędne nazwy plików
odwoływanie się w modelu do nieistniejących materiałów (bardzo częste w Blenderze, gdzie przy kopiowaniu obiektu Blender kopiuje też materiał i dokleja do nazwy jakiś ciąg typu “.001”, który rozwala Trainza).
brakujące/niewłaściwie skonfigurowane atrybuty w pliku config.txt,
błędy poziomów LOD, np. ostatni poziom ma więcej niż 500 trójkątów, między dwoma poziomami jest mniej niż 20% różnicy w liczbie trójkątów.

Jeśli z dodatkiem wszystko jest w porządku, możemy skasować z niego plik FBX. W tym celu otwieramy dodatek do edycji, wybieramy opcję “Pokaż w Eksploratorze”, kasujemy plik FBX, pozostawiając plik z rozszerzeniem .trainzmesh, a następnie zatwierdzamy zmiany w Menedżerze Zawartości.

Kilka porad i ważnych zasad na start

Format plików config.txt ewoluuje razem z grą i zmianami w jej silniku. O ile znaczenie już wprowadzonych atrybutów raczej się nie zmienia, to kolejne wydania gry wprowadzają nowe atrybuty oraz… nowe walidatory, które sprawdzają poprawność pliku. Na początku istnienia Trainza twórcy popełnili – w mojej ocenie jako zawodowego programisty – kardynalny błąd, pozwalając wpisywać do pliku config.txt totalne bzdury, które i tak gra “jakoś” łykała. Nie tylko utrudniało to im później rozwijanie gry, ale też przyzwyczaiło do tego twórców dodatków, którzy mogli mylnie uznać, że ich pliki konfiguracyjne są poprawne, skoro “jakoś działają” (pomijam już praktykę bezmyślnego kopiowania od innych całych partii konfiguracji bez próby zrozumienia, co tam się dzieje). W późniejszych wersjach gry zaczęto naprawiać ten błąd i dodawać walidatory, które nie pozwalają na instalację dodatków z błędami w pliku config.txt. Niestety mleko się już rozlało i nawet dzisiaj można znaleźć w Internecie wiele dodatków, których bez ręcznych poprawek nie da się zainstalować, a których autorzy już dawno zniknęli.

Dodam, że pliki konfiguracyjne to nie jest jedyne miejsce, które ma wpływ na kompatybilność z różnymi wersjami Trainza. Gra daje możliwość umieszczania w dodatkach skryptów. Działanie skryptów zależy mocno od działania wnętrza gry, które często jest nieudokumentowane i potrafi zmieniać się nawet pomiędzy patchami do tej samej wersji Trainza do tego stopnia, że dotychczasowe dodatki nie są w stanie działać bez przeróbek skryptów. Dodatki ze skryptami są nie tylko trudniejsze w stworzeniu (konieczna jest znajomość programowania), ale – z powodu wspomnianych zmian – dużo trudniejsze w utrzymaniu. Jednak temat ten wykracza poza ramy tego artykułu i nie będę go tu dalej rozwijać.

Jeśli chcesz zminimalizować ryzyko problemów w przyszłości, już na starcie przyswój sobie mocno następujące zasady zdrowej pracy z plikami config.txt (i jakimikolwiek plikami konfiguracyjnymi w jakimkolwiek programie):

Zasada 1: nie wpisuj losowych głupot do plików konfiguracyjnych

Zasada 2: nie kopiuj od innych bezmyślnie opcji, których przeznaczenia nie znasz

Zasada 3: nie wpisuj błędnych/niedozwolonych wartości do opcji

Parafrazując: zanim użyjesz jakiejś opcji, sprawdź w dokumentacji, co ona robi i jak należy ją ustawić. Oszczędzisz sobie i innym problemów i nerwów.

Porada: jeśli chcesz się wzorować na konfiguracji innych, wzoruj się na dodatkach pod nowsze wersje gry.

Powyższe rady nie eliminują ryzyka. Walidatory pozwalają wychwycić większość błędów, ale niestety nie wszystkie. Sam niedawno dostałem zgłoszenie o błędzie w moim zestawie niewidzialnych stacji pasażerskich PNS, gdzie jedna rzecz nie działała tylko dlatego, że w jednej opcji przez przypadek wstawiłem liczbę 0 w cudzysłowach i gra mi tego nie wychwyciła. Błędy się zdarzają, trudno, trzeba umieć z tym żyć – znaleźliśmy przyczynę, zrobiłem poprawkę, wgrałem na DLS i jedziemy dalej.

Zakończenie

To by było na tyle. Udało nam się stworzyć prosty obiekt scenerii i wgrać go do Trainza, jednak to dopiero początek drogi. W kolejnej, trzeciej części, wzbogacimy nasz obiekt o wersję zimową oraz tryb nocny.

Tutoriale

Tworzenie dodatków do Trainz cz. 2