Az objektum rejtelmei

Az objektum rejtelmei avagy

tippek, trükkök kezdőknek és haladóknak

Ver 2.00

Összeállította: Iván Zoltán (Zsivány)

Tartalomjegyzék 1.

Az objektum .................................................................................................................................... 4

1.1.

A textúra fájl (.ACE) .................................................................................................................. 4

1.2.

A shape fájl (.S) .......................................................................................................................... 5

1.3.

A shape data fájl (.SD) ............................................................................................................... 7

1.4.

Összegzés ................................................................................................................................... 8

1.5.

Javaslat ...................................................................................................................................... 8

1.6.

Képek ......................................................................................................................................... 9

2.

A pálya objektumai ....................................................................................................................... 18

2.1.

Statikus objektumok ................................................................................................................. 18

2.2.

Speciális pályaobjektumok ...................................................................................................... 18

2.3.

Sín- és útobjektumok ................................................................................................................ 20

2.4.

A pályaobjektumok pályába integrálása (.REF) ...................................................................... 21

3.

A pályaobjektumok beállításai ..................................................................................................... 22

3.1.

Speciális pályaobjektumok ....................................................................................................... 22

3.2.

Sín- és útelemek beállításai ...................................................................................................... 24

4.

Sínen mozgó objektumok ............................................................................................................. 25

5.

A járművek beállításai .................................................................................................................. 25

5.1.

A vontatott jármű (.WAG) ........................................................................................................ 25

5.2.

A vontató jármű – a mozdony (.ENG) ...................................................................................... 32

5.3.

A járművek kiegészítő beállításai – a kabinnézet (.CVF) ............................................... tervezett

6.

A hangosítás rejtelmei (.SMS) ....................................................................................... tervezett

6.1.

Pálya menti hangforrások .............................................................................................. tervezett

6.2.

Menethangok ................................................................................................................ tervezett

6.3.

Járművek hangbeállításai .............................................................................................. tervezett

7.

A pálya működtetése – Activity-k .................................................................................................. 34

7.1.

Az Activity felépítése ................................................................................................................. 34

7.2.

Alapbeállítások ......................................................................................................................... 35

7.3.

A tevékenység létrehozása – a Service (.SRV) .......................................................................... 35

7.4.

A Consist (.CON) ...................................................................................................................... 36

7.5.

A nyomvonal – a Path (.PAT) ................................................................................................... 38

7.6.

A játékos tevékenysége.............................................................................................................. 43

7.7.

Egyéb műveletek ....................................................................................................................... 44

7.8.

Hogyan ér véget az activity - hatások ....................................................................................... 45

7.9.

Activity-k speciális beállításai – időjárás és veszélyek ............................................................. 48

7.10.

Az Activity-k kézi módosítása – az .ACT fájl............................................................................. 48

7.11.

Mesterséges intelligenciájú forgalom – az AI-vonatok............................................................. 49

7.12.

Javaslat..................................................................................................................................... 50

2

8.

Jelzők programozása .................................................................................................................... 51

8.1.

A jelzők beállítása – a SIGCFG.DAT fájl ................................................................................. 51

8.2.

Jelzőprogramozás – SIGSCR.DAT ........................................................................................... 56

8.3.

Néhány példa ............................................................................................................................ 57

8.4.

Összegzés .................................................................................................................................. 61

Felhasznált irodalom .................................................................................................................................. 62 Ajánlott irodalom ........................................................................................................................................ 62 (A változtatás jogát fenntartom.) Megjegyzés: A sötétkék szöveggel azokat a részeket jelöltem, melyek a V1.0-ban még másképp szerepeltek, de visszajelzések alapján megváltoztattam őket.

3

1. Az objektum (avagy a shape fájl és tartozékai) 1.1. A textúra fájl (.ACE) A textúra fájl mérete (felbontása) csak 1024x1024, 512x512, 256x256, 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1 képpont lehet. (Speciális eseteket kivéve, lásd később.) A 32 képpontos, vagy annál kisebb textúrákat ritkán használják, elsősorban csak alapszínek tárolására jók. Arra viszont kíválóak, hiszen teljesen felesleges egyetlen színt nagyobb textúrán – megsokszorozva – tárolni, csökkentve ezzel is a még használható memória nagyságát. Az ACE fájl tulajdonképpen nem csak egy kép, hanem ugyanannak a képnek több, egyre csökkenő felbontású másolatainak összessége. Ez utóbbiak a MIP-szintek. Ezek a MIP-szintek a távolság függvényében jelennek meg, a távolság növekedésével egyre kisebbek. Erre a grafikus erőforrások észszerű kihasználása miatt van szükség, pl.: teljesen felesleges egy 1024-es textúra megjelenítése egy, a TS-ben több száz méterre látható objektumnál, hiszen a 3D grafikus megjelenítés során a részletek úgyis elvesznek. Ezek a MIP-szintek jól megfigyelhetők a TS-ben vonalsimítási és anizotróp szürési funkciót nem használó beállítás esetén: a sín ágyazatának textúrája a távolban lépcsőzetesen homályosodik, csíkosodik. Egyes videókártyáknak nehézséget (jelentős FPS csökkenést) okoz az 1024x1024-es textúrák használata. Ezen a problémán a textúra 512x512-essé alakításával jelentősen lehet segíteni. Ehhez javasolt a TGATool2 használata: - Megnyitjuk az 1024x1024-es textúrát. - A TGATool2 meüjéből meghívjuk a képet egy képszerkesztőprogramban (Pl.: PaintShopPro, vagy PhotoShop). - A kép tartalmát vágólapra tesszük. - Bezárjuk a képszerkesztőt. - Megnyitunk egy tetszőleges 512-es textúrát. - A TGATool2 meüjéből meghívjuk a képet egy képszerkesztőprogramban. - A vágólapról a képet lekicsinyítve beillesztjük az 512-es textúra helyébe. (Paint Shop Pro esetében lehetőségünk van kijelölésbe illeszteni a vágólapról. Ilyenkor ki kell jelölni a teljes 512-es képet, majd a kijelölésbe illeszteni a vágólapon található 1024-es képet. Más programok esetében megoldás lehet a vágolapos kép külön beillesztése, majd lekicsinyítése. A lényeg, hogy ilyenkor ezt is be kell illeszteni a TGATool2-vel megnyitott „zagyva” nevű képbe, mert csak így kerül vissza a TGATool2 kezelésébe a kép.) - Bezárjuk a képszerkesztőt. - Elmentjük az új 512-es képet a TGATool2-vel ACE formátumba, az 1024-es textúrával azonos névre. Figyelem! A művelet előtt érdemes biztonsági másolatot csinálni az 1024-es textúráról! Az ACE fájl formátuma is többféle lehet. A TGATool2 szerinti elnevezések: - ACE (no alpha): ez a textúra csak a képet tartalmazza, átlátszó vagy áttetsző felületek nem alakíthatók ki vele. Mérete általában kisebb. - ACE (alpha): ez a textúra 256 színű (greyscale) alfacsatorna képet is tartalmaz az eredeti kép mellett. Ezen az alfacsatorna képen lehet megadni, hogy a kép egyes képpontjaiban mennyire legyen átlátszó. A fehér helyen nem átlátszó, a feketén teljesen átlátszó. - ACE (-trans): ez a textúra 2 színű (fekete-fehér) alfacsatorna képet is tartalmaz az eredeti kép mellett. Ezen az alfacsatorna képen lehet megadni, hogy a kép egyes képpontjaiban átlátszó legyen-e vagy sem. A fehér helyen nem átlátszó, a feketén teljesen átlátszó. - ACE (DXT1): ez a textúra egy speciális tömörítési eljárás eredménye. Végeredményben a –trans típusúval egyezik meg. Valójában a TS számára mégis más, mivel a –trans típusú textúra használata esetén a színek valamiért foltosodhatnak a TS-ben. Ezen a foltosodáson lehet segíteni a DXT textúrával. (Lásd képek!) Ezek mellett a DXT textúra nagy előnye, hogy mérete sokkal kisebb is, mint a fenti textúráké. A DXT textúrához 2 bites alfacsatorna tartozik. A TGATool2 újabb verzióiban jobb oldalt található 3 pipa. - Compress ACE files: Tömöríti az ACE fájlt. A fájl mérete sokkal kisebb lesz. Cserében feltehetően a textúra betöltésekor fog többet szöszmötölni a gép, bár személy szerint nem vettem észre jelentős különbséget. - Include MIPMAPs: Ez a funkció a kép minőségét javíthatja főként abban az esetben, ha videókártyának engedélyezve van a vonalsimítási és anizotróp szűrési eljárások használata (Windows képernyő beállítások, Speciális fül). Ebben az esetben a textúra a TS-ben a távolság függvényében egyenletesebben homályosodik el, nem képződik csíkozás. A MIP-szintek kialakításánál használ speciális eljárást, a TS alapbeállításától különbözőt. Amennyiben a vonalsimítás és anizotróp szűrés nincs engedélyezve, a textúra sokkal hamarabb homályosodik el, használni ilyenkor ezt nem biztos, hogy érdemes, bár a megjelenést így is javítja. (A hatásáról lásd a képeket!) - Use mwdds for DXT: Erre még nem jöttem rá, mire jó.

4

A textúra megjelenését sokban befolyásolhatja a vonalsimítás és anizotróp szűrés használata, mértéke. Természetesen annál kevésbé csíkozott, kevésbé pöttyöző, vibráló lesz a kép, minél nagyobb mértékben engedélyezzük e két funkciót. Ez viszont a számítási műveletek miatt mind az FPS (Frame Per Secundum – megjelenített kép másodpercenként) értékét, mind pedig a kép élességét jelentősen csökkentheti a TS-ben. Személy szerint az éles kép híve vagyok, nem zavar, ha a távolban lévő fák „hangyáznak” (mint a TV szokott adásmentes időben), - sőt ez tekinthető a levelek szél általi vibrálásának is, amely élettelibbé teszi a képet. Akit ez zavar, bekapcsolhatja a vonalsimítás és anizotróp szűrés funkciókat, de ekkor számítson rá, hogy csökkenni fog az FPS értéke. Talán legjobb megoldás a legkisebb fokú – 2szeres – vonalsimítás és anizotróp szűrés bekapcsolása. Ez jelentős mértékben csökkentheti a hangyázást, viszont a legkisebb mértékben csökkenti az FPS-t. Gyakran alig látni a 2x-es és a nagyobb 4x-es 8x-os vonalsimítások és anizotróp szűrések esetén a kép minőségében javulást, viszont az FPS tovább csökken. (Erősebben, mint amekkora javulás elérhető. Persze akinek van rá processzorkapacitása…) A képminőség élesítését nem csak a textúra javításával és a grafikus beállítások megváltoztatásával, hanem a textúrát használó shape fájl módosításával is el lehet érni. Új objektum esetén természetesen már a készítéskor oda kell figyelni ezekre a dolgokra, de akkor sincs minden veszve, ha például egy, a netről letöltött objektum esetében csak a shape fájl áll rendelkezésünkre. Speciális méretű textúrafájlok Ilyenek a Cabview összeállítása esetén használt fájlok, és a TS információs ablakaiban megjelenő képek. Ezeket, mivel nem kerülnek 3D objektumokra, nem szükséges optimalizálni. Értelemszerűen nincs szükség a MIP-szintekre, hiszen például egy mozdony vezetőállás háttérképe esetén az fixen mindig a kamera előtt van. Ezeknél a képeknél a MIPszintek fel nem használása miatt nem szükséges a meghatározott felbontás használata sem. 1.2. A shape fájl (.S) A shape fájl egy unicode szöveg formátumú, általában letömörített fájl. A ki-/betömörítéshez sok program használható (Route Ritter, Shape File Manager, stb.), de szerintem a legalkalmasabb Okrasha Gia által készített Zipper program. Ha a .s kiterjesztéshez hozzárendeljük, akkor csupán egy Enter lenyomására a shape fájl ki- ill. betömörítődik. Ráadásul ez a program gyorsabb, mint pl a Route Ritter, illetve jobban összetömöríti a shapet, mint más programok (Pl.: a Gmax-ból kiexportált .s mérete is nagyobb, pedig az is tömörített.) Első lépés a shape átszerkesztése előtt, hogy kitömörítsük, illetve biztonsági másolatot készítsünk róla. Ezután már bátran ismerkedhetünk shape-ünk rejtelmeivel. Nézzük sorban: - Esetenként előfordul, hogy az objektum a TS-ben eltűnik, ha a látómező szélére esik. Ez általában a TSM (Train Sim Modeller) modellező program esetében szokott fellépni rendszeresen, de előfordult már Gmax program esetében (kisebb méretű objektumok esetén) is, illetve a ShapeFileManager programnál az eltolás funkció esetében. Ezen a hibán általában lehet segíteni, ha volumes ( részben a volsphere ( sorokban a vector () bejegyzés után a zárójelen kívül álló számot min 10 %-kal magasabb értékűre írjuk be, mint a vector () bejegyzés zárójelén belül álló legmagasabb szám értéke. Az esetek 90 %-ában a +10 %-os emelés segít. A maradék esetben emeljük próbálgatással még magasabb értékre a számot. -

A shader_names ( részben a felhasznált textúra jellemzőket lehet beállítani. A named_shader ( bejegyzésben található nevek jelentései a következők: o TexDiff: normál, nem átlátszó textúra; a legtöbb esetben ezt használjuk o BlendATexDiff: ezt akkor látjuk ott, ha olyan textúrát is használ az objektum, amely átlátszó vagy áttetsző (2 vgy 256 bites alfacsatornával rendelkező textúrát használ a kép); a textúra csak abban az esetben lesz átlátszó az alfa csatorna megléte esetén is, ha ez a név van ide beírva o BlendATex: ez a textúratulajdonság elég érdekes dolgot produkál a TS-ben: a tárgy az TS-beli éjszaka beálltával nem sötétedik el, hanem nappali fényben ragyog. Ez általában hibaként szokott jelentkezni, és a bejegyzés BlendATexDiff-re való átírásával megszüntethető, de tulajdonképpen ennek a tulajdonságnak a segítségével sok érdekes objektum állítható elő (Pl.: tábortűz) o Egyéb, használható, de általam ki nem próbált bejegyzések: Tex, AddATex, AddATexDiff

-

A texture_filter_names ( részben a MIP-szintek kezelését (nem biztos, hogy ez a legjobb szó rá) lehet beállítani. Általában a MipLinear bejegyzés szerepel itt, de egyes objektumok esetében a LinearMipNearest bejegyzés csökkentheti a textúra csíkosodását. Több más bejegyzés is szerepelhet itt, de igazából nagy különbséget nem tapasztaltam közöttük, így nem sorolnám fel őket.

5

-

-

A points ( egységben az objektumot meghatározó pontok koordinátái vannak felsorolva. A koordináták értékeit átírva bizonyos mértékig módosíthatjuk a shape fájlt. Pl.: megváltoztathatjuk egy egyszerű felépítésű objektum méreteit. Ez természetesen csak bizonyos egyszerűségig lehetséges, hiszen meg is kell találni azokat a pontokat, amit módosítani szeretnénk. Pl.: Senki ne próbálkozzon egy M62-es középső tengelye csapágyfedélének átméretezésével, viszont egy 400 poligonos személykocsi tetőmagasságát viszonylag egyszerűen megváltoztathatjuk (legmagasabb Z értékek). Ezen beavatkozás csakis saját felelősségre, az eredeti objektum elmentésével végezhető. A módosított objektum esetén figyelmbe kell venni a szerzői jogokat! (Nem etikus egy ilyen objektumot saját készítésként kiadni!) A pontok számát új készítésű objektum esetében minimalizálni kell! Bizonyos esetekben – túl magas pontszám felett – a TS nem hajlandó megjeleníteni a modellt a játékban. A pontokat érdemes összevonni, amennyire lehet. Minden pontkoordináta megterhelés a TS számára. Ha egy adott koordinátára több pont is utal, az az erőforrások pazarlása. Ezen segíthet a PolyMaster nevű program Punkte zusammenfassen funkciója, mely megkeresi és összevonja az azonos koordinátájú pontokat. Természetesen jobb, ha már a modell készítésekor a modellező programban megtörténik ez az összevonás.

-

A számunkra fontos következő rész az images ( rész, amely azoknak a textúráknak a nevét tartalmazza, amelyeket a shape fájl használ. Ezeket általában átfestések alkalmával kell (illene) átírni.

-

A textures ( részben a fenti textúrák tulajdonsága van felsorolva. Az első szám a kép sorszáma. Számunkra igazából a 3. szám a fontos. Ez a szám utal – a Gmax-ban alkalmazott név szerint – a MIP LOD Bias-ra. Ez a szám végeredményben arra utal, hogy az adott textúra milyen távolságban kezdjen el „homályosodni”, azaz milyen távolságban váltson át egy alacsonyabb MIP szintre a megjelenítés során. Konkrétan nem távolságot kell érteni ezen a számon: lehetséges értékei 0, -1, -2, -3 (Mással nem láttam, és nem is próbáltam.). 0 esetén a legrövidebb távolságonként vált, -3 esetén a legnagyobb távolságonként, azaz a legmesszebbre a nagyobb felbontású képet használja, tehát így lesz legélesebb a kép. (Lásd a képeket!) -3 esetén nagyobb a fent említett „hangyázás”, csíkosodás. Ez viszont finomítható, kiszűrhető az Include MIPMAPs opció (TGATool2) használatával, illetve a vonalsimítás és anizotróp szűrés engedélyezésvel. Igazán jó eredményt csak mindkét módszer egyszerre alkalmazásával érhetjük el. A MIPmaps-szal elmentett textúra önmagában homályossá teszi a látható képet, és csak a vonalsimítás, és anizotróp szűrés bekapcsolása esetén jelenhet meg éles képében a tárgy. A -1, -2 érték az arany középút lehet. Mindenkinek a saját ízlése, gépének grafikus adottságai, beállítása teszi függővé, melyik a számára legoptimálisabb érték. A TS-ben ezen paramétert tekintve vannak megkötések. A Dynamic Track és a Forest beépített objektumok esetében a tapasztalat szerint (mivel fizikai shape fájl ezekhez nem csatolható) 0 értékű lehet. Emiatt ezen objektumoknál mindenképpen érdemes az ACE (-trans) típusú textúra használata, különben elég csúnya eredményt kapunk: a fák foltosak lesznek, és csak igazán közelről lesz látható az eredeti textúra (Lásd a képeket!). A másik megkötés inkább egyezményes jellegű: a „normál jellegű” sínelemek tekintetében (TS alapelemek és Xtracks kiadások) a vágányzat ágyazatának textúrája -1 értékű. Ez már kevésbé zavaró, de közel sem a legjobb megoldás (szerintem).

-

A vtx_states ( részben is van egy fontos jellemző szám, amivel az objektum tulajdonságát befolyásolni lehet. Itt a 3. szám mutatja meg, a felület milyenségét. Itt elsősorban a csillogásra ill. matt felületre gondolok. -5 szám esetén az objektum részegységének felülete matt, míg -6 esetén fényesen csillogós lesz. Több szám is szerepelhet ezen a helyen, de leggyakrabban ezt a két számot szokták használni. A felületek csillogása csak részobjektumonként együtt adható meg, ez függ az objektum kialakításától. Előfordulhat, hogy csak a teljes modellre vonatkoztatva lehet a csillogást megváltoztatni. Természetesen ezt az értéket is a modell elkészítésekor kell (kellett volna) beállítani.

-

Újabb, megjelenést befolyásoló érték található a prim_states ( részben. Itt a prim_state () bejegyzés utolsó és utolsó előtti előtti (tehát hátulról a harmadik) számának átírásával a textúra más textúrákra gyakorolt hatását állíthatjuk be. Lehet: o … 0 0 1): átlátszó úgy, hogy minden átlátszó objektumot kitakar o … 1 0 1): átlátszó úgy, hogy az átlátszó objektumok is látszanak mögötte o … 1 0 3): átlátszó úgy, hogy még a nem átlátszó részein is átlátszik rajta más textúra Az első az alapeset, alfacsatorna nélküli textúra esetén normálisnak számít, alfacsatornás, átlátszó textúra esetén viszont hiba, igen sokan találkozhattak már vele. Ilyenkor a szögletes, amúgy átlátszó textúra kitakarja például a háttérben álló fákat, vagy például ezért nem látszanak a BDV motorvonat ülései kívülről. Sajnos a TS jelzőfény textúrái is ebbe a kategóriába tartoznak, így a távolról látszódó speciális jelzőfények esetén előfordulhat, hogy kitakarják például a Forest objektum elemeit. A második beállítás erre a problémára a megoldás. (Természetesen a beépített TS elemek – Forest, jelzőfények – esetében nem.)

6

A harmadik nagyon fontos beállítás a TS-ben. Ez a beállítás a vágányelemek ágyazatánál használatos az árnyék megjelenítéshez. A jármű árnyéka tulajdonképpen egy másik objektumnak tekinthető, amely a terepen jelenik meg. Ahhoz, hogy ez átlátszon az ágyazaton, ennek a beállításnak meg kell lennie. Sajnos ez által páldául egy rosszul elhelyezett alfatextúrás objektum (pl.: gaz) is átlátszik az ilyen objektumokon, így ez sajnos nem mindenhol alkalmazható megoldás, illetve a sín esetében okozhat problémákat az objektumok lehelyezésekor. -

Ugyancsak fontos lehet a LOD távolságok utólagos beállítása is. Ez a lod_controls ( részben tehető meg, a distance_level ( rész dlevel_selection () bejegyzésében. A distance_level ( részben a LOD szinteknek megfelelő megjelenés van felsorolva, növekvő LOD szintek (általában növekvő távolságok szerint). A dlevel_selection () bejegyzésben a számok métert jelentenek a TS-ben, ezeket kell átírni, lehetőleg növekvő sorrendben.

-

A shape fájl vége felé az animations ( részben az animációk megadása látható. Ezen általában nem kell változtatni, de időnként lehetséges bizonyos módosítás – animáció lejátszási sebesség változtatás (az animation ( bejegyzés második számjegye az animáció FPS értéke, vagyis ezáltal a sebessége is, feltéve, hogy a TS ehhez nem rendelt előre meghatározott időintervallumot; pl.: váltó animácó kb. 1 másodperc hosszú (ha nem végezne ennyi idő alatt, akkor levágja a végét), sorompó animációnál Route Editorban állítható érték) – de ez nem mindig hozza meg az elvártakat. Általában csak ellenőrzésre használjuk.

1.3. A shape data fájl (.SD) Az .SD azaz shapedata fájl a shape fájlhoz kapcsolódó, a TS számára fontos információkat tartalmazza. A TS-ben alig lehet néhány objektum e nélkül a fájl nélkül. Bejegyzései a következők: -

ESD_Bounding_Box ( bejegyzés a shape fájl ütközési méretét adja meg. E nélkül átmegy rajta minden, mint forró kés a vajon. A járműveknél különösen fontos szerepe van az összekapcsolódás miatt: „Az ENG-ben, ill. WAG-ban található egy Size ( ) sor, ami azért felelős, hogy a kocsik ne 5 méterre legyenek egymástól, amikor össze vannak kapcsolva. Ha pl a hosszúságot 1 méterrel nagyobbra veszitek, akkor a kocsik ütközői mindkét oldalon fél-fél méterre lesznek a másik kocsi ütközőjétől. A másik fontos dolog méretügyileg a Bounding Box nevű izé, ami arra való, hogy mintegy "körbeölelve" a kocsit ebbe fogunk beleütközni. A Bounding Box méretének meg kell egyeznie a kocsi méreteivel ( hossz, magasság, szélesség ), mert különben a következő esetek fordulhatnak elő: Ha hosszabb a bounding box, akkor a kocsi a lekapcsolásakor elrúgja magát a szerelvénytől, és ha újra rá akarunk csatlakozni, akkor először a hosszabb bounding boxba csapódunk bele, és nem fogjuk elérni a csavarkapcsot ( mivel a csavarkapocs az ENG-WAG ban megadott ( hossz, szélesség, magasság ) szerint helyezkedik el. Ha rövidebb a Bounding Box, akkor lekapcsoláskor ugyan nem ugrik el a másik kocsitól a kocsink, viszont rákapcsolódáskor be fog menni a kocsiba addig, míg meg nem találja a bounding boxot, mivel nem a kocsiba ütközik bele, hanem ebbe a láthatatlan téglatestbe ( a bounding boxba ). Na ilyenkor pl kiakadhat a TS, mivel hülyét csinál belőle ez a két hosszméret, és azt kiáltja a TS: mi a franc van, hogy van ez? A bounding Boxot elő lehet csalni a CTRL NUM+ billenytűkombinációval, és az SD fájl ESD Bounding Box sorban lehet beállítani. Itt hat értéket találtok, ami a PIVOT PONT hoz viszonyítva a téglatest ( bounding box ) csúcsainak a koordinátái.”

-

Az ESD_Alternative_Texture ( részben lehet meghatározni, hogy a játékban beállítható különböző időjárási körülmények között a TS mely textúrákat használja az adott shape fájlhoz. Az értékei az alábbiak lehetnek: o 0: mindig csak az alap textúrát használja (Textures könyvtár) o 1: az alaptextúra mellett a havas textúrát is használja (Textures\Snow) o 252: minden évszakban külön textúrát használ o 256: az alaptextúra mellett csak az éjszakai textúrát használja (Textures\Night könyvtár) Figyelem! Ez a beállítás hibás az MSTS-ben. Annak ellenére, hogy nem kellene, a program a Global könyvtárban havas textúrkat is keres! Lehetőleeg ne használjuk!!! o 257:az alaptextúra mellett az éjszakai és a havas textúrákat is használja (Textures\Night és Texturs\Snow)

-

Az ESD_Detail_Level ( bejegyzésben egy 0-10-ig terjedő szám adható meg, mely az adott objektumnál a TSbeli grafikai beállításoktól függően a megjelenését (vagy nem megjelenését) befolyásolhatja. 0 érték a leginkább részletgazdag megjelenést, a 10 a legkevésbé részletgazdag megjelenést jelenti.

7

-

Az ESD_Complex ( bejegyzés segítségével bonyolultabb formájú Bounding Boxok is megadhatók. A szám az utána következő ESD_Complex_Box ( bejegyzések száma. Az ESD_Complex_Box ( bejegyzésben az elforgatás szögét (x, y, z), az eltolás mértékét (x, y, z), majd a Bounding Box esetében megszokott hat koordinátát (a PIVOT ponttól a téglatest kiterjedését) kell megadni.

-

Az ESD_Tunnel ( bejegyzésben az alagútkapuknál felmerülő ütközési problémát lehet feloldani. Ha ugyanis alagútkapunál kisiklik a vonat, az nem megy be az alagútba, hanem a talaj vonalát követve felpattog a hegyoldalra. Ezzel a bejegyzéssel „lyukat üthetünk” a hegyen. Az első érték egy hosszérték (sajnos nem értem a Kuju techdocs leírását, mire jó), a következő érték az alagútkap falvastagsága, azaz az alagút nyílásának belsejétől a falak külső éléig. Ezután az alagút szélessége, magassága, majd az a hosszirányú távolság adandó meg, amely az alagút sínelemhez vezet. Soha nem próbáltam, hogy működik-e ez a funkció, és még soha nem is találkoztam ilyesmivel a gyakorlatban.

1.4. Összegzés A fenti módszerek nem alkalmasak a shape fájlok nagyobb átalakítására, inkább csak hibajavításra jók. Az eredeti modell nagymértékben nem befolyásolható velük, de alkalmasak apró, néha bosszantó hibák kiküszöbölésére, vagy segítségünkre lehetnek, ha valamit elfelejtettünk, vagy nem jól állítottunk be egy modell elkészítésekor (sok időt megspórolhatunk, ha egy exportálási művelet helyett csak egy számot kell átírni). A fenti tanácsok nem azt akarják célozni, hogy ezentúl mindenki piszkáljon bele a shape fájlokba! Ha lehet, ne rondítsunk bele más munkájába, csakis a javító szándék vezéreljen, és az eredmény is szemmel látható legyen! Tisztelettel kell lenni az eredeti készítő szerzői jogát illetően! Lehetőleg minden nagyobb beavatkozás előtt kérdezzük meg a készítő véleményét. Minden módosítás előtt készítsünk biztonsági másolatot! A módosításokat mindenki saját felelősségére végezze! Nem teljesen biztos, hogy a fent leírtakkal el lehet érni a kívánt hatást! 1.5. Javaslat Az általam legmegfelelőbbnek talált beállítások: Kisebb teljesítményű gépek esetében: - Grafikus beállításoknál anizotróp szűrés és vonalsimítás kikapcsolva – ezáltal nem terheljük a processzort, az FPS a lehető legnagyobb lesz - MIP LOD Bias -3 (lásd shape fájl, textures ( rész) – a lehető legélesebb textúrák, nincsenek foltos tárgyak - Include MIPMAPs opció (TGATool2) nélküli textúrák – a lehető legélesebb textúrák érdekében; a Forest objektumok textúráinál kimondottan célszerű a DXT textúrák ACE (-trans) típusú textúrára konvertálása. - A textúrák mérete lehetőleg 512x512 vagy az alatt – videókártya és alaplapi memória kímélése céljából; egyes videókártyák az 1024-es textúráktól jelentős lassulást szenvednek Közepes teljesítményű gépek esetén: (2 GHz feletti Celeron P4) - Grafikus beállításoknál anizotróp szűrés és vonalsimítás bekapcsolva a legkisebb fokozatra (2x) – kis mértéken terhelhető processzor - MIP LOD Bias -3 (lásd shape fájl, textures ( rész) – lehető legélesebb textúrák - Include MIPMAPs opcióval (TGATool2) optimalizálva mentett textúrák – a fenti -3as érték miatti csíkozás, vibrálás megszüntetésére - Lehetőleg 512x512 vagy az alatti méretű textúrák, videókártyától függően akár 1024x1024-es textúrák – memóriától és videókártyától függő beállítás; 1024-es textúrás objektumok sokkal élesebb képet mutatnak Nagyteljesítményű gépek esetén: (2 GHz feletti Pentium 4) - Grafikus beállításoknál anizotróp szűrés és vonalsimítás bekapcsolva (akár maximumra) - MIP LOD Bias -3 (lásd shape fájl, textures ( rész) - Include MIPMAPs opcióval (TGATool2) optimalizálva mentett textúrák - 1024x1024-es textúrák is nyugodtan szerepelhetnek Mindezen beállítások természetesen az egyedi gépektől, a felhasználók ízlésétől, igényeitől is függenek (zavaró-e a vibrálás, vagy sem, inkább szebb grafika legyen, inkább gyorsabb grafika legyen, stb.). Nincs egyetemleges megoldás, mindenkinek magának kell beállítani a lehetőségeket, illetve az objektumgyártáskor törekedni rá, hogy a lehető legjobb minőségű shape és textúra fájlokat készítse el.

8

1.6. Képek A következőkben néhány képpel illusztrálnám a fent leírtakat. Mindenki maga döntse el, melyik beállítást használja.

Forest objektum DXT1 típusú textúrával, MIPmaps (és tömörítés) nélkül Vonalsimítás és anizotróp szűrés kikapcsolva

Forest objektum DXT1 típusú textúrával, MIPmaps (és tömörítés) nélkül 2-szeres vonalsimítás és 2-szeres anizotróp szűrés mellett

9

Forest objektum DXT1 típusú textúrával, MIPmaps (és tömörítés) nélkül 8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

Forest objektum -trans típusú textúrával, MIPmaps-szal és tömörítéssel 2-szeres vonalsimítás és 2-szeres anizotróp szűrés mellett

10

Forest objektum -trans típusú textúrával, MIPmaps-szal és tömörítéssel 8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

Forest objektum -trans típusú textúrával, MIPmaps nélkül és tömörítéssel Vonalsimítás és anizotróp szűrés kikapcsolva

11

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: 0 Vonalsimítás és anizotróp szűrés kikapcsolva

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: 0 2-szeres vonalsimítás és 2-szeres anizotróp szűrés mellett

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: 0 8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

12

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: -1 Vonalsimítás és anizotróp szűrés kikapcsolva

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: -1 2-szeres vonalsimítás és 2-szeres anizotróp szűrés mellett

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: -1 8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

13

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: -3 Vonalsimítás és anizotróp szűrés kikapcsolva

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: -3 2-szeres vonalsimítás és 2-szeres anizotróp szűrés mellett

Normál objektum No Alpha típusú textúrával, tömörítéssel, MIPmaps nélkül ill. MIPmaps-szal A MIP LOD Bias értéke: -3 8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

14

Különböző Terrtex textúrák nagy távolságból Vonalsimítás és anizotróp szűrés kikapcsolva

Különböző Terrtex textúrák nagy távolságból 8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

15

MIPmaps nélküli os MIPmaps-szal elátott textúrák különbsége Vonalsimítás és anizotróp szűrés kikapcsolva

MIPmaps nélküli os MIPmaps-szal elátott textúrák különbsége 2-szeres vonalsimítás és 2-szeres anizotróp szűrés mellett

MIPmaps nélküli os MIPmaps-szal elátott textúrák különbsége 8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

No Alpha és DXT textúrák különbsége

8-szoros vonalsimítás és 8-szoros anizotróp szűrés mellett

16

ACE –trans típusú textúra a jármű elején (foltosodás!!!) Vonalsimítás és anizotróp szűrés kikapcsolva

DXT1 textúra a jármű elején

Vonalsimítás és anizotróp szűrés kikapcsolva

17

2. A pálya objektumai Az MSTS alapvetően mindent az objektumokkal csinál. Objektum a sín, az út, a vonat, a fák, épületek, egyszóval minden. Az előző fejezetben megismerhettük egy meglévő objektum szerkezetét. Most a fajtaspecifikus részletekre szeretnék kitérni. 2.1. Statikus objektumok A statikus objektumokat a pályákon használjuk, mint tereptárgyakat. Szerkezetük általában nagyon egyszerű, esetenként animációt tartalmazhatnak, mely ciklikusan ismétlődve játszódik le, amennyiben a Route Editorban bekapcsoljuk az animációjukat. Nagyon lényeges egy 3D objektum elkészítésénél a megfelelő PIVOT pont megadása, mivel ez lesz a TS-ben a beillesztés pontja. Ez általában a tárgy aljának közepe (pl.: ház, fa) szokott lenni, de hosszú objektumoknál (pl.: kerítés) érdemes az egyik végpont aljához illeszteni a PIVOT pontot. Ez akkor jó, ha több elemet akarunk lerakni egymás után – akár egy nyomvonal, pl.: vasút mentén –, mert ilyenkor az első elem lerakása és beforgatása után a második elemet könnyedén az első végéhez illeszthetjük, és forgathatjuk a helyes irányba. Fontos a PIVOT pont iránya is. Mivel a PIVOT nem csak egy pont, hanem tulajdonképpen objektumunk koordináta rendszerének középpontja, így azt is megadja, hogy melyik irányban van az X, Y, Z kiterjedés. A TS ez alapján helyezi el az objektumot a térben. (Előfordulhat, hogy a Gmax-ban jól áll a tárgy, de a TS-ben eldőlve, vagy akár fejjel lefelé jelenik meg a beillesztéskor.) 2.2. Speciális pályaobjektumok A normál statikus objektumok mellett a TS pályákon szerepelhetnek funkcióval ellátott objektumok is. Ilyenek például a sorompók, jelzők, „mászkálók”, vételező helyek, sebességkorlátozók, felsővezetéktartó oszlopok, erdők, talajtextúrák, távíró póznák, egyéb beépített objektumok. Sorompók (Level Crossing) A sorompó objektum kialakításánál fontos, hogy tartalmazzon legalább egy GATE<szám> nevű animált részobjektumot. Ez lesz a felnyíló sorompó karja. Programozása igen sok funkciós, és a Route Editoron belül a sorompó objektum lerakásakor beállítható. A Level Crossing objektum nem csak közúti sorompó lehet. Ez az objektum tulajdonképpen a közeledő vonat hatására animál, majd a vonat elhaladása után visszaáll alaphelyzetbe. Ezen tulajdonsága miatt alkalmas vágányzáró sorompók, kapuk, stb. kialakítására is. A LevelCrossing sín- és útfüggő objektum. (Route Editor-beli jele: narancs kocka) Figyelem! Ha több mint négy vágány keresztezi az utat, gondok lehetnek a működésével! Jelzők (Signal) A jelző objektum kialakításánál szintén fontos, hogy megfelelő részobjektumokat tartalmazzon. A legfontosabb, hogy legalább egy HEAD<szám> részobjektumot tartalmazzon. Ez lehet animált is (karos jelzők), de animáció nélkül is meg kell lennie (fény jelzők). A jelzőobjektum a programozás révén akár több animációt is végezhet (részobjektumonként egy HEAD állapotváltozása), illetve tetszőleges számú fényforrás jelenhet meg rajta. Programozása a sigcfg.dat és sigscr.dat fájlokban történik (lásd egy későbbi külön fejezetben). A Signal sínfüggő objektum. (Route Editor-beli jele: piros gúla) Ez az objetum a REF fájlba történő bejegyzés nélkül szerepel az objektumok listájában (Track Objekts csoportban). „Mászkálók” (Hazard) A „mászkáló” objektumok olyan aktív objektumok, melyek nem statikusan vannak jelen a pályán, számuk az activitykben szabályozható. Ráadásul animáció révén képesek mozgásra is, illetve, aktivizálódnak a vonat közeledtére, vagy a mozdony kürtjének bekapcsolására. Két fajtája van: állat (Animals) és ember (People). Működésük jelenleg még számomra nem teljesen ismert, a TS-ben mindössze két ilyen típusú objektummal találkoztam. A Hazard sínfüggő objektum. (Route Editor-beli jele: színes oktaéder) Vételező helyek (Pickup) A vételező helyek olyan animációval is ellátott objektumok, melyek a járművek feltöltésére használhatók. Elsősorban gőzmozdonyok víz- és szénvételezéséhez, illetve dízelmozdonyok üzemanyaggal való feltöltéséhez használhatók. Amennyiben a járművel megállunk mellettük, és megnyomjuk a T gombot, az esetleges animáció

18

végrehajtódik, és a jármű tartálya elkezd feltelni. Az objektum alapját BASE-nek, az animáló részobjektumot ARM-nak kell elnevezni (és a TS dokumentációja szerint az alap PIVOT pontját a – például – kiforduló kar végállapota alá kell helyezni; személy szerint nem igazán értem, miért?) Működésük bonyolultsága miatt ezek közül is csak az eredeti elemek léteznek, nem sokan kisérleteztek átalakításukkal. A Pickup sínfüggő objektum. (Route Editor-beli jele: sárga kocka) Sebességkorlátozók (Speedpost) A sebességkorlátozók statikus táblák, kijelző funkcióval ellátva. A következő pályaszakasz sebességének illetve a pálya szelvényszámának (távolság értékének) kijelzésére szolgálnak. Hasznos tulajdonságuk, hogy egy textúra fájlban megadott karakterkészletből válogatva számok irathatók ki rájuk. Programozásuk két részből áll: az alaptulajdonságok (használandó shape fájl, karakterkészlet textúra, betüméret, stb.) megadása a speedpost.dat fájlban, míg az egyes lehelyezett objektumok számértékének, tulajdonságának beállítása a Route Editorban történik (lásd egy későbbi külön fejezetben). A Speedpost sínfüggő objektum. (Route Editor-beli jele: színes oktaéder) Ez az objetum a .REF fájlba történő bejegyzés nélkül szerepel az objektumok listájában (Speed Limits csoportban). Felsővezetéktartó objektumok (Gantry) A felsővezetéktartó objektumok tulajdonképpen programozottan a pályára – a vágányokra, ill. mellé – lerakott statikus objektumok. A programozás a gantry.dat fájlban történik (lásd egy későbbi külön fejezetben). Előnye a Gantry típusú objektumoknak, hogy a pálya vonalában egyenletes kiosztással helyezhető le sok objektum, illetve a lehelyezés után mindez – az első mentésig – visszavonható. A lehelyezés tile-onként történik. Az objektumok szempontjából fontos a PIVOT pont helye az objektumban. A lehelyezésnek két módozata van: vagy a pálya középvonalában, vagy a szélső vágányok mellé mindkét oldalra. Ehhez kell, hogy méreteiben is illeszkedjen a PIVOT pont helye: középvonalba helyezés esetén kapuszerű objektumnál középre, a két oldali elhelyezésnél pedig úgy, hogy az objektum a vágánytól kellő távolságra kerüljön. Az objektum neve félrevezető, ugyanis nem csak felsővezetéktartó oszlopok helyezhetők le vele, hanem bármely más statikus objektum is (pl.: szelvénykő, távíró oszlop, akár bokrok is). A Gantry nem sínfüggő objektum, de az automatikus lehelyezése csak sín mellé történhet. Ez az objetum a .REF fájlba történő bejegyzés nélkül szerepel a Route Editor menüjében. Erdők (Forest) Az erdő objektum a TS-be félig beépített objektum. Tulajdonképpen csak minimális mértékben tudjuk programozni, illetve a használt textúrát kell megadnunk. Ez az objektum egy egyszerű (két egymásra merőleges kétoldalúan textúrázott lap) objektum „véletlenszerű” megsokszorozását jelenti egy változtatható méretű téglalapon belül. A fák (az objektumok) méretének megadása a forest.dat fájlban történik, míg egy sűrűségi tényező megadása a Route Editorban. A fák megjelenését tekintve a „véletlenszerű” szó azért van idézőjelben, mert látszólag ugyan össze-vissza rakja le a fákat, viszont ezt valamiféle logika alapján teszi, mivel azonos mérteű téglalap esetén azonos sűrűség mellett ugyanoda kerülnek a fák. A véletlenszerűséget nagyban rontja, hogy a fák mindig azonos irányban állnak. Előnye viszont, hogy a fák talpa a talajra kerül, bármilyen változatos formájú is az. A Forest objektum túlzott használatát kerülni kell, mivel elég jelentős lassulást (FPS csökkenést) okozhat a játék számára. Mint minden más objektum a TS-ben, ez sem csak fák lehelyezésére szolgálhat, bár a fix shape erősen korlátozza a lehetőségeket. (Route Editor-beli jele: három zöld kocka) Ez az objetum a .REF fájlba történő bejegyzés nélkül szerepel az objektumok listájában (Track Objekts csoportban). Talajtextúra (Transfer) A talaj kinézete a Route Editorban egyrészt a talajtextúra megváltoztatásával, másrészt kisebb felületek esetén Transfer objektum lehelyezésével változtatható meg. Ez az objektum is egy beépített objektum, mely tulajdonképpen nincs is. Az általunk megadott textúrát ugyanis a talajra fekteti rá a megadott méretben. Maximális mérete 500x500 m lehet. A programozása a Route Editorban történik a méretek megadásával. (Route Editor belijele: zöld gúla) Távíró pózna (Telepole) Egy speciális objektumlehelyezési módszer, ha a tárgyat, mint távírópóznák sorát helyezzük le. Ilyenkor egy vonalban, adott távolságra helyezi el ugyanazon objektumot a lehelyezéskor a TS. Beállítása külön fájlban történik (lásd egy későbbi külön fejezetben). Sajnos a Route Editor fogyatékossága miatt ez az elem elég nehezen kezelhető, ráadásul bizonyos esetekben az első és utolsó elem nem abban az irányban áll, mint a többi, ami miatt

19

nem szívesen alkalmazzuk. Ez az objetum a .REF fájlba történő bejegyzés nélkül szerepel az objektumok listájában. Beépített interaktív objektumok A beépített interaktív objektumoknak csak funkciójuk van, a vizuális megjelenítésben nincs szerepük. Látható formájuk is csak a Route Editorban van, sem shape, sem textúra fájl nem tartozik hozzájuk. Az alábbi fajták léteznek: - Siding (két sárga gúla, köztük vonal); a vágányok megnevezésére szolgál, activitykben van jelentősége - Platform (két zöld gúla, köztük vonal); a peronok megnevezésére szolgál, activitykben van jelentősége - Yard definition (lila kocka); rendezőpályaudvarok megjelölésére szolgál, ahol alkalmazható egy speciális kameranézet. Ez az objetum a REF fájlba történő bejegyzés nélkül szerepel az objektumok listájában (Track Objekts csoportban). - Sound source (sárga oszlop); hangforrás helye (lásd egy későbbi fejezetben). Ez az objetum a .REF fájlba történő bejegyzés nélkül szerepel az objektumok listájában (Sound Source csoportban). - Sound region (négy darab ságra gúla nyílszerű objektumként); pályamenti menethang változás helye (lásd egy későbbi fejezetben). Ez az objetum a REF fájlba történő bejegyzés nélkül szerepel az objektumok listájában (Sound Regions csoportban). - CarSpawner (két kék gúla, köztük kék-fehér színben változó vonal); az utakra telepíthető vele autóforgalom (lásd egy későbbi fejezetben). Beállítása külön fájlban történik. 2.3. A sín- és útelemek Speciális kategóriába tartoznak a sín- és útelemek. Ezen elemeket szintén megszabott formában kell létrehozni ahhoz, hogy jól illeszkedjenek az eddigi elemekhez. A sínelemek tekintetében egyrészről az eredeti elemeket, és az azokhoz kapcsolódó XTracks kiadásokat tekinthetjük alapnak, de egyre nagyobb teret hódítanak a tsection.dat (lásd később) egységesítésével más rendszerű, részben az eredeti elemekhez kapcsolódó újabb sínelemek. Ilyenek például az YTracks, az MTracks, vagy a UK Fine Scale sínelemek. Hazai viszonyok között az eredeti elemek az XTracks-szal kiegészítve bőven elegedőek pályaépítéshez. A többi sínelem gyűjtemény nagyon szép elemeket tartalmaz, de lényegesen több – időnként túlzottan is sok – poligon felhasználásával készültek, így nem biztos, hogy használatuk kifizetődik (FPS tekintetében). A következő részben elsősorban az alapelemek, és az XTracks kiadású elemek – Okrasha Gia – által felügyelt szabványosítási jellemzőit írom le. A sínelemek shapeje két részből áll: az ágyazatot jelképező alaplapból és a ráhelyezett két téglatestből, mely a sínt ábrázolja. Az alap – egyenes elemet tekintve – egy 2 poligonos lap, melynek csak a teteje van letextúrázva az ACleanTrack1.ace nevű transzparens (BlendATexDiff) textúrával. Nagyon fontos, hogy ezt a textúranevet használja, hiszen csak így lehet kompatibilis sínelem. Az egyenletes talpfakiosztás érdekében egy 5 méteres egyenes sínelemre kell a textúrát egyszer ráfektetni, és többszörözve nyújtani annak függvényében, hogy mennyiszer hosszabb az adott sínelemünk (pl.: egy 15 méteres egyenes elemre 3-szor van a textúra ráillesztve). A sínek nem átlátszó (TexDiff) ACleanTrack2.ace textúrával vannak bevonva, úgy, hogy a tetejükre a sín fejét, két oldalukra a sín oldalát ábrázoló rész van beillesztve. A sínek téglatestjeinek végeit, illetve aljának poligonjait törölték. A sín textúrázásánál nem lényeges a többszörözés mértéke, mégis jobb, ha a rövidebb elemeknél csak egyszer, teljes hosszában fektetjük rá a textúrát a kellő részre. Az ágyazat MIP LOD Bias-a -1, a sínfejé 0 kell, hogy legyen – egyezmények alapján. Így biztosítható, hogy egyes sínelemek ne lógjanak ki a sorból. (Természetesen így is akad néhány elem, amely nem az egyezményes elvek alapján készült és más látványt mutat a játékban.) Nagyon fontos még, hogy az ágyazat esetén ne felejtsük el beállítani az árnyék átlátszóságát biztosító beállítást (lásd a shape fájlnál). Nem normál nyomtávolságú elemek esetén a textúrák neve eltérhet a fentiektől. Az útelemek tekintetében nincs ilyen mértékű szabványosodás. Az alapelemeken kívül létezik még a NewRoads nevű folyamatosan fejlesztett csomag, mely igen sok elemet tartalmaz – talán túl sokat is – és kompatibilis az XTracks tsection.dat fájljával. Speciális követelmény az útelemeknél nemigen van, a NewRoads csomag is külön textúracsomaggal rendelkezik, csak részben használja az eredeti elemeket. Ezek az objetumok a .REF fájlba történő bejegyzés nélkül szerepelnek az objektumok listájában (Track Sections illetve Road Sections csoportban). A sínelemek között is van beépített elem, a dinamikus vágány (Dynamic Track), mely nevét a méreteinek beállíthatóságáról kapta. Beépítettsége miatt shape fájl nem tartozik hozzá, textúraként pedig az alapelemek textúráját használja. Csak normál nyomtávolságú vágány formájában létezik. Beállítása a Route Editorban a pályára helyezéskor történik.

20

2.4. A pályaobjektumok pályába integrálása (.REF) Ahhoz, hogy egy objektumot egy TS pályába be tudjunk építeni a fentieken kívül sok fontos dolgot kell elvégeznünk: Először is másoljuk a shape (.S) és shape data (.SD) fájlt a pálya Shapes könyvtárába. Ezután másoljuk a textúra fájlt (.ACE) a Textures könyvtárba, illetve ha a shape különböző körülmények között több textúrát is használ (lásd .SD fájl ESD_Alternative_Texture ( bejegyzését), úgy a megfelelő könyvtárakba szintén tegyük meg a megfelelő textúra fájlok bemásolását. Ahhoz, hogy a TS tudjon az objektumunkról, tegyünk egy bejegyzést a .REF fájlba. Ez a fájl a pálya könyvtárában kell, hogy legyen a Route Editor beli építés alatt (a játék folyamán már nincs szükség rá). A .REF fájlban szereplő bejegyzés neve mondja meg a TS-nek, hogy milyen fajta objektumról van szó: -

A Static ( bejegyzés statikus objektumra utal. Alapesetben ezt használjuk. A CollideObject ( bejegyzés olyan statikus objektumra utal, amelybe a vonat beleütközhet. Ehhez természetesen az .SD fájlban az ESD_Bounding_Box ( bejegyzésnek kikell töltve lennie. A LevelCr ( bejegyzés sorompó objektumra utal. A Hazard ( bejegyzés „mászkálókra” utal. A Transfer ( bejegyzés talajtextúra objektumra utal. A Pickup ( bejegyzés a vételező hely objektumra utal. A Siding ( bejegyzés a vágány megnevezésére szolgáló beépített objektumra utal. A Platform ( bejegyzés a peron megnevezésére szolgáló beépített objektumra utal. A CarSpawner ( bejegyzés az utakra telepíthető autóforgalom megadására szolgáló beépített objek-tumra utal. A Dyntrack ( bejegyzés a beépített dinamikus vágányra utal.

Ezek közül a utóbbi négynek csak egyszer kell szerepelnie a .REF fájlban, és módosítani sem sokat lehet (szabad) rajtuk. Ezen bejegyzéseken belüli bejegyzések szinte minden objektumtípusnál azonosak: -

-

-

A Class ( bejegyzésben azt a nevet adhatjuk meg, amelyik csoportba az adott objektum kerül. Érdemes – lehetőleg nem túl sok – csoportba besorolni az objektumokat, hogy könnyebben megtalálhassuk őket a pályaépítés folyamán. Ha a csoport neve szóközt tartalmaz, mindenképpen „” jelek közé írjuk! A Filename ( bejegyzésben a shape fájl nevét tudjuk megadni. Kivételek: o Hazard: a .HAZ fájl nevét kell megadni o Dyntrack: a DYNTRACK szó kell, hogy ott szerepeljen o Platform, Siding, CarSpawner esetén nincs ilyen bejegyzés o Transfer: a textúra (.ACE) nevét kell megadni A Description ( bejegyzésben a listában megjelenő nevet adhatjuk meg. Ez minden elemnél szabadon változtatható. Ha a név szóközt tartalmaz, mindenképpen „” jelek közé írjuk! Az Align ( bejegyzés nem tudom mire való. J A neve alapján igazítás lenne, de hogy mit és mihez igazít, nem sikerült rájönnöm. A Shadow ( bejegyzésben az árnyék típusát tudjuk megadni. Itt azokat a beállításokat lehet megadni, amit a Route Editorban is. Előnye, hogy ettől fogva a beillesztéskor ez lesz az alapértelmezett árnyék. Lehetséges állapotai: None, Rect, Round, Dynamic. A StoreMatrix () üres bejegyzés szintén nem tudom mire való. Ez a bejegyzés csak a Siding, Platform, és CarSpawner objektumoknál fordul elő. Szerintem ne piszkáljuk. A PickupType ( bejegyzésben a Pickup objektum típusát adhatjuk meg. Lehetséges állapotai: _FUEL_DIESEL, _FUEL_COAL, _FUEL_WATER. Bővebb részletezés még kisérletezést kíván. Ez a téma sok érdekességet kínál, így a későbbiekben visszatérek még rá. (Zárójelben jegyezném meg, hogy az ehhez a funkcióhoz kapcsolódó, a .WAG fájlban szereplő IntakePoint ( bejegyzésnél az egyik leírás szerint más lehetséges értékek is szerepelnek, úgy mint: FreightGrain, FreightCoal, FreightGravel, FreightSand, SpecialMail is!) Az Anim ( ) bejegyzés az animáció alapra bekapcsolt állapotát jelöli. Ezt – mint a többi tulajdonságot is – a Route Editorban lehet ki-/bekapcsolni.

A .REF fájl szerkesztése lehetséges átlátható táblázatos formában is a Route Riter programmal.

21

3. A pályaobjektumok beállításai 3.1. Speciális pályaobjektumok A statikus objektumok beállítást nem igényelnek, a .REF fájlba történő bejegyzés után szabadon használhatók pályaépítésre. A további beállítást igénylő objektumok az előző fejezetben felsorolt speciális objektumok. Ezen fejezetben az ezekhez kapcsolódó, Route Editoron kívüli beállításokat írom le. (A Route Editoron belüli beállításokkal Ptrmarci pályaépítési leírása foglalkozik. http://marci.triak.hu) Az alább megnevezett fájlok mind a pálya könyvtárában találhatóak. Jelzők (Signal) – SIGCFG.DAT és SIGSCR.DAT fájlok A jelzők beállítása igen sokrétű, bonyolult rendszerű művelet, így erről később egy külön fejezetben, vagy egy külön dokumentumban írnék. „Mászkálók” (Hazard) – DEER.HAZ és SPOTTER.HAZ fájlok A Hazard objektumoknak két fajtája van: ember (People) és állat (Animals). Az első a SPOTTER.HAZ a második a DEER.HAZ fájlban programozható. Elvileg ezeknek más név is megadható, és valószínűleg (bár ez közel sem biztos) több mint két fajta Hazard objektum is telepíthető a pályára. (A REF fájlba bejegyzés megengedett, viszont az Activity Editor beállításai között csak ez a két típus szerepel.) A .HAZ fájl bejegyzései: - Tr_Worldfile ( bejegyzés foglalja magába az összes többit. - A FileName ( bejegyzés a shape fájl nevét mutatja meg. Ennek vagy a pálya Shapes könyvtárában, vagy a Global\Shapes könyvtárban kell lennie. - A Workers ( bejegyzésben egy másik shape fájl adható meg. Amennyiben egy activityben úgy jelölünk ki egy ideiglenes lassan bejárandó pályarészt (temporary reduced speed zone), hogy a pályára elhelyezett Hazard objektum ezen szakaszon belülre esik, úgy nem az első, hanem ez az objektum fog megjelenni a játékban. - A Distance ( bejegyzésben szereplő szám azt a távolságot adja meg méterben, amekkora távolságra a Hazard objektum elmozdul aktivizálódása után. - A Speed ( bejegyzésben a „mászkáló” aktivizálódás utáni haladási sebessége adható meg m/s mértékegységben. - Az Idle_Key ( ill. Idle_Key2 ( bejegyzésben az alapmozgás animációjának kezdő- és végkockája adható meg. Ezt a shape fájl elkészítésekor kell meghatározni. A két beállított animáció véletlenszerűen váltakozva játszódik le. - A Surprise_Key_Left ( és Surprise_Key_Right ( bejegyzésben a minimális távolságnál lejátszódó animáció kezdő- és végkockája adható meg. Ezt a shape fájl elkészítésekor kell meghatározni. Az egyik a jobbról, a másik a balról érkező vonat esetén indul el. - A Success_Scarper_Key ( bejegyzésben a Hazardhoz 160 méternél közelebb érkező illetve a 200 méteren belül kürtölő vonat hatására aktivizált Hazard animációjának kezdő- és végkockája adható meg. Ezt a shape fájl elkészítésekor kell meghatározni. Autóforgalom (Car spawner) – CARSPAWN.DAT fájl A CARSPAWN.DAT fájlban a Route Editorban telepített útvonalon közlekedő autókat tudjuk megadni, a shape fájljaik felsorolásával. Fontos, hogy a bejegyzéssorozat a bejegyzéssorok számával kezdődjön. Minden sorba a CarSpawnerItem ( bejegyzés kerül, idézőjelben („”) az autó shapefájljának neve, majd egy számérték, mely a sorompónál felsorakozó autók egymástól való távolságával arányos (nem a köztük lévő távolságot jelenti!). Minden sor végére bezáró zárójel kerül, majd a legutolsó sor után még egy. A TS hibája, hogy az utolsó autó sosem jelenik meg a pályán, így oda érdemes egy másolatot készíteni valamelyik sorról. Sebességkorlátozók (Speedpost) – SPEEDPOST.DAT fájl A bejegyzések a Speedpost_Set ( bejegyzésen belül találhatók. Ebből elvileg több is létezhet különböző neveken, de ekkor a Route Editor kilépéskor lefagy, levelezni akar. Az alábbi bejegyzések adhatók meg:

22

-

-

-

A Name ( bejegyzésben a neve adható meg. Ez mint jelző jelenik meg a Route Editor listájában a Speed Sign (lassan bejárandó pályarész eleje), Speed Warning Sign (előjelzés lassan bejárandó pályarészre), Speed Resume Sign (lassan bejárandó pályarész vége) előtt. A Speed_Sign_Shape ( bejegyzésben a – lassan bejárandó pályarész eleje – tábla shape fájljának neve, majd a feliratok darabszáma után a beillesztendő szöveg beillesztési koordinátái adhatók meg az objektum PIVOT pontjához képest, három szám formájában. Az utolsó érték az elforgatás szögének meghatározására szolgál. Amennyiben több felirat kerül a tárgyra, úgy minden felirathoz tartozik 4 szám (3 db helypozíció és egy forgatás). A Speed_Warning_Sign_Shape ( bejegyzésben a – lassan bejárandó pályarész előjelzője – tábla adható meg a fentiekhez hasonló formában (lásd: Speed_Sign_Shape). A Speed_Resume_Sign_Shape ( bejegyzésben a – lassan bejárandó pályarész vége – tábla adható meg a fentiekhez hasonló formában (lásd: Speed_Sign_Shape) A Speed_Digit_Tex ( bejegyzésben az a textúra adható meg, amelynek részeit, mint számjegyeket használ a TS a lassan bejárandó pályarész sebességének kiírásához. Ez a textúra képzeletben 4x4 részre van osztva. A bal felső sarokból indulva jobbra a részek jelentései: az első sorban a számok 0-3-ig, a másodikban 4-7-ig, a harmadikban 8, 9, a személy és tehervonatokra vonatkozó előjelek, majd az utolsó sorban a tizedespont szerepel. A Speed_Text_Size ( bejegyzésben a sebességjelzés számainak mérete adható meg. Az első szám a méret értéke, a második és harmadik, pedig a vizszintes és függőleges betütávolság értéke. A Restricted_Shape ( bejegyzésben az Activity Editorban bejelölhető ideiglenes lassan bejárandó pályarész kezdő táblája adható meg a fentiekhez hasonló formában (lásd: Speed_Sign_Shape). Az End_Restricted_Shape ( bejegyzésben az Activity Editorban bejelölhető ideiglenes lassan bejárandó pályarész vége táblája adható meg a fentiekhez hasonló formában (lásd: Speed_Sign_Shape). A Milepost_Shape ( bejegyzésben a szelvényezést jelző tábla (kilométer kő) adható meg a fentiekhez hasonló formában (lásd: Speed_Sign_Shape). A Milepost_Digit_Tex ( bejegyzésben az a textúra adható meg, amelynek részeit, mint számjegyeket használ a TS a szelvényezés kiírásához. Ez a textúra ugyanolyan felépítésű, mint a Speed_Digit_Tex ( bejegyzésben hivatkozott textúra. A Milepost_Text_Size ( bejegyzésben a szelvényezés számainak mérete adható meg. Az első szám a méret értéke, a második és harmadik, pedig a vizszintes és függőleges betütávolság értéke.

Felsővezetéktartó objektumok (Gantry) – GANTRY.DAT fájl A bejegyzések a Tr_GantryFile ( bejegyzésben szerepelnek. (Ne felejtsük a végén a bezáró zárójelet kitenni.) Ezen belül található a GantrySets ( bejegyzés, melyben elsőkét a GantrySet ( bejegyzések számát kell megadni. Ezután történik a GantrySet ( bejegyzésben az egyes beállítások megadása: -

-

A Name ( bejegyzésben a neve adható meg, szóköz használata esetén mindenképpen tegyük ki az idézőjeleket („”). A Style ( bejegyzésben a stílusa adható meg. A 00000001 a vágány szélére egymással szembefordítva telepített objektumokat, míg a 00000002 a vágány(ok) közepére elhelyezett objektumokat jelenti. A Separation ( bejegyzésben a lehelyezési távolságot kell meghatározni. Ezután lehet meghatározni, hogy adott vágányszélesség (értsd: a párhuzamosan futó, egymástól nagyon el nem távolodó vágányoknál a két szélső vágány külső széle közti távolság) esetén milyen objektum kerüljön lehelyezésre. Ez elsősorban a 2-es típus esetén érdekes, ott ugyanis például egy keresztgerendás felsővezetéktartó esetén nem mindegy, hogy milyen hosszúságú keresztgerendás shape kerül lehelyezésre. A GantryTable ( bejegyzés után a GantryTableEntry ( bejegyzések számát, majd magukat a GantryTableEntry ( bejegyzéseket kell elhelyezni. A GantryTableEntry ( bejegyzésbe először a Filename ( kerül, ahol a shape fájl nevét kell megadni (lehetőleg idézőjelben), majd a Distance ( bejegyzésben azt a szélességet, amely alatt ez a shape kerüljön lehelyezésre.

Erdők (Forest) – FORESTS.DAT fájl A CARSPAWN.DAT fájlhoz hasonlóan itt is először a Forest ( bejegyzések számát kell megadni. Ezután következnek az egyes Forest ( bejegyzések, ahol először a nevét (ez jelenik majd meg a Route Editor listájában mint Forest - ), majd a használandó textúra nevét kell magadni. Ezek után jön a magassági majd szélességi értékek megadása. A következő két szám valamiféle különbségi tényező szerepét tölti be: ennyivel lesznek véletlenszerűen másabbak a méretek az előzőleg megadott méretekhez képest. Mind a négy szám mögé „f” betüt kell írni (talán mint mértékegységet?).

23

Hangforrás (Sound Source) – SSOURCE.DAT fájl Ez a fájl a hangforrások neveinek és a nevekhez tartozó .SMS fájlok felsorolására szolgál. Itt csupán a Sound ( bejegyzések szerepelnek, melyeken belül található egy Name ( bejegyzés, melybe a hangforrás listában megjelenő nevét kell írni idézőjelekbe („”), illetve egy Filename ( bejegyzés melybe az .SMS fájl nevét kell beírni, szintén idézőjelekbe. Itt kivételesen nem kell megadni a Sound ( bejegyzések számát. Pálya menethang (Sound Region) – TTYPE.DAT fájl A pályamenti menethangok megadása történik itt. Először az összes TrackType ( bejegyzés számát kell megadni. Ezután történik a TrackType ( bejegyzések felsorolása. Itt kell megjegyezni, hogy ez esetben nagyon fontos szerepe van a sorrendiségnek is! A hivatkozott .SMS fájlokban ugyanis meg kell adni majd a TrackType-ok értékét is, ami tulajdonképpen ebben a listában lévő pozícióját adja meg az .SMS fájlnak. Ha ez a két dolog (a pozíció a TTYPE.DAT-ban és a megadása az .SMS fájlban) nem egyezik meg, nem fog megszólalni a hang. Az első sorban szereplő .SMS fájlba a 0 értéket, a második sorban lévőbe az 1-es értéket, stb. kell megadni! A TrackType ( bejegyzésbe három szöveges értéket kell beírni: - A menethang nevét; ez jelenik majd meg a Route Editor listájában, mint név. - A bent (beállítástól függően – vezetőfülkében, utasnézetben) hallható .SMS fájl nevét. - A kint (beállítástól függően – külső nézetben) hallható .SMS fájl nevét. Ez utóbbit még nem sikerült soha megszólaltatni, feltehetően a TS hibájából. Ezeket az .SMS fájlokat a TS először a Global\Sound könyvtárban keresi. Amennyiben a pálya Sound könyvtárába tesszük őket, érdemes ezt megadni a fájl neve előtt: „../../Routes/pályaneve/Sound/akármi.sms”. Távíró pózna (Telepole) – TELEPOLE.DAT A TPoleConfigData ( bejegyzésben a TPoleConfig ( bejegyzések számát kell megadni. (Én egynél többet még nem láttam, és csak tippem van, hogyan lehetne többet beilleszteni belőlük egy pályára.) A TpoleConfig ( bejegyzésen belül az alábbi bejegyzéseket tehetjük meg: - A Filename ( bejegyzésben a shape fájl nevét adhatjuk meg. - A Shadow ( bejegyzésben egy külön objektumot adhatunk meg árnyéknak (!). Ez teljesen úgy viselkedik, mint az árnyék, vagyis forog a Nappal, és nyúlik is a Nap állásának megfelelően. Bár nagyon egyszerű, de speciális objektumnak tűnik. Megérne néhány óra kutakodást. A TS-hez mellékelt eredeti objektum neve teleshad.s. - A Separation ( bejegyzésben a beillesztési távolságokat adhatjuk meg. - A Wire ( bejegyzésben pedig elvileg az elemek közé behúzandó – kábelt jelképező – vonal helyét adhatjuk meg, akár több Wire ( bejegyzést is tehetünk. Nekem sajnos ezeket a kábeleket még nem sikerült előcsalogatnom. 3.2. Sín- és útelemek beállításai A sín- és útelemek beillesztése nem egyszerű dolog a TS-be. Saját sín- és útelemek építése csak a megszállottak-nak javasolt, az is csak akkor, ha teljesen speciális elemekre van szükségük! A beillesztéshez a Global könyvtár tsection.dat fájljának módosítására van szükség. Állj! Mielőtt bárki is nekiesne, tudnia kell bizonyos dolgokról. A tsection.dat fájl módosítása a különböző pályák tönkretételével járhat! A tsection.dat fájlban minden egyes sín- illetve útelem shape fájljához rendelünk egy számot. Ezek alapján a számok alapján van nyilvántartva az egyes pályákon, hogy milyen elemekből épülnek fel. Amennyiben mi ezeket a hivatkozási számokat megváltoztatjuk a tsection.dat fájlban, úgy más pályák összeomolhatnak, mivel majd nem találják, illetve más elem jelenik meg az egyes hivatkozási számok helyén. Jó, erre lehetne mondani azt is, hogy majd új számok helyére illesszük be az új elemeket. Igen ám, de akkor később történhet baj, ugyanis a tsection.dat fájlt folyamatosan frissítik. Akinek mégis ilyen célú ambíciói lennének, a következőket tudom ajánlani: - Először is, készítse el az elemeket. Érdemes nem 1-2 darabot csinálni, hanem akár többet is, egész készletet. - Vegye fel a kapcsolatot Steven Masters-szal ([email protected]). Ő vette ugyanis vállára a tsection.dat fájl karbantartását. Vele kell megbeszélni, tőle kell kérni, hogy integrálja az új pályaelemeket a következő tsection.dat verzióba, tőle kell „kérni” olyan helyszámokat, melyek még nem használatosak, és más sem gyártja új elemeit ezekre a helyekre. Ezután – például – a következő XTracks kiadásakor megjelenő legújabb tsection.dat fájlban már benne lesznek a saját elemeinkre a hivatkozási számok. A tsection.dat verzióját az első megjegyzés sora ( _INFO ( ) mutatja „Build <ötjegyű szám>” formában. A legfrissebb verzió a fent említett honlapon megtalálható.

24

A TSECTION.DAT bejegyzései a következők: -

-

-

Az _INFO ( vagy _Skip ( bejegyzésekben információs, szöveges adatok szerepelnek. A TrackSections ( bejegyzésen belül szerepelnek az elemek méreteinek megadása. Először a bejegyzések száma szerepel, majd a TrackSection ( bejegyzések. A TrackSection ( bejegyzésen belül vannak az egyes elemek méretei. A bejegyzés után álló szám a bejegyzés sorszáma. A SectionSize ( bejegyzésben az elem méretei szerepelnek: az első szám a nyomtáv, míg a második a hossza egyenes elem esetén (íves elem esetén a hossz nulla). A SectionCurve ( bejegyzésben az íves elem méretét adhatjuk meg: az első szám az ívsugár méterben, a második a szöge fokban. A TrackShapes ( bejegyzésben a TrackShape ( bejegyzések sora található, ahol az egyes geometriai méretekhez történik a shape fájlok hozzárendelése. A TrackShapes ( bejegyzés után a TrackShape ( bejegyzések száma szerepel. A TrackShape ( bejegyzésben az egyes elemek definiciója van megadva. Az első szám az adott shape hivatkozási száma. A Filename ( bejegyzésben a shape fájl neve van megadva. A NumPaths ( bejegyzésben a lehetséges útvonalak száma van megadva. (Pl.: kétvágányú pályán ez 2.) A MainRoute ( bejegyzésben az elsődleges útvonal hivatkozási száma van megadva. A CleareanceDist ( bejegyzés a foglaltságérzékelésnél a foglaltságérzékelés távolságát adja meg. Elsősorban váltóknál fontos a nem használt irányban. (A nyomvonal egy pontban válik szét, de a vágányok egy darabig egymásba fonódva, illetve egymáshoz közel futnak. Ha itt vonat állna, ütközés történne, ezért a megadott távolságig, ott is figyeli a foglaltságot.) A SectionIdx ( bejegyzésekben bal oldalitól kiindulva jobbra történik egy-egy útvonal leírása, amely az adott shapehez tartozik. A SectionIdx ( bejegyzésen belül először a felhasználandó TrackSection-számok darabszámát, majd a shape PIVOT pontjától való eltolás (x, y, z), majd pedig az esetleges elforgatás értékét kell megadni, ezután pedig felsorolni a TrackSections ( részben beállított méretek hivatkozási számát sorban egymás után. A TunnelShape ( ) bejegyzés alagút objektumra utal. A RoadShape ( ) bejegyzés útobjektumra utal. Az XoverPt ( bejegyzés az egymást keresztező nyomvonalak keresztezési pontja a PIVOT ponttól számítva. A ManualJunctionShape ( ) bejegyzés a kézzel állítható váltóra utal. (Activitykben van jeletősége.)

Akinek túl macerás a fenti eljárás (kapcsolatfelvétel Steven Masters-szal), vagy csak néhány, nem annyira speciális sínés útelemre van szüksége, annak a következő módszer is segíthet: -

-

A módszer lényege, hogy egy meglévő sínelem helyére illesztünk másikat a kész pályán. A kiválasztott, kicserélendő elemnek megfelelő méretű új objektumot kell ilyenkor legyártanunk, hogy az pontosan illeszkedjen a régi helyébe. Tulajdonképpen a TS geometriai, logikai sínfelépítését nem piszkáljuk, csupán az elem megjelenését változtatjuk meg. Fontos, hogy az új elem PIVOT pontja megegyezzen a régi elemével. A régi elem helypozícióját gondosan feljegyezzük, majd a megfelelő tile World (.W) fájljában megkeressük a helypozíció alapján a kiválasztott elemet. Ezután a megkeresett sín-(vagy út-)elemnél a Filename ( bejegyzésben átírjuk a shape fájl nevét az általunk készítettre. Ekkor az új shape-et a Global\Shapes könyvtárba kellene másolnunk. Viszont, hogy elkerüljük a Global\Shapes könyvtár „elszemetesedését”, mivel csak ez az egy pálya használja majd ezt a shape fájlt, inkább másoljuk a pálya Shapes könyvtárába, és a Filename ( bejegyzésbe írjunk elérési utat a következő módon: „../../Routes/pályaneve/Shapes/shapeneve.s”

Ez ugyan sok elem esetén szöszmötölős módszer, de megfelelő gondosság mellett ugyanaz az eredmény érhető el vele, mint a fenti módszerrel, mégis elkerüljük a hosszabbtávú levelezés és kiadás fáradalmait.

FIGYELEM! A TSECTION.DAT módosítása nem ajánlott olyanok számára, akik nem rendelkeznek kellő tapasztalattal! Csak és kizárólag saját felelősségre, és lehetőleg NEM a TSECTION.DAT fájl új generációját elindítva építs pályát! Sok ember sok munkája fekszik az EGYSÉGES TSECTION.DAT létrehozásában! Az új elemek létrehozása nem tiltott, csak az egységesítés és a problémák elkerülése érdekében megszabott eljárás lefolytatásához kötött!

25

4. Sínen mozgó objektumok A sínen mozgó objektumok – a járművek működtetéséhez speciális kiegészítő adatok is szükségesek, melyek a szimuláció során „életet” adnak a járműnek. Ezek az adatok a .WAG és .ENG fájlokban vannak leírva (lásd 5. fejezet). Emellett a helyes működéshez a shape fájl kialakításának is vannak követelményei. Ezeket sorolnám fel az alábbiakban: - Ahhoz, hogy a kerekek forogjanak a kerekeket el kell választani a mozdonytól és legalább tengelyenként egyegy WHEELS<szám> nevű részobjektumba kell őket sorolni. Figyelni kell a PIVOT pont megfelelő beállítására, mert ennek egyik tengelye lesz a forgáspont. A WHEELS részobjektum mozdonyok hűtőventillátorának animálására is felhasználható. - A forgóvázak elfordulásához, azokat le kell választani a mozdonytól és mint alárendelt BOGIE<szám> részobjektumot kell belőle létrehozni. A PIVOT pont a forgóváz forgási pontja lesz. A kerekek a forgóváz alárendelt részobjektumai kell, hogy legyenek, hiszen csak így tudnak a forgóvázzal együtt elfordulni. - Lehetőség van áramszedő animációjára, mely a P gomb egyszeri megnyomására a másik állapotba, majd újbóli megnyomására az alapállapotba kerül a játék során. Ehhez az áramszedő karjait PANTOGRAPTOP<szám>, PANTOGRAPMID<szám>, és PANTOGRAPBOTTOM<szám> névvel kell elnevezni, és a megfelelő alárendeltségi viszonyban részobjektumozni. Ez a módszer más animációk (pl.: ajtónyitás) kialakítására is jó (persze csak feltételekkel: csak villamos járműnél, ill. a művelet együtt jár a jármű „kikapcsolásával”). - Amennyiben a jármű csatlórudakkal, illetve gőzmozdony esetén rudazattal rendelkezik, úgy azokat az elemeket is külön-külön, ROD<szám> elnevezéssel alárendelt részobjektumokká kell alakítani. - A járműre ki-/be kapcsolható alternáló mozgást végző animáció kerülhet, amelyet leginkább az ablaktörlő megformálására használnak fel. Az ablaktörlő nyelét WIPERARMLEFT<szám> ill. WIPERARMRIGHT<szám>, a törlő lapátot WIPERBLADELEFT<szám> ill. WIPERBLADERIGHT <szám> elnevezésű alárendelt részobjektumnak kell beállítani. Az így kialakított jármű alapszükséglete a későbbi beállítások helyes működésének.

5. A járművek beállításai A következő részben nem egy teljes részletességű, mindenre kiterjedő leírást lehet majd olvasni. A célom elsősorban a legfontosabb beállítások leírása, azoknál is néhány tévhit eloszlatása, illetve véleménykifejtés. A nagy szakértők biztos jót vitatkoznak majd velem ezen a fejezeten. A lent leírtak részben saját tapasztalatok, részben más szerzők írásainak (lásd: Felhasznált irodalom) lefordítása alapján íródtak. 5.1. A vontatott jármű (.WAG) A .WAG fájl a nem mozdonyként üzemelő, saját vonóerővel nem rendelkező járművek, a kocsik adatait tartalmazza. A legfontosabb bejegyzések a .WAG fájlokban: -

Minden .WAG (és .ENG) fájl Wagon ( bejegyzéssel kezdődik (eltekintve a TS-ben szokásos SIMISA... sortól), mely után a jármű TS-beli hivatkozási neve áll. Ez nem az a név, amely az Activity Editorban a szerelvény összeállításánál megjelenik. Ezt a nevet, a Consist (.CON) fájlokban lehet megtalálni, mint hivatkozást egy járműre, illetve az .ENG fájlokban lesz jelentősége (lásd később).

-

Minden járművet kategóriába kell sorolni. Ezt a Type ( bejegyzésnél lehet megtenni. Lehetséges változatai: o Mozdony esetében: Engine o Teherkocsi esetében: Freight o Személykocsi esetében: Carriage o Gőzmozdony szerkocsi esetében: Tender o És – mint nem dokumentált elem – hajtány, kisgép: Draisine Ezeket a neveket használja a kategorizáláshoz az Activity Editor és a ConBuilder program is.

-

A jármű neve a Name ( bejegyzésben adható meg, kettős macskakörmök között, lehetőleg hosszú Ő és Ű betű nélkül. Ez a név fog a játékban (AE. CB is) megjelenni.

-

A WagonShape ( bejegyzés szolgál a jármű shape fájljának megadására.

-

A következő a már korábban is (ESD_Bounding_Box esetén) említett Size ( bejegyzés. Itt a kocsi méreteit kell megadni, szélesség, magasság, hossz sorrendben, méter mértékegységgel.

-

Az előzőhöz hasonló, de attól némileg eltérő jelentésű az InertiaTensor ( bejegyzés jelentése. Míg a Size ( a kocsik egymástól való távolságát adja meg, addig az InertiaTensor ( némiképp az .SD fájl

26

ESD_Bounding_Box ( bejegyzésére hasonlít. Egyes források szerint érdemes az InertiaTensor ( és az ESD_Bounding_Box ( hosszméret értékeit 5-10 cm-rel kisebbre venni, mint a Size ( hosszméret értéke – a kocsik könnyebb összekapcsolódása érdekében. Ez javítja a mozdony elejével való kapcsolódást is. A Size ( hosszértéke soha ne legyen kisebb, mint a másik két bejegyyzésben szereplő hosszérték! (lásd .SD fájl) -

A Mass ( bejegyzésben a jármű tömege adható meg tonna mértékegységben. Egy shape fájlhoz érdemes több .WAG fájlt is készíteni, hiszen például egy teherkocsi is lehet üres (~20-30t) vagy rakott (~60-80t).

-

A WheelRadius ( bejegyzésben a kerék méreteit lehet megadni, pontosabban a sugarát, méter mértékegységben (számunkra talán ez megfelelőbb, mint az inch).

-

Létezik egy nem dokumentált Thumbnail ( bejegyzés is, ahol a TS átal használt kis infókép nevét lehet megadni. Alapvetően ez a loco.ace fájl. (Ezzel például a VMW „sok mozdony egy könyvtárban” elvű rendszerében megoldható minden mozdonyhoz külön kép csatolása.)

-

A következő, a Coupling ( , egy nagyobb bejegyzés, több bejegyzés is tartozik alá. Ezen belül lehet megadni a kapcsolókészülék tulajdonságait. o A Type ( bejegyzésben a típusát. Lehet Chain (azaz csavarkapocs), Automatic (azaz központi ütközővonó készülék), vagy Bar (azaz fix kapcsolat). Nálunk érdemes a Chain teljeskörű használata (eltekintve néhány motorkocsitól), mivel a különböző kapcsolókészülékű járművek egymással nem képesek kapcsolódni. Egy járműnél két kapcsolókészülék típus is megadható, az első lesz a hátsó, a második az első kapcsolókészülék. o A Spring ( bejegyzésen belül a rugó beállításait lehet megadni: § Stiffness ( – rugóellenállás – mértékegysége N/m § Damping (– csillapítás ? – mértékegysége N/m/s (és nem N/m, ahogy az az eredeti TS járműveknél szerepel!!!) § Break ( – törés, szakadás – mértékegysége N (Newton) § r0 (– a rugó nyúlási hossza – mértékegysége m (méter, de elképzelhető, hogy a cm is használható) A Stifness, Damping, Break bejegyzéseknél nem szabad második értéknek nullát (0) használni, mert problémákat okozhat, jobb, ha az első paramétert írjuk a második helyre is. A fenti esetekben a <szám>e<szám> formátumú számmegadás nem egészet, törtalakot jelent, hanem exponenciális tényezős megadást. Azaz: 5e6N = 5x106 N =5000000N =5000kN! o A Velocity ( bejegyzés arra a maximális sebességkülönbségre utal, amelynél a kocsik még összekapcsolódnak. Mértékegysége m/s. o A CouplingHasRigidConnection ( 1 ) bejegyzéssel a rugó „nemlétét”, a kapcsolat merev voltát fejezhetjük ki. Ismert hibák, melyeket nem lehet kijavítani: o A mozdony első kapcsolókészüléke nehezen kapcsolódik. o A mozdony elejére kapcsolt kocsikat nehezebb elvontatni a nagyobb ellenálás miatt (a fék nem, vagy csak részben old fel?) A fenti értékekre nem hiszem, hogy akad képlet, mellyel könnyedén kiszámíthatók, mindenképpen érdemes tapasztalati úton meghatározni őket. A Break tényezőt főként azért nehéz megállapítani, mert ha túl kicsire vesszük, akkor egy MSTS hiba miatt könnyedén, indokolatlanul szétszakadhat a vonat. Ez a hiba a váltók közti túl nagy (8-10 km-nél is több) távolság. Ilyenkor a szerelvény a túlsó, másodikként érintett váltónál – valamiféle helypozíciós számítás korigálása képpen – nagyot rándul, minek hatására a kis törési erőre – helyesen – beállított kapcsolókészülék elszakad. Ez a hiba csak a pályaszakaszok hibatűrő megépítésével javítható, akár utólagosan is: két egymással szembefordított A1tPnt1m.s váltóval „láthatatlan” váltó illeszthető a túl hosszú szakasz közepébe. A két váltó ilyen módon beépítése váltóállítást nem igényel, kisiklást nem okoz. Amennyiban a kapcsolókészülék törési erejét túl nagyra vesszük, nem lesz reális a kocsik viselkedése, például a siklott kocsik nem akarják elengedni egymást.

-

A Buffers ( bejegyzés az ütközőkre vonatkozna, amennyiben működőképes lenne, de ez a beállítás hatástalan.

-

Az Adhesion ( bejegyzés a tapadási tényezőkre vonatkozik, nem érdemes piszkálni, a beállított ( 0.2 0.4 2 0 ) értékek tökéletesen megfelelnek.

-

A DerailRailHeight ( értéke feletti pályahiba esetén kisiklik a vonat (amennyiben a TS opciói között a Derailment be van jelölve!). Értéke 4 cm, bár egyes források szerint jobb ha 10 cm-re vesszük. Mindez csak a használt pálya megépítésének minőségétől függ.

27

-

A DerailRailForce ( azt az (oldaliráyú) erőt jelenti, melynek hatására a jármű elhagyja a pályát. Ezzel az erővel határozható meg a jármű ívben haladásakor a kisiklás határa. Különböző források szerint ez az érték 2.5kN tonnánként. Az alkalmazása viszont elég sok helyen szerintem hamis. A bejegyzéseknél ugyanis pl.: ( 2.5*100t ) szerepel, amit szerintem a TS nem tud értelmezni, hiszen a mértékegység nem tonna, hanem Newton (vagy kN). Vagyis érdemesebb kiszámolni: 250kN. Egyesek szerint ez kis érték, szerintem, még talán sok is (én a 2x-es szorzót használom). Mindenesetre csak olyan pályákon használható, melyek a pályaívek és a megengedett sebesség tekintetében a valóságos értékekhez közelítenek. Az alappályák egyike sem, de sok más egyéb pálya sem tartozik ezek közé. Siklás csak úgy következik be, amennyiben a TS opciói között a Derailment be van jelölve! (Egy írás szerint ez az opció csak a megengedett pályasebesség túllépése esetén kapcsolódik be, és csak akkor történik siklás. ???)

-

A DerailBufferForce ( a ütközőkre ható erő esetén mondja meg a siklási határértéket. Bizonyos források szerint ez a jármű tömege kN-ban (ha úgy tetszik: tizes szorzó), azaz egy 80t-s jármű esetén 800kN. Ez szerintem megint sok egy kicsit (az 5x-ös szorzó híve vagyok), de ez már ízlés kérdése. Siklás csak úgy következik be, amennyiben a TS opciói között a Derailment be van jelölve!

-

A NumWheels ( bejegyzés a .WAG fájlban egyszer, míg az .ENG fájlokban kétszer szerepel. Itt most a Waggon ( bejegyzésen belüliről lesz szó. Ez az érték elvileg a kerekek számát határozná meg. A vélemények viszont nem egyezőek: egyes források szerint semmi hatása nincs ennek a bejegyzésnek, mások szerint a kocsi fékerejének számításakor, mint szorzó szerepel. Megint mások szerint a mozdony végsebességét határozza meg. Személy szerint nem tapasztaltam befolyásoló hatást.

-

A Friction ( bejegyzés a jármű menetellenállási tényezőit mondja meg. Ezek a tényezők határozzák meg egy guruló kocsi mindenféle (súrlódási-, gördülési-, ívben haladási-, lég-, csapágysúrlódási-) ellenállásból való lassulását. Kiszámítása a Friction Calculator nevű programmal lehetséges. A bejegyzésen belül 10 számjegy található. Az első öt az alapellenállások, a második öt az ívellenállások kiszámítására alkalmas, illetve ez utóbbi csak lenne, mivel ezekkel a TS nem számol (egyes források szerint). Csak csendben jegyezném meg, hogy a második (0), harmadik (1 mph) és ötödik (1.8) tényező zárójelben megadott értéke kis hibával elfogadható minden kocsihoz. Az első érték a tömeg 15-30-szorosa N/m/s-ban, a negyedik pedig egy a kocsifajtától függő érték 1 és 4 N/m/s között. Természetesen ezek csak nagyjábóli határértékek, pontos értéket a képletek, illetve a FrictionCalculator ad.

-

A BrakeEquipmentType ( és a BrakeSystemType ( a fék rendszerét adja meg. Ez mindenképpen azonos legyen az egyszerre használt járművek esetében, mivel csak így bizosítható, hogy a mozdony fel tudja oldani a vonat fékjét, és el tudja vontatni a kocsikat. A BrakeEquipmentType ( általam használt (lásd Bakony Edition) értéke ("Handbrake, Graduate_release_Triple_valve, Auxilary_reservoir"), a BrakeSystemType ( -é ("Air_single_pipe").

-

A MaxBrakeForce ( bejegyzés értéke van legnagyobb hatással a járművek fékezésére. Mértékegysége kN. Az érték nagyságában itt sincs teljes egyetértés. A Kuju szerint 10-16%-a a jármű tömegének, más források szerint az 5-10% is elegendő. Tehát egy 80 tonnás jármű esetében ~60-80-100 kN járműtípustól függően.

-

A MaxHandBrakeForce ( a kézifék erejének nagyságát adja meg, értéke jóval kisebb a MaxBrakeForce-énál.

-

A TripleValveRatio ( a fékrudazat áttételének (?) arányát adja meg. A 2.5-ös érték megfelelőnek tűnik.

-

A MaxRelaseRate( a fék oldásának sebességét adja meg psi/s mértékegységet értve rajta. A Kuju szerinti alapbeállítás (20) nagyon nagy érték, a valóságban a fékek sokkal lassabban oldódnak. A valósághű érték 0.5 és 2 között mozoghat.

-

A MaxAplicationRate( a fék oldásának sebességét adja meg psi/s mértékegységet értve rajta. A Kuju szerinti alapbeállítás (20) naagyon nagy érték, a valóságban a fékek sokkal lassabban oldódnak. A valósághű érték 1 és 4 között mozoghat.

-

A BrakeCylinderPressureForMaxBrakeBrakeForce( a maximális fékerőhöz tartozó levegőnyomást adja meg. Ez hazai viszonyok között ~50 psi.

-

A Sound ( bejegyzés a jármű hangzását meghatározó .SMS fájl nevét (és helyét!!!) adja meg. Amennyiben nem adunk meg könyvtárat, úgy a jármű Trainset könyvtáron belüli könyvtárában található Sound könyvtárban

28

keresi az .SMS fájlt. Amennyiben az .SMS fájl másik könyvtárban található, úgy a következő formában adjuk meg az elérési utat: Pl.: Sound ( "..\\..\\MAV_Hangok\\nehez\\nehez.sms" ) Ilyen esetben ügyeljünk arra, hogy ettől még az .SMS fájlban található hangfájlokat ugyanúgy a jármű Trainset könyvtáron belüli könyvtárában található Sound könyvtárban keresi a TS, ezért az .SMS fájl módosítása is ajánlott. -

Nagyon fontos bejegyzés, mely a kocsiknál ritkábban szükségeltetik, a jármű lámpáinak fényei beállítására szolgáló Lights ( bejegyzés. A bejegyzés után meg kell adnunk az alá tartozó Light ( bejegyzések számát. Nagyon fontos a helyes szám beírása, különben a TS lefagy, levelezni akar! Ezután következik a fények meghatározása Light ( bejegyzésekkel. A Light ( bejegyzés egy összfoglaló bejegyzés, sok kisebb bejegyzés tartozik alá. Nézzük sorban: o

o

A Type ( bejegyzés a fény típusát adja meg. A TS-ben két fajta fényt különböztetünk meg: § A fényforrás a mozdony lámpája előtt látszik. Ebből akár több is lehet egy járművön. Típusszáma: 0 (nulla) § A fény-megvilágítás, azaz a mozdony lámpái által megvilágított talaj fényessége. Ebből egy lámpaállapotban csak egy darab, illetve AI (mesterséges inteligenciájú, azaz Traffic-ban közlekedő) járművek esetén – feltehetően valmilyen hiba folytán – egy sem lehet. (Lehet, hogy ez abból adódik, hogy a játékban összesen csak 1 db szerepelhet, mivel lehet, hogy a TS nem képes ezen fények átfedését lekezelni. De ez csak tipp.) Típusszáma: 1 (egy) A fényforrások száma a TS erőforráshatárai miatt korlátozott. Az egyszerre betöltött tile-ok (területegységek; ~2x2 km/darab) esetében összesen kb. 200 darab fény éghet, beleértve ebbe a jelzők fényeit és a járművek mindkét fénytípusát. Nos ez, ha jól belegondolunk, nem is olyan sok egy akár 6x6 km-es területen. Ez a hiba kétféleképpen szokott megmutatkozni: egyrészt nem akar égni a mozdony lámpája, másrészt sötétek a jelzők. A TS mechanizmusa szerint a folyamat a következőképpen zajlik: Először betölti a pálya aktuális és környező tile-jait a rajtuk szereplő jelzőkkel együtt. Amennyiben már a pályán túl sok jelző szerepel, a később betöltött jelzőknek már nem marad „hely”, így a fényeik nem égnek. De ettől még működnek a jelzők! Ezután tölti be a TS a memóriába a járműveket. Ha a játék kezdetekor felkapcsoljuk a fényeket, amennyiben már nem volt „hely” a fények működtetéséhez, úgy azok nem gyulladnak fel. Előfordul az is, ha a határérték közelében jár a fények száma, hogy a jármű fényeiből csak néhány gyullad ki. A másik eset, amikor a játék során később érkezünk olyan tile-okra, ahol túl sok a jelzőfény, és a járművünk lámpáit már korábban felkapcsoltuk, hogy a jelzők közül fog több nem világítani, míg a jármű fényei égve maradnak. Ha ugyanide lekapcsolt lámpával érkezünk, előfordulhat, hogy világít a jelzők fénye. Bármelyik esetre a megoldás a jelzők számának csökkentése lehet csak. Ezért pályaépítés során igyekezzük elkerülni a túl nagy pályaudvarok építését, illetve a túlzott jelzősítést! A Conditions ( bejegyzésen belül azt állíthatjuk be, hogy az adott fény milyen körülmények között égjen. Ezt több tényező is befolyásolhatja: § A Headlight ( bejegyzés arra utal, hogy mikor kapcsolódik be a fény a játékban a kezelés hatására. A lámpa bekapcsolása a H gombbal, kikapcsolása a Shift+H billentyűkombinációval lehetséges két fokozatban. Kivétel a gőzmozdony, mert ott csak egy fokozat van. Lehetséges értékei: • 0: a fény a kapcsoló állásától függetlenül működik; AI járművek esetén van fontos szerepe (lásd később) • 1: a fény kikapcsolt állapotban ég • 2: a fény az első fokozatban ég (H gomb egyszeri megnyomására gyullad ki) • 3: a fény a második fokozatban ég (H gomb kétszeri megnyomására gyullad ki) Szándékosan nem írtam a játék szövege szerinti tompított (dim) és távolsági (bright) szavakat, mivel nem csak kimondottan erre használható a kapcsoló. Egyes járművek (motorkocsik) esetén előfordul, hogy a második pozícióban hátrafelé világít a fényszóró, míg előre vörös fény ég, így hátrafelé haladáskor is ég a jármű lámpája. Egyes írások szerint – amelyekkel teljesen egyetértek – az 1-es érték kikapcsolt lámpaállásra használata pazarlásnak számít, főként, hogy összesen három (gőzmozdonyok esetében kettő) állású kapcsoló programozhat csak be. § A Units ( bejegyzés attól teszi függővé a fény világítását, hogy a jármű hol áll egy szerelvényben. Lehetséges értékei: • 0: a fény függetlenül világít attól, hogy a jármű szerelvényben áll-e vagy sem

29

•

o

o o

1: a fény akkor ég, ha a jármű szerelvényben áll (egyes források szerint ez csak akkor igaz, ha nem az első, vagy utolsó helyen áll a jármű) • 2: a fény akkor világít, ha a jármű a szerelvény elején áll • 3: a fény akkor világít, ha a jármű a szerelvény végén áll § A Penality ( bejegyzés a vészfékezéskori világításra utal. Működését jelenleg is homály fedi, még nem láttam használni. Lehetséges értékei: • 0: a fény függetlenül világít a vészfékezéstől • 1: a fény akkor ég, amikor a jármű még nem állt meg egy vészfékezés folyamán (?) • 2: a jármű megállt egy vészfékezés után § A Control ( bejegyzés a játékos jármű feletti uralmának megfelelően szabályozza a fény világítását: • 0: a fény a vezérlési állapottól függetlenül ég • 1: a fény akkor ég, ha a játékosnak nincs befolyása a járműre (pl.: szerelvénybe sorozott második mozdony), de ide tartozik az AI-vonatok csoportja is • 2: a fény akkor ég, amikor a játékos kezeli a járművet Ennek az AI vonatok kivilágításánál lesz szerepe (lásd később). § A Service ( bejegyzés a jármű üzemállapotától függő beállítást jelenti. Lehetséges értékei: • 0: a fény független az üzemállapottól • 1: a jármű inaktív állapotban van, azaz lekapcsolt jármű a játékos szerelvényéről, vagy Loose Consist • 2: a jármű aktív állapotban van, azaz a játékos vonata, vagy AI-vonat § A TimeOfDay ( bejegyzés a napszaktól teszi függővé a fény világítását: • 0: a fény a napszaktól függetlenül ég • 1: a fény csak nappal ég • 2: a fény csak éjszaka ég § A Weather ( bejegyzés az időjárástól teszi függővé a fény világítását: • 0: a fény az időjárástól függetlenül ég • 1: a fény csak napos időben ég • 2: a fény csak esőben ég • 3: a fény csak havazásban ég § A Coupling ( bejegyzés a járműre kapcsolt másik járműtől teszi függővé a fény világítását (szinte teljesen ugyan az, mint a Units ( csak más oldalról közelíti meg a kérdést): • 0: a fény független a kapcsolástól • 1: a fény akkor világít, ha a jármű elejére van másik jármű kapcsolva • 2: a fény akkor világít, ha a jármű végére van másik jármű kapcsolva • 3: a fény akkor világít, ha a jármű mindkét végére jármű van kapcsolva A Conditions ( bejegyzések alapértelmezése a 0, így ezt nem kell külön bejegyzésbe beírni. Ne felejtsük a Conditions ( bezáró zárójelét kitenni! A következő a Cycle ( bejegyzés, mely a különböző fényállapotok váltakozásának módját adja meg. Erre csak akkor van szükség, ha több fény váltakozik folyamatos ciklusban, például: futófény, stb. Vasúti alkalmazása elég ritka, inkább csak speciális esetekben, illetve érdekes dolgok kialakítására használható (síncsiszoló, áramszedő szikrázás, stb.) Lehetséges értékei: § 0: a fények ciklusa folyamatos (1., 2., 3., 4., 1., 2., 3., 4., 1., stb.) § 1: a fények ciklusa alternáló (1., 2., 3., 4., 3., 2., 1., 2., stb.) A FadeIn ( és FadeOut ( bejegyzésekkel a fények felgyulladásának sebessége állítható be 0 és 1 másodperces értékek között. Modern járművek esetében 0.1-0.3, régebbi járművek esetén 0.5-0.75 érték lehet helyes választás. A States ( bejegyzés a különböző fényállapotokat tartalmazza. A bejegyzés után be kell írni az utána következő State ( bejegyzések számát. Ez a legtöbb esetben 1 lesz, több State ( csak a ciklikusan változó fények esetén lehet érdekes. A State ( bejegyzésen belül az alábbi paraméterek adhatók meg: § A Duration ( bejegyzés a fény világításának időbeni hosszát adja meg másodpercben. Erre csak a villogó, illetve ciklikusan változó fények esetén van szükség, alapesetben 0 a helyes érték. § A LightColour ( a fény színét adja meg. A bejegyzésben szereplő 8 karakterből az első kettő az átlátszóságot, a további 6 pedig párosával a vörös, zöld és kék színek arányát adja meg. A négyszer két karakter tulajdonképpen egy kétjegyű hexadecimális (tizenhatos számrendszerbeli) szám. (A tizedhatos számrendszerben 16 db számjegy van: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F.) A legkisebb érték a 00, a legnagyobb az FF. Néhány példa a közérthetőség kedvéért:

30

• FFFFFFFF: nem átlátszó fehér fény • 80FF0000: félig áttetsző vörös fény • FF808000: nem átlátszó sárga fény Fontos a fények beállításánál az élethűségre törekedés. A legtöbben a jármű fényszoróinak fényét teljesen fehérre állítják be, ami szerintem helytelen. A fényforrások – főként az izzók – nem képesek tökéletes fehér fényt adni, fényük kissé a sárgába, narancsba hajlik. A koszos járművek esetén ez még inkább jelentkezik, hiszen a jármű fényszórója is koszos, rozsdaporos, amitől a fény még inkább elfakul és elsárgul. Néhány új jármű kivételével (pl.: Desiro) nem valósághű a tisztán fehér fény alkalmazása. § A Position ( bejegyzésben a fények helyét lehet megadni a jármű PIVOT pontjához (beillesztési pont) képest. A három szám jelentése: a járműhöz képest keresztirányú, magassági és hosszirányú méretek méterben a PIVOT pontól számítva. Itt kell megemlíteni néhány gyakorlati problémát is. Az egyik, amikor két fényforrás fénye van egymás mellett, előfordulhat, hogy az egymást fedő részeken csíkozódás alakul ki. Ezt ki lehet küszöbölni, ha az egyik fényforrás helyét néhány cm-rel előrébb, vagy hátrébb toljuk. A TS nem szereti az azonos helyen található felületeket. A másik probléma lehet, hogy egy beállított fény nem akar megjelenni a járművön. Amennyiben kizárható a korábban leírt „túl sok fényforrás” probléma, úgy előfordulhat, hogy a fényforrás helyét adtuk meg rosszul, például a jármű belsejében helyeztük el. Ekkor természetesen nem világít át a fény a járművön. § A Transition ( bejegyzésben a különböző State ( bejegyzésben szereplő fények átmenetét lehet beállítani. 0 érték esetén a váltás villámgyors, míg magasabb értékek esetén egyre elnyúltabb. Ennek a bejegyzésnek is csak a ciklikusan változó fények esetén van jelentősége. § A Radius ( bejegyzésben a fényforrás méretét, fénykör sugarát lehet megadni. Kivétel ez alól a fény-megvilágítás (Type ( 1 )), mert itt a megvilágítás hosszát adhatjuk meg így (Tulajdonképpen tényleg a sugarát, mivel a megvilágítás egy körcikk szelet.) § Az Angle ( bejegyzés csak a fény-megvilágítás (Type ( 1 )) típus esetén érvényes, és a megvilágítás középvonaltól számított szélességét határozhatjuk meg vele. § Az Azimuth ( és Elevation ( bejegyzések a fényforrás irányát (ill. lehatároltságát ?) adják meg. Tapasztalatom nem sok van velük, a leírások pedig elég zavarosak. Egy nagyon fontos feladatuk azért van: a jármű végén található fényforrás megfordítására használhatók, hogy az hátrafelé világítson. (Azimuth ( 0 180 0 )) Ezzel a States ( bejegyzés végére értünk. Ne felejtsük el a State ( és a States ( bejegyzések bezáró zárójeleit kitenni. Ami még hiányzik a végéről az a Light ( bejegyzés bezáró zárójele, illetve ha nem akarunk megadni több Light ( bejegyzést, akkor a Lights ( bejegyzés bezáró zárójelét is ki kell rakni. A Light ( bejegyzésben van néhány a Kuju által nem dokumentált bejegyzés, melyekről senki nem tud semmit, azt sem, hogy működnek-e egyáltalán. Ezek a következők: ActiveCab (, InactiveCab ( és a Taillight ( bejegyzések. Ami még ide tartozik, de konkrét példával még nem illusztráltam: az AI-vonatok világítása. A járműkészítők a legtöbb esetben csak azt állítják be a járműveknél, hogy a játékos felkapcsolhassa a fényeket, azt már nem, hogy a jármű fényei akkor is világítsanak, amikor AI-vonatként közlekedik. Pedig ennek a beállításnak az elvégzése csupán néhány percet vesz csak igénybe: o A megfelelő Light ( bejegyzésekről csinálunk másolatot, átírjuk a Lights ( bejegyzésben a darabszámot az új értékre, a Comment ( sorba lehetőleg beírjuk, hogy itt majd AI fényekről lesz szó. o A Conditions ( bejegyzésben a Headlight ( sort töröljük – mivel ez a fényszóró kapcsolójának állapotára utal – és az alábbi bejegyzéseket tesszük meg: Control ( 1 ) – a fény akkor ég, amikor nem a játékos kezeli a járművet Service ( 2 ) – a fény akkor ég, amikor a jármű aktív AI-vonat (vagyis nem Loose consist) o Ezen kívül még további bejegyzéseket is tehetünk, de ez már csak a kialakítástól és az egyéni ízlésektől függ. Pl.: Units ( 2 ) – csak a szerelvény elején álló jármű esetén ég, stb. -

Amiről eddig még nem esett szó, de sokszor nagy jelentőségű a FreightAnim ( bejegyzés. Ezzel a bejegyzéssel lehetőségünk van a járműhöz egy különálló shape fájl hozzáfűzéséhez. Ezt elsősorban a gőzmozdonyok szerkocsijában található szénhez találták ki. Ezzel a bejegyzéssel ugyanis a TS képes animálni a szén fogyását. A shape fájl neve után beírt két szám közül az első a PIVOT ponttól számított magasságot, a második az animáció gyorsaságát jelent. Ezt a bejegyzést a gyakorlatban másra is fel lehet használni: rakomány elhelyezése teherkocsikon, illetve mozdonyvezető mozdonyra helyezése. A hozzáillesztendő shape fájlhoz nincs szükség shape data fájl létrehozására.

31

5.2. A vontató jármű – a mozdony (.ENG fájl) Az .ENG fájl a vontató járművek tulajdonságait tartalmazza. Lényeges eleme, hogy az .ENG fájl is úgy kezdődik, mint a .WAG fájl: Wagon ( bejegyzéssel. Azaz, a fent leírtak ide is ugyanúgy érvényesek. Az .ENG fájl viszont bővebb, mint a .WAG fájl, hiszen a vontatás tulajdonságait is tartalmazza. Ezek közül csak a leglényegesebbeket sorolnám fel: (A gőzmozdonyhoz tartozó ezernyi beállítást mellőzném, mivel az nagy szakértelmet kíván.) -

A Type ( bejegyzésben a mozdony típusát tudjuk megadni. Lehet: Diesel, Electric, és Steam attól függően, hogy dízel-, villany- vagy gőzmozdonyról van szó.

-

A Wagon ( bejegyzésben a fentebb, fájl elején megadott Wagon ( bejelgyzés utáni nevet kell újra beírni.

-

Az Effects ( részben a jármű füstölését lehet megadni dízel- és gőmozdonyok esetén. Dízelmozdony esetén a DieselSpecialEffects ( bejegyzésben kipufogó nyílásonként szerepel egy Exhaust<szám> ( bejegyzés. Ezen belül a számok jelentése a következő: o Az első három szám a kipufogás helye a jármű PIVOT pontjához képest o A második három szám az irányra utal (a felfelét a 0 1 0 adja meg) o Az utolsó szám a kipufogás mennyisége: minél kisebb, annál több

-

A MaxPower ( a jármű teljesítményét mutatja meg, kW-ban.

-

A MaxForce ( a jármű indításkor kifejtendő legnagyobb vonóerejét adja meg kN-ban. Ez a magyar vasúti irodalomban indító vonóerő néven szerepel. Az egyik forrás hoz egy számítási képletet is, amelynek pontosságát nem ismerem (bár pl.: az M40-es sorozat esetén teljesen igaz): MaxForce = a jármű szolgálati tömege / 4 (tengelyszám?) * 10

-

A MaxContinousForce ( az állandó vonóerő értékének megadására szolgál. Indításkor a mozdony a maximális indító vonóerővel képes csak indulni, annak ellenére, hogy a teljesítménye miatt számtanilag akár nagyobb erő kifejtésére is képes lenne. Az oka ennek a tapadás. Túl nagy vonóerő esetén a kerekek elkaparnak. Az indulás ezen az úgynevezett „tapadási határon” történik. A tapadási határ vonóerő értéke a sebesség növekedésével enyhén csökken mindaddig, míg el nem éri a beépített teljesítmény által meghatározott vonóerőt. Ez egy adott sebességnél következik be, az állandó vonóerőhöz tartozó sebességnél, akkor a vonóerő értéke megegyezik az állandó vonóerő értékével, azaz a MaxContinousForce ( bejegyzéshez beírandó értékkel. Az ennél nagyobb sebességeknél már a teljesítmény szab határt a vonóerőnek, általában a vonóerő ilyenkor rohamosan csökenni kezd. Amennyiben nincs adatunk erről az értékről, úgy a MaxForce ( értékének 2/3-a jó közelítő értéket ad.

-

A MaxVelocity ( bejegyzés a maximális sebesség beállítására használható. Tevékenysége csupán annyi, hogy e felett a sebesség felett a vonóerő értékét rohamosan csökkenti egészen nulláig. Egy jól beállított teljesítményű és vonóerejű mozdonynál ez amúgy is bekövetkezik, tehát ilyen szempontból nem sok értelmét látom ennek a bejegyzésnek. Szerepe igazából talán csak a túlsebesség védelem (általában a megengedett sebesség +10% értéknél automatikusan lekapcsolódik a mozdonyoknál a vontatás, esetleg fékezés kezdődik) beálításánál lehet.

-

A DieselEngineSpeedOfMaxTractiveEffort ( bejegyzésben az állandó vonóerőhöz tartozó sebesség értékét lehet megadni. (Lásd fent.)

-

A NumWheels ( bejegyzés az Engine ( bejegyzés-szakaszban a tengelyterhelés kiszámításával a tapadási erő (hiába van egy mozdonynak a teljesítményéből eredően nagyobb vonóereje, ha nincs elég tömege a tapadáshoz, és elkaparnak a kerekek) megállapításához szükséges. Sajnos a Kuju itt több hibát is vétett: először is, nem a kerekek, hanem a tengelyek számával számol, másodszor pedig rosszul is számol. Mint azt más írásokban olvastam a beépített képletben a vontatási tömeg kiszámításához a jármű tömegét osztja a NumWheels ( értékével. Mivel hazai (és európai) viszonyok közt tengelyterheléssel számolunk, ide a tengelyek száma szükségeltetik. A másik hiba, hogy ide nem az összes, hanem csak a hajtott tengelyek száma szükségeltetne. Viszont így is csak az egy tengelyre eső tapadósúlyt számolja ki, a további számításokhoz (mozdony teljes tapadósúlyának kiszámítása) az összes hajtott tengelyre eső tapadósúly szükségeltetne. Erre még a játék kiadása előtt a Kuju is rájött, mert az eredeti .ENG fájlokban is egy fiktív érték (1 ill. 2) szerepel. Ebből az következne, hogy az 1-es érték akkor szükséges, ha a jármű minden kereke hajtott. A 2-es érték a felezi a jármű tömegéből tapadásra kifejthető tömeg értékét. Tapasztalati úton történő meghatározáskor a befolyásolt tulajdonság a mozdony gyorsulása lett, de nem igazán követhető le számszerűen. Az 1-es érték nagy, a nagyobb értékek lomhább gyorsulást eredményeznek.

32

-

A Name ( bejegyzésben ugyanúgy meg kell adni a jármű nevét, mint az a kocsik esetében a Wagon ( bejegyzésben történt.

-

A Sound ( bejegyzésre szintén a fent leírtak a mérvadóak. Mivel a többi funkcióban még nem ismerem ki magam teljesen, új információm ezekkel kapcsolatban nincs, itt félbehagynám ennek a fejezetnek a leírását. A mozdonyok további beállításai nagy szakértelmet és sok órás próbálkozást jelent. A közeljövőben folytatni fogom.

33

7.

A pálya működtetése – Activityk

Kinek ne lett volna az első időszakban olyan érzése, hogy: „Szép ez a pálya, meg ez a vonat, amit vezetek, de egyedül vagyok? Hol van a többi vonat?” Nem elég megépíteni egy pályát, meg is kell azt tölteni élettel! Vagyis készítsünk ACTIVITY-ket! Az activity a játék egy előre programozható menete. Az állandó, programozható tényezők mellett az egyetlen, ami az activity működését befolyásolhatja, az a játékos vonatvezetése. Minden más tényező fix egy activityben. 7.1. Az Activity felépítése Az activity több részből áll. A legfontosabb, és minden activitynél szükséges, a játékos tevékenységének beállítása. Ezt a Player Service (a játékos tevékenysége) beállításával tehetjük meg. Ez a Service könyvtár .SRV fájljában rögzítődik. A Service létrehozásához egy Consistot és egy útvonalat (Path-t) kell megadnunk. A Path a Paths könyvtár .PAT fájljaiban rögzítődik. Személyszállító vonat esetén megadhatjuk, hogy a vonat melyik peron mellett álljon meg. Ezután a menetrendet is ki lehet számíttatni a vonat számára. Ezzel már egy játszható activity kapunk, egy normál vonattovábbítást. Egyéb beállítások ezután történhetnek: activity végfeltételeinek megadása, Loose Consistok lehelyezése, ideiglenes lassan bejárandó pályarészek meghatározása, évszak, időjárás beállítása, stb. Ezen adatok az Activity könyvtárban található .ACT fájlokban kerülnek eltárolásra. Amennyiben AI-vonatokat is közlekedtetni szeretnénk, meg kell adni Traffic-ot, amely a forgalom tevékenységét (Traffic Service) tartalmazza. Ezek ugyanolyan Service-ek, mint a Player Service-ek, tehát ugyanúgy meg kell adni egy szerelvényt és egy nyomvonalat. A különbség annyi, hogy az indulási időket a Trafficban kell megadni, és egy Traffic Service többször is szerepelhet (különböző indulási időkkel) egy Trafficon belül. A Traffic adatait a Traffic könyvtár .TRF fájljaiban rögzíti a program.

Az Activity Editor (AE) felépítése a követező részekből áll (részletes ismertetésük később következik): - A bal felső sarokban a főablak (Activity Editor) látható, rajta a pálya vonalas térképével. A térkép a bal egérgomb lenyomva tartásakor mozgatható, a jobb egérgomb lenyomva tartásakor zoomolható az egér mozgatásával. A térképen a jobb egérgomb lenyomására különböző menük ugranak elő. - A térkép alatt balra található az activity teszteléshez használatos időskála és kiegészítő gombjai. - A térkép alatt jobbra az activity speciáis beállításai tehetők meg. - A jobb felső sarokban található az Activity nevű rész, ahol az activity neve és információ beállításai tehetők meg. - Ez alatt a Player rész található, ahol a játékos által vezetett vonat beállításai tehetők meg. - Ez alatt a Conditions and Hazards részben az időjárás és az egyéb veszélyek megjelenése állítható be. - Legalul pedig a Traffic Pattern részben az egyéb vonatok közlekedése adható meg.

34

7.2. Alapbeállítások Az első lépés az Activity Editor elindítása után, hogy a File menü New parancsával létrehozzunk egy új activity-t. A program először a pálya kiválasztását kéri legördülő menüből. A legördülő menüben csak a Routes könyvtárban található, a TS számára hibátlan – használható – pályák jelennek meg. Ezután egy ablakban az activity nevét kell megadnunk. Ez lesz a játékban megjelenő neve az activitynknek. Az activity fájlnevét a mentéskor kell megadnunk. Ezután hosszabb-rövidebb idő elteltével megjelenik a pálya rajza a térkép ablakban. Kezdhetjük az activity készítését. Jobbra fent, az Activity részben a Display name részben beírva látjuk az előbb megadott nevet. Ezt bármikor módosíthatjuk. Alatta az activity nehézségi fokát állíthatjuk be könnyű-közepes-nehéz fokozatokban. Mindez csak tájékoztató jellegű a játékosoknak. A Duration két számlálójában az activity időtartamát állíthatjuk be, ez szintén tájékoztató jellegű adat lesz. Az ez alatt található két gomb – Edit Activity description és Edit Activity brief – megnyomására előjön egy-egy ablak, melyekbe tájékoztató szöveget írhatunk. Az első a játékban az activity információs ablakában jelenik meg (ez legyen rövid és célratörő), míg a másik az activity indításakor a mozdonyban megjelenő ablakban lesz olvasható. Ez utóbbi legyen hosszabb, részletesebb leírás. Az ablakok ez esetben az X gomb megnyomásával zárhatók, a szövegek mentése így is megtörténik. Amennyiben ezeket az adatokat nem töltjük ki, az activity nem lesz elmenthető, mentés esetén hibaüzenet ír ki. ("Not all necessary information has been entered, activity may not work.") 7.3. Tevékenység létrehozása – a Service (.SRV) A játékos feladatának beállítása minden activityben kötelezően elvégzendő feladat. Ezt a Player részben tehetjük meg: - A Player service legördülő listában jelennek meg a már létező tevékenységek. - A New gombbal új tevékenység hozható létre - Az Edit gombbal a listából kiválasztott meglévő tevékenység szerkeszthető át - A Use as template gombbal a listából kiválasztott tevékenység szerkeszthető át, de új nevet lehet neki adni, így egy korábbi tevékenység szolgálhat egy újabb alapjául (a régi változatlan marad, az új pedig új néven kerül elmentésre) - A Delete gombbal végérvényesen törölhető a tevékenység. Csak olyat töröljünk, amelyikről tudjuk, hogy más activity nem használja, különben hibaüzenetet kapunk. - Az Edit timetable gomb megnyomására felugró ablakban majd a peronoknál megálló vonatunk menetrendjét számolhatjuk ki. - A View Work order gomb megnyomására felugró ablakban a feladatlista látható (hol melyik kocsit kell fel-, vagy leakasztanunk, stb.). - A Fuel status résznél a három üzemanyag (szén, víz, és gázolaj) kezdeti mennyisége adható meg a csúszkák segítségével. - A Start time számlálóknál az activity kezdési időpontját kell megadni. Hozzunk létre egy új tevékenységet: klikkeljünk a New gombra. Ekkor megjelenik a képen látható ablak: - A Name sorban a fájlnevet adjuk meg. - A Display name sorban a játékban megjelenő nevet kell megadnunk. A két névnek célszerű közös szót beírni, így egyszerűbben eligazodunk a fájlok közt. - Az Expected player performance (Default performace – AI-vonat esetén) számlálóval a nehézségi fok határozható meg. A menetrend számításakor ennek megfelelően számít lazább, vagy szorosabb menerendet. AI-vonatok esetében mellőzzük a használatát (egyes források szerint hibát okozhat – személy szerint erről nem vagyok meggyőződve, de az ördög nem alszik). - A Start speed és End speed számlálókban a tevékenység kezdeti és végsebességét adhatjuk meg. Ez elsősorban AI-vonatok esetén használható, de a játékos tevékenysége esetén is működik. Tehát például van arra lehetőség, hogy a vonat haladása közben „csöppenjünk” a vezetőállásba. A végsebeség beállításának ilyenkor nincs sok értelme, mivel azt már mi szabályozzuk, a sebességelérést, mint feltételt pedig nem itt kell meghatározni. (AI-vonat esetén van értelme, hiszen menet közben is végetérhet az AI-vonat futása, nem kell szükségszerűen megállnia.) - A Consist legördülő listából a meglévő szerelvényeket választhatjuk

35

ki. A New, Edit, Use as template, és Delete gombok segítségével hozhatunk létre, módosíthatunk, vagy törölhetünk consistokat. A gombok működése megegyezik a fentebb leírtakkal. - A Path legördülő listából a meglévő nyomvonalak között válogathatunk. A New, Edit, Use as template, és Delete gombok segítségével hozhatunk létre, módosíthatunk, vagy törölhetünk nyomvonalakat. A gombok működése megegyezik a fentebb leírtakkal. - A Stops listában azok a peronok (Platform) fognak megjelenni, amely mellett a nyomvonal elhalad. Amennyiben azt szeretnénk, hogy a vonatnak ott meg kelljen állnia, pipáljuk be a kis kockát a peron neve előtt. Később ez alapján számíttathatunk menetrendet a programmal. De először is hozzunk létre egy szerelvényt, amit majd a játékos vezet az activityben, illetve egy nyomvonalat, amelyen a játékosnak haladnia kell. 7.4. A consist (.CON) Adott egy pálya a Routes könyvtárban, és adott a járművek halmaza a Trainset könyvtárban. Ahhoz, hogy a járművekből vonatok álljanak össze, meg kell ismerkednünk a CONSIST fogalmával. A Consist egy szerelvény összeállítását adja meg. A .CON fájlok a Trains\Consists könyvtárban találhatók. Az MSTS indításakor a program leellenőrzi az összes Consist fájlt, hogy meg van-e a bennük hivatkozott jármű, és amennyiben nincs, hibaüzenetet ír ki. Ezt elkerülendő, érdemes a Consist fájlokat rendszeresen karbantartani. Consist fájl készítése lehetséges az Activity Editoron belül (lásd később), vagy a ConBuilder segédprogrammal. Ez utóbbi használata javasolt, mivel nem csak a Consist összeállítására képes, hanem több más kényelmi funkciója mellett a Consistok, járművek hibáinak kiszűrésére is alkalmas.

Az Activity Editorba beépített Consist Editor elindításkor megjelenik a fenti ablak, melynek részei a következők: - Name: a Consist fájl neve - Display name: a szerelvény neve a játékban - Rolling stock types: a jármű típusa. A legördülő listából a típus kiválasztása után csak a kiválasztott fajtájú járművek jelennek meg az alatta lévő Rolling stock listában. - Selected: a kijelölt jármű neve (.ENG/.WAG fájl-beli hivatkozási neve)

36

-

Rolling stock: a járművek listája a nevükkel, fékrendszerükkel és a kapcsolókészülék típusával. A Name gombra klikkelve a nevek szerint lehet sorbarendezni őket. Alapállapotban a legutóbb használtak lesznek legelöl. Length: információ a jármű hosszáról. Mass: információ a jármű tömegéről. Consist durability: információ a szerelvény tűrőképességéről. Az ez alatt lévő csuszka segítségével érzékenyebbé tehetjük a szerelvényt szakadásra, siklásokra. Brakes: információ a fék típusáról. Fontos, hogy egy szerelvényben csak egyféle fékrendszerű jármű legyen. Couplings: információ a kapcsolókészülék típusáról. Fontos, hogy csak azonos típusú kapcsoló-készülékkel rendelkező járművek tudnak összekapcsolódni. Preview: előnézet kép a jármű shape-jéről. A nagy ablakban állítható össze a szerelvény a listából való lehúzással. A járműre való dupla klikkelésre a jármű iránya megfordul a szerelvényhez képest. A jármű a szerelvényben szabadon áthelyezhető az egérrel való húzással. A bal oldali kis ikon (a Coupling felirat alatt) a jármű törlésére alkalmas. A lenti nagy ablakból a kis ikonra húzva a jármű törölhető a szerelvényből. A szerelvény mentése és kilépés a Save & Exit gomb lenyomásával lehetséges.

Természetesen a Consist fájlok nem csak ezekkel a programokkal módosíthatók, akár kézzel is át tudjuk írni tartalmukat, mint az összes többi TS konfigurációs fájl esetén. Lássuk hát, mit is tartalmaznak a Consist fájlok: - A bejegyzések a Train ( bejegyzésen belül találhatók. - A TrainCfg ( bejegyzés tartalmazza a részletes adatokat. A bejegyzés után a szerelvény hivatkozási neve áll. Ezen a néven fog majd a szerelvény az activitykben szerepelni. - A Name ( bejegyzésben a képernyőre kiirandó név szerepel. Szóköz használata esetén mindig tegyük ki az idézőjeleket („”)! A név megadásakor kerüljük a hosszú Ű és Ő betüket (Általános érvényű szabály a TS-ben!). - A Serial ( bejegyzés jelentését nem tudom. - A MaxVelocity ( bejegyzésben a szerelvény sebességét határozhatjuk meg. Ez a játékos által vezetett vonatra nem érvényes, csak a számítógép által vezetett (AI- azaz mesterséges inteligenciájú) vonatok esetén van jelentősége. Az első szám a vonat sebessége mérföld/óra mértékegységgel, a második szám a sebesség véletlenszerűségét megadó tényező. Az AI-vonatok a pályán – amennyiben jelző, vagy Speedpost elem sebességkorlátozó hatása nem érvényesül – ezzel a sebességgel fognak haladni. Amennyiben itt 1-es érték szerepel a sebesség értéke nem változik. Amennyiben viszont ide kisebb értéket írunk be, úgy az AI-vonat sebessége egy intervallumon belül változhat, melynek minimális értéke a második szám szorzata a megadott sebességgel, a maximális értéke pedig a megadott sebesség. (Pl.: a két megadott szám ( 40 0.5 ), akkor az AIvonat sebessége 20 és 40 mp/h között változhat.) - A NextWagonUID ( értéke a következő, még nem használt UiD ( bejegyzés értéke a Wagon ( vagy Engine ( bejegyzésen belül. (Lásd lent.) - A Durability ( bejegyzés a vonat terhelhetőségét mondja meg. 1-es érték esetén a járműveknél beállított értékeket alkalmazza, ennél kisebb értéknél csökken a terhelhetőség mértéke (könnyebben siklik ki, könnyebben szakad szét a vonat.) Sohasem használtam. - Ezután következik a szerelvény egyes járműveinek felsorolása. Mozdony esetén Engine (, kocsi esetén Wagon ( bejegyzésnek kell szerepelnie. Mindkét fajta bejegyzésen belül az alábbi bejegyzések találhatók: - Az UiD ( az adott jármű száma. Ez általában 0-tól kezdődő számozás a vonat elejétől, de össze-vissza is lehet a számozás. A lényeg, hogy azonos szám két kocsinál egyszerre nem szerepelhet. - A WagonData ( illetve EngineData ( bejegyzésen belül a jármű neve és a konfigurációs fájljának (.WAG illetve .ENG) helye (könytár neve a Trainset könyvtáron belül) szerepel. A név a .WAG illetve .ENG fájlban a Wagon ( bejegyzésben megadott hivatkozási név, nem a fájl neve! - A Flip () bejegyzés menetirányhoz ellentétes irányba fordítja a járművet. Mozdony nélküli Consistot is készíthetünk, de ez a játékban nem jelenik meg a kiválasztható vonatok listájában. Ezeket az activitykben szokták alkalmazni. Az activityben a Consistokat többféle funkcióra is felhasználhatjuk: - Játékos szerelvénye: ez lesz az a vonat, amelyet a játékos vezethet. - AI-vonat szerelvénye: ezek azok a vonatok, amelyek a számítógép által vezérelve közlekednek a pályán. - Loose Consistok: ezek azok a szerelvények, amelyek mozdulatlanul állnak a pályán. Ezeket a járműveket felkapcsolhatja a játékos a vonatára.

37

7.5. A nyomvonal – a Path (.PAT) A nyomvonal létrehozása előtt meg kell adnunk a fájlnevet, majd a hivatkozási nevét. Ez utóbbi az Activity egyéb fájljaiban jelenik majd meg. A megjelenő segédablakban a következőket láthatjuk: - A Path display name sorban az előbb beírt hivatkozási nevet. - A Starting és Ending location sorokba írjuk be a nyomvonal kezdő és célpontjának egy tetszőleges szöveget. Ez mint tájékoztató szöveg fog megjelenni a játékban. - A Player drivable path pipa csak az AI-vonatok tevékenységénél aktív, ha ez nincs bepipálva, a játékos számára láthatatlan lesz a nyomvonal. - A Leave path editor gomb megnyomásával kiléphetünk a nyomvonal szerkesztőből. - A Higlight gomb megnyomására megnézhetjük nyomvonalunk egyes szakaszait pirossal kiemelve. - A .prev és .next gombokal a szakaszok közt lépegethetünk előre-hátra - A Mouse pipa az egér számára is megengedi a fenti funkciót (még nem használtam) - A Broken gomb megnyomására az eltörött nyomvonal törési helyéhez ugrik a térkép. A pályát a térképen láthatjuk. A fekete vonal a vágányokat, a fekete pontok a váltókat jelölik. Amennyiben a View menüben be van pipálva, más objektumokat is láthatunk: - Zöld ferde vonal a Siding vége (egy Siding-hez kettő tartozik) - Kék ferde vonal a Platform vége (egy Platform-hoz kettő tartozik) - Piros (teszt közben zöld) pont a pálya mellett kis szárral: jelző. A jelzők a pálya bal oldalára vannak jelölve, ellentétesen a magyar viszonyokkal. - Ezen kívül jelöli még a Milepost-ok, üzemanyagfeltöltő (Pickup) objektumok, ideiglenes lassan bejárandó pályarészek helyét is, illetve - kiíratható vele a Siding-ek és Platform-ok neve, láthatóvá tehető az AI-vonatok útvonala, az AI-vonatok neve is. A nyomvonal meghatározása a jobb egérgombra előugró menüből kiválasztott parancsok segítségével lehetséges. A nyomvonal lehelyezéséhez először a kezdőpontját kell meghatározni a Place Start point menüpont kiválasztásával. Ekkor a kurzor helyén a vágányon megjelenik egy kék pont zöld szegéllyel, és tőle egyik irányban elindul egy zöld vonal, mely a váltók egyenes ágán át fut a pálya végpontjáig. A pont a Consistunk végének helye lesz, ezért mindig számoljuk bele a vonat hosszát is a lehelyezésbe. Amennyiben a zöld vonal az ellentétes irányba indul, mint amerre a vonatunkat indítani szeretnénk úgy válasszuk ki a Toggle start direction menüpontot. Ekkor a zöld vonal a másik irányban indul el. Az érintett váltók helye a nyomvonalon zöld ponttal van jelölve. Amennyiben ráállunk erre a pontra, a menüből kiválaszthatjuk a Take other exit menüpontot, melynek hatására a váltó másik ágán fut majd tovább a zöld színű nyomvonal (feltéve, hogy csúccsal szemben érintett váltónál csináljuk ezt). Amennyiben a vonattal tolatni szeretnénk, válasszuk ki a Place reverse point menüpontot. Ekkor abban a pontban keletkezik egy jel, majd a zöld vonal az ellenkező irányban folytatja útját. Ez általában nem látszik, hiszen azon a szakaszon már volt egy zöld vonal. Az első csúccsal szemben álló váltónál viszont a visszafelé futó nyomvonalunkat eltéríthetjük. Egy szakaszon sokszor áthaladhat egy nyomvonal, de mindig csak a legutolsó mozgást tudjuk szerkeszteni (pl.: Reverse point-ot lerakni vagy váltónál irányt választani). A Place waiting point paranccsal várakozó pontot tudunk lehelyezni egy AI-vonat számára. A megadott időtartamra megáll az AI-vonat. A probléma csak az vele, hogy a TS az activity AE-be való betöltésekor ennek értékét nullázza, így minden activtity módosításkor újra be kell állítanunk őket. A Begin passing path paranccsal az AI-vonatok találkozását lehet megoldani. A Begin passing path parancs csak AI-vonatok esetén működik a játékos útvonalára nincsenek hatással.. Ezt a parancsot csak váltón tudjuk kiadni. Lényegében az AI-vonatok találkozása oldható meg vele könnyedén. Működési elve, hogy a kijelölt váltótól, a program a váltó másik ágán keresztül felépít egy második nyomvonalat, amit az AI-vonat akkor fog használni, ha az első útvonal egy másik vonat által foglalt lenne. Természetesen ennek akkor van értelme, ha pl. egy állomás másik oldalán a nyomvonal visszatalál az eredeti nyomvonalhoz. A második nyomvonal felépülésekor a váltó másik ágán elindulva, a kitérők egyenes ágán halad a felépülése. Sajnos emiatt nem biztos, hogy visszatalál az eredeti nyomhoz. A második nyomvonalon viszont váltó átállítására lefagy a TS. Így ezt a funkciót csak egyszerűbb, vagy adott kialakítású vágánygeometria esetén tudjuk használni. A Place End point paranccsal a nyomvonal végpontját tudjuk megadni. Alapesetben ez a vágány

38

vége, de érdemesebb a végpontot egy normál sínszakaszra áthelyezni, mert esetenként prolémák adódhatnak vele. A Mark point as broken és a Delete broken point parancsokkal a nyomvonal eltörhető, illetve a törött pont törölhető. (Igazából nem tudom mi a lényege, főleg az első parancsnak, hiszen a nyomvonal eltörése – lásd később – hiba, rossz dolog. Ki az a hülye, aki magának rosszat akar?) Az Alter waiting time paranccsal a várakozó pont időtartamát tudjuk megváltoztatni. A Remove start point, Remove end point, Remove waiting point, Remove passing path parancsokkal az adott pontokat tudjuk törölni. Vigyázat! A kezdőpont törlése a nyomvonal törlésével jár! A Return to start point menüpontot még nem használtam. A .PAT fájl tartalmát nem részletezném, természetesen megtalálhatók benne mindazon adatok, melyet az AE bekér egy nyomvonal elkészítésekor. A szöveges részeken kívül mást nem érdemes átírni benne. 7.5.1. Problémák a nyomvonal körül A leggyakoribb hiba a nyomvonal törése (Broken path). Ez több esetben is elő szokott fordulni, leggyakrabban akkor, ha a nyomvonal kijelölése után a pályán még módosítás történik. (Vagy egy régi activity-t szeretnénk lejátszni egy újabb, módosított pályán.) A nyomvonal a pálya azonosító pontjait, elsősorban a váltókat, azok sorrendjét tárolja. Ha a pályán módosítás történik, akkor a nyomvonal tárolt pályaelem-sorrendje nem fog megegyezni a pályán lévővel, így a hiba helyén eltörik a nyomvonal. Ezt piros pontokkal, és vonallal jelöli az AE. Meg lehet probálni megjavítani a nyomvonalat az AE-ben, de a további bonyodalmak elkerülése érdekében szerintem ilyenkor érdemes újra meghatározni az egész nyomvonalat. Eltörik a nyomvonal akkor is, ha két váltó csúcsával szemben túl közel van beépítve a pályába. A váltók csúcsa között ezért mindig hagyjunk min. 10 méter távolságot! A problémát az okozza, hogy a nyomvonalban tárolt adatok nem kellően részletesek, így összekeveri a túl közel lévő elemeket. Ez a keveredés máshol is megfigyelhető: váltó közelébe soha ne rakjunk Reverse point-ot, mert a közel futó vágányok esetén a TS nem biztos, hogy arra a vágányra tárolja el a fordulópontot, mint amelyikre szeretnénk. Sőt extrém esetben (tapasztalat!) a váltót átállítja a nyomvonalnak megfelelően, de a Reverse point-ot a váltó másik szárára teszi, így hiba (Broken path) ugyan nem lesz, de az activity játszhatatlan lesz, mert a fordulópontot nem tudjuk a vonattal elérni. A TS nyomvonalbeli „melléfogásai” egyébként sok probléma hibaforrása. Előfordul kereszteződések – főleg az 5 részből összerakott angolváltó – esetén, hogy a tárolt keresztezési pont (lásd tsection.dat, XoverPt ( bejegyzés) sem a megfelelő helyre kerül a vágányok logikai adathalmazában, így ilyen esetekben gyakran előáll, hogy két vonat közlekedése esetén a TS nem veszi figyelembe az egymást keresztező útvonalakat. (Ellenőrzésre a Track Viewer program használható, mely megjeleníti a keresztezési pontok helyét, így láthatóvá válik, hogy hol van probléma a keresztezéssel.) 7.5.2. A nyomvonal és az AI-vonatok Amennyiben a pályán a játékos vonata mellett más, AI-vonatok is közlekednek, és ezek útvonala keresztezi, vagy fedi egymást, nagy gondossággal kell eljárni a nyomvonalak kialakításában. A nyomvonalak felépülése a pályán a vonat indulásának pillanatában történik, és ezek a nyomvonalak nincsenek egymásra tekintettel. A nyomvonalak felépülése a start ponttól kezdődik. A nyomvonal beállítja maga számára a váltókat, de csak azokat, amelyeket más nyomvonal még nem foglalt le, majd lefoglalja a maga számára. A nyomvonal felépülése vagy a végpontig, vagy egy ilyen lefoglalt váltóig, vagy egy forduló pontig (Reverse point) történik. Itt kell megemlíteni, hogy a TS-ben kétféle váltó létezik: automata és manuális (ez utóbbi neve egy Mnl kiegészítést tartalmaz). A két váltó között az a különbség, hogy míg az automata váltó mind a játékos, mind az AI-vonatok nyomvonala által állítható (amennyien már nem foglalt a váltó), addig a manuális váltó az AI-vonatok nyomvonala számára csak addig állítható, míg a játékos nyomvonala (vagy a játékos maga a G gombbal) nem állította át egyszer. A manuális váltó ezen kívül a játékban kézzel is állítható még akkor is, ha azt egy AI-vonat nyomvonala már lefoglalta. Ezen okból nem mindegy, hogy milyen váltókból épült fel a pálya. Az automata váltók a vonattalálkozásokra alkalmas állomásokon szükségesek, míg a manuális váltók a rakodóvágányok, rendezőpályaudvarok szükséges eleme. A másik fontos jelenség a jelzők kezelése. A jelzők a lefoglalt nyomvonal mentén nem állnak egyből szabadra, hanem a konfigurációs fájlukban beállított szakasz-számmal a vonat előtt jelenik csak meg rajtuk a szabad jelzési kép. Amíg nem jelenik meg a lefoglalt nyomvonalon a jelzési kép, addig a játékos nyomvonala (vagy más AI-vonat) „kitúrhatja” az AIvonat nyomvonalát. Fordítva viszont ez nem igaz. A játékos vonatának elsőbbsége van. A problémánk akkor lép fel, ha pont az AI-vonatnak szeretnénk elsőbbséget adni (pl.: megelőzés, stb.). A nyomvonalak kialakításánál ha lehet, kerüljük az egymást keresztező nyomvonalakat, elsősorban azokat, amelyek részeiben sem közös nyomvonalon futnak (pl.: keresztezés, angolváltón keresztező nyomvonalak). Alkalmazzunk helyettük olyan nyomvonalakat, melyeknek van közös szakaszuk, így ott a TS számára is egyértelműen csak egy vonat tartózkodhat. Kerülendő az egymást nem keresztező, de egymáshoz túl közel futó nyomvonalak használata is (pl.: angolváltó két íves irányának egyidejű használata). A lenti ábrán a nyomvonalak rossz és jó elhelyezése látható. Az ábra

39

csak a nyomvonalak kialakítására vonatkozik, nem az egymás veszélyeztető menetekre! Az alábbi rossz nyomvonalkialakítás eredményére a jelzők nem biztos, hogy Megállj! állásba kerülnek a fent leírt okok miatt!

7.5.3. Néhány példa Adott az ábrán látható állomás mindkét végén egy-egy automata váltóval. Egyik irányból egy AI-vonat, másikból a játékos közelít. Tételezzük fel, hogy egyszerre érnek oda, és így nincs gond az előrefutó nyomvonallal (lásd később).

Mindkét nyomvonal a túlsó oldali váltóig fut előre, de mivel az a másik nyomvonal által már lefoglalt, automata váltó esetén nem állítja át azt. Bármely vonat elhaladása esetén a váltó lefoglalása megszűnik, a másik nyomvonal átállítja azt, a jelző szabadra vált, és elhaladhat mindkét vonat. Ez egy elméleti működés, időnként, a vonatok pontos időzítésével sikerül kialakítani. Az esetek többségében azonban ez nem egy biztos megoldás. A probélmát az okozza, hogy az egyik vonat korábban indul a nyomvonala kezdőpontjából. Így ha a játékos indul előbb, a nyomvonala végigfut és lefoglalja a fenti állomás mindkét váltóját. Ekkor az AI-vonat nyomvonala már nem képes ezt magának állítani, és – a jelzőktől függően – a nyíltvonalon , vagy az állomás bejárati jelzőjénél néznek majd egymással szembe a vonatok. A játékos a szembejövő vonat miatt nem tud haladni, az pedig nem tudja átállítani a váltót, hogy félreálljon. A másik lehetőség, hogy az AI-vonat indul előbb. Ekkor az okozza a problémát, ha az AI már oly mértékben megközelítette az állomást, hogy számára már a kijárati jelzők is szabadra álltak. Ha csak ekkor indul a játékos, és fut előre a nyomvonala, az AI-vonat által már végérvényesen lefoglalt váltót nem képes állítani, az AI-vonattal a nyíltvonalon találkozhat. A legjobb eset, ha az AI egy kicsit korábban érkezik, de ez nem mindig megvalósítható. A megoldást a problémára később mutatom be. Más a helyzet manuális váltó esetén. A manuális váltó az AI-nak csak akkor engedelmeskedik, ha a játékos nyomvonala még nem állította azt át. Így ha a fenti legideálisabb esetet is vesszük figyelembe, legfeljebb csak az állomásra tud behaladni, a legritkább esetben tud csak kihaladni onnan, mivel a játékos az AI-vonat kijárati váltóját már ellentétes irányba állította. Kihaladni akkor tud, ha a játékos a manuális váltót kézzel visszaállítja, illetve egy, a kritikus kijárati váltóval „szoros kapcsolatban” lévő másik váltót átállít. (Ezen azt értem, hogy a TS nem csak egyenként állítja a váltókat, hanem esetenként – ha a vágánygeometria olyan – egy másik váltót is átállít. Például a fenti ábrán az állomás mindkét váltója átáll, ha az egyik váltót játékosként átállítjuk. A TS nem ismeri a váltófelvágás esetét, a gyökkel érintett váltókat az esetek többségében automatikusan a megfelelő állásba állítja.) A manuális váltós állomáson ezen felül a fent leírt késedelmes indulások itt is ugyanúgy problémát okoznak. („Jó” példa a manuális váltók okozta problémára a Bakony pálya (V1.2), mely sajnos manuális váltókkal van megépítve.) A maunális váltó előnye viszont, hogy olyan esetben is állítható, ha ezt a nyomvonal nem engedné meg. Így például az ábrán jelölt rakodóvágányra manuális váltó esetén anélkül lehet kocsikat állítani, hogy a nyomvonalba forduló pontokat (Reverse point) kellene beépíteni. (Ha ez után a művelet után egy AI-vonat jár erre, csak akkor tud majd továbbhaladni, ha a váltót visszaállítottuk egyenesbe!)

40

7.5.4. Trükkök, tippek a nyomvonal kialakításánál A vonattalálkozások megfelelően lebonyolíthatók néhány trükk segítségével. Az egyik: a dupla fordulópont megoldás. A trükk lényege, hogy a fordulópont megfogja a nyomvonalak felépülését. A nyomvonal csak a fordulópontig fut, majd csak akkor épül tovább – a másik irányba – ha a vonat érintette a fordulópontot. A legnagyobb problémát a játékos nyomvonalának előnye jelenti. Emiatt fordulópontokkal térben lekorlátozzuk a nyomvonal lefoglalását. Azon az állomáson, ahol a játékos vonatát meg akarjuk állítani, a megállás helyéhez (a megálló vonat eleje és vége közti szakaszra valahova) lehelyezünk egy fordulópontot, majd közvetlenül (viszonylag közel) mögé egy másikat. A vonattalálkozás a fenti ábrán látható állomáson ilyenkor a következőképpen zajlik. A játékos indulásakor a nyomvonala végigfut, beállítja a bejárati váltót, lefoglalja, majd az elsőként lehelyezett fordulópontot elérve megáll, várakozik mindaddig, amíg a játékos a vonatával oda nem ér. Az AI-vonat – mivel a másik oldali váltó szabad – beállítja a maga számára azt, és lefoglalja. Az AI nyomvonala a játékos nyomvonala által lefoglalt váltónál áll meg. Ha az AI-vonat közel ért, a jelzőt is szabadra állítja maga előtt, majd behalad az állomásra. A találkozást úgy kell időzíteni, hogy az AI-vonat legkésőbb akkor kerüljön olyan távolságba az állomástól, hogy számára a bejárati jelző szabadra álljon, mielőtt a játékos vonata megállna az első fodulópont felett. Mivel a jelzőállítási távolság 2-3 jelzőtávolság szokott lenni, ez lényegesen nagyobb időintervallumot jelent, mint a korábbi esetben. Jelzőkitűzéstől függően akár 5-10-20 perc idő is eltelhet az AI-vonat bejárati jelzőjének szabadra állásától a megérkezéséig. Ez elegendő idő arra, hogy jól beállítható legyen még nagy tűréssel is a játékos megérkezése (vagy ha tetszik fordítva, az AI megérkezése) anélkül, hogy az AI-vonatnak meg kellene állnia. A játékos megérkezésekor megáll vonatával a fordulópont felett. Ekkor az első fordulópont után továbbindul nyomvonala a második fordulóponthoz, itt megáll, majd várna, de mivel a feltételek adottak – a játékos vonata a fordulópont felett áll – már fut is tovább – újra előre – és amennyiben teheti, átállítja a váltót, lefoglalja és fut tovább. Mivel ekkorra az AI-vonatnak már – jól beállított esetben – áll a szabad jelzés a bejárati jelzőn, a játékos nyomvonala vár a kijárati váltó felszabadulásáig. Amennyiben túl későn jön az AI (túl korán érkezik a játékos) a játékos megáll az első fordulópont felett, a fent leírt elven továbbfut a nyomvonala, és „kitúrja” az AI-vonatot a kijárati váltóról, mivel az még messze jár. Egyes esetekben, ha ilyenkor a játékos megáll, és a féket behúzva tartja, a vonata nem mozdul meg egy centit sem hátrafelé, folyamat állva maradhat, és megérkezhet az AI anélkül, hogy a játékos „kitúrná” a váltóról. Ez utóbbi esetre viszont megbízhatatlansága miatt nem lehet számolni, az AI és a játékos vonatának indulását jól be kell időzíteni. Ugyanezen okra vezethető vissza, ha az AI elhaladása után nem akar szabadra váltani a jelző. Ilyenkor meg kell mozdítani egy picit a vonatot hátrafelé, hogy a folyamat tovább induljon, a hatás azonnali lesz. Ugyanezen elven működik a játékos vonatának megelőztetése az AI-vonattal. Ez esetben arra kell törekedni, hogy a játékos félreállásakor az AI lehetőleg már jelzőtávolságban mögötte ballagjon, hogy amint felszabadul a játékos mögött a váltó, az AI nyomvonala előrefuthasson, és a játékos előtti váltót lefoglalhassa, majd a jelzőt is szabadra állíthassa a maga számára. Ha a játékos félreállásakor az AI még túl messze jár, előfordulhat, hogy nem engedi előre az AI-t. Ugyanezen módszer alkalmazható AI vonatok esetében is, ha valamilyen okból kifolyólag az AI nyomvonala „túl agresszív” lenne és nem engedné el a játékost. Természetesen ilyenkor az AI nem vár a dupla fordulóponton, csak megáll, tolat egy kicsit, majd újra elindul előre. (Ez esetenként elég furán nézhet ki, ezért lehetőleg csak olyan helyen használjuk, ahol nincs a játékos a közelben.) A másik, kizárólag AI-vonatokhoz alkalmazható megoldás a Passing path (átmenő nyom) alkalmazása. Ezt a Begin passing path parancs kiválasztásával adhatjuk meg. Lényege, hogy egy kitérőtől a kitérő másik ágán át egy másodrendű útvonalat adhatunk meg. Abban az esetben, ha az első foglalt lenne az AI-vonat a második irányba fog közlekedni. A második nyom felépülése az adott kitérő másik ágából indul és a soron következő váltók egyenes ágán fut tovább, szerencsésebb esetben az eredeti nyomvonalig. Egyszerűbb állomásokon (mint a fenti példa) tökéletes megoldást adhat. Amennyiben nem jön másik vonat, mely foglalná az eredeti nyomvonalat, az AI-vonat az eredeti nyomvonalon halad. Ha viszont érkezik másik vonat addig, amíg szabadra nem áll az adott vágányszakaszt fedező (állomás esetén bejárati) jelző az AI-vonat számára, és a szemből érkező vonat az AI elsődleges útvonalát foglalja le, az AI a második nyomvonalon folytatja útját. Nagyon fontos szabály ez esetben, de más esetben is, hogy ne indítsunk úgy AI vonatot a vonalról, ha a közelében már egy másik vonat jelző szabadra állításával olyan váltót foglal le, amit a „ledobott” másiknak állítani kellene. Pl.: adott az ábrasoron látható helyzet. Mindkét vonat AI-vonat (a jobb oldali lehet a játékos is).

Közeledik jobbról egy vonat.

41

A váltó átáll egyenesbe, lefoglalásra kerül, majd a jelző is szabadra áll. A vonat még 2-3 (jelzőprogramozástól függ) jelzőnyi távolságban van.

Tovább közeledik a vonat.

Ebben a pillanatban elindul egy AI-vonat a nyílt vonalról. A váltó előtti jelző STOP állásba kerül a vonalszakasz foglaltsága miatt. A jobbról érkező vonat megáll a jelzőnél.

A balról érkező vonat a másik jelzőnél áll meg, mert a váltót a jobbról érkező vonat foglalja, ezért azt átállítani sem tudja (még automata váltó esetén sem!), a jelző sem tud szabadra váltani. Abszolút PATT-helyzet! A megoldás a következő lenne:

A bal oldali AI-vonat korábban megjelenik a vonalon. Mivel korábban indul, messzebbről kell indítani, hogy ugyanakkor érjen az állomásra.

Így a váltót kitérőbe állítja, majd lefoglalja, és szabadra állítja a bejárati jelzőt.

A jobb oldali vonat kijárati jelzője nem áll szabadra, mert nem tudja egyenesbe állítani a váltót.

A bal oldali behalad, a váltó felszabadul a jobb oldali egyenesbe állítja, a jelző szabdra vált.

Mindkét vonat folytatja útját. 42

7.5.5. Problémák a fordulóponttal „Természetesen” a fordulópontnak is van hibája a TS-ben. Amennyiben a játékos mozdonyához Loose consist kocsikat kapcsol a mozdony elejére, úgy adott esetben hátrafelé mozgáskor, a kocsikat húzva sosem sikerül elérni a fordulópontot, az egyre nagyobb távolságra tolódik hátrafelé. A problémának csak a létezéséről tudok, kiküszöbölésére megoldást még nem hallottam, nem találtam. A másik probléma a fordulópont rossz elhelyezése egy tolatásnál. A fordulópont úgy aktivizálódik (indul el a nyomvonal felépülése a másik irányba), ha két feltétel teljesül: a vonat elérte a fordulópontot, és megállt. Amennyiben a fordulópontot túl közel helyezzük ahhoz a váltóhoz melynek az irányváltás után át kell állnia, problémák léphetnek fel. Ha ugyanis egy hosszabb vonat a fordulópontot elérve úgy áll meg, hogy a vonat vége rálóg az állítandó váltóra, a nyomvonal továbbépülése a másik irányba megszakad, mert nem tudja átállítani a váltót. A fordulópont eltűnik, a váltó nem állt át: a játék folytatása lehetetlen. Amennyiben a vonattal úgy állunk meg közel lerakott fordulópont esetén is, hogy nincs rajta a vonat vége a váltón, nem történik baj. Tehát elvileg ez nem lenne probléma, viszont a játékos ember, és tévedhet, főleg, ha nincs kellőképpen tájékoztatva. A megoldás, hogy vagy olyan messzire visszük a pontot, hogy azt elérve már ne lehessen a vonat a váltón, vagy tájékoztatjuk erről a játékost, és megbízunk benne. Én a biztonság kedvéért az első megoldást szoktam választani. 7.6. A játékos tevékenysége Vissza a Service Editor ablakba. Létrehoztunk egy szerelvény, és kialakítottunk egy megfelelő nyomvonalat. Mi még a teendőnk? A legfontosabb dolgunk még az activity kezdeti időpontjának beállítása a Player rész Start time számlálóival. Ez lesz az az időpont, amikor a játékos belép a játékba. AI-vonatok természetesen korábban is közlekedhetnek a szimuláció kedvéért, azért, hogy előálljon egy időben pontos állapot. Amennyiben személyszállító vonatról van szó, és azt szeretnénk, ha annak kötelező megállásai lennének bizonyos peronoknál, akkor a Stops listában található peronok közül pipával jelöljük ki azokat, ahol a vonatnak meg kell állnia. Amennyiben ezzel végeztünk, klikkeljük az OK gombra. Ezzel a .SRV fájl mentődik a Service könyvtárba. Ezzel létrehoztunk egy tevékenységet. Akár el is menthetnénk, mivel ez így már működőképes, de még nem teljesen tökéletes. Személyszállító vonat esetén nincs menetrendünk, ami alapján közlekedhetnénk. Hát hozzuk létre: klikkeljünk az Activity Editor jobb oldali Player részében található Edit timetable gombra. A megjelenő ablakban látható azon állomások listája, amelyeket a Service Editor ablakban kiválasztottunk. Mindegyikhez tartozik egy kiválasztó négyzet, egy állomásnév, egy érkezési, egy indulási idő, és egy teljesítményérték. Lent két gomb található: Recalculate this és Cancel. Amennyiben raklikkelünk a Recalculate this gombra a TS kiszámolja a menetrendet. A Cancel gomb megszakíthatjuk a számolást. A kilépés az X gomb megnyomásával történik, ekkor is rögzítődnek az adatok. A számolásban időnként nem tökéletes az Activity Editor. Bonyolult, vagy fordulópontokat tartalmazó nyomvonalak esetén nem képes normális menetrend kiszámítására. Ekkor nincs más, mint a kézi javítás. Módosíthatjuk is az időadatokat a Timetable ablakban is, de nem túl egyszerűen: - Klikkeljük az Arrive (érkezés) időadatra annál az állomásnál, ahol változtatni akarunk. - A megjelenő kis ablakba írjuk be az érkezési időt. - Klikkeljük újra az Arrive (érkezés) időadatra annál az állomásnál, ahol változtatni akarunk. - A megjelenő kis ablakba most az indulási időt írjuk be! - Klikkeljük újra még egyszer az Arrive (érkezés) időadatra annál az állomásnál, ahol változtatni akarunk. - A megjelenő kis ablakba írjuk be újra az érkezési időt. Ez a módszer elég nehézkes, választhatunk másikat is. Mint később látni fogjuk, az időadatot a TS eltárolja az activity fájljaiba. A tárolás módja, hogy az időt másodpercben számlálja. Azaz azt az értéket tárolja időként ahány másodperc 0 óra 0 perc 0 másodperctől eltelt. Tehát pl.: 8:20 az ( 8 x 60 x 60 ) + ( 20 x 60 ) = 30000 másodperc lesz. Ezt elvileg kézzel is át lehet írni a megfelelő helyeken, de mindezt elintézi helyettük Ptrmarci által készített Menetrendszerkesztő programja is. Használata gyors, átlátható és kényelmes. Ha egyszer már módosítottuk a menetrendet, ne klikkeljünk a Recalculate gombra, de ne is módosítsunk se a nyomvonalon, se a tevékenységen, mert akkor a TS nullázza az időadatokat! Érdemes a legvégén megcsinálni a menetrend módosítását. Gőz- illetve dízelmozdonyos szerelvény esetén a Player rész Fuel status csúszkáival beállíthatjuk az activity indulásakor a járművekben található üzemanyag mennyiségét. Így például a fogyatkozó üzemanyag feltölthető lesz az üzemanyagfeladó helyeken, illetve a pazarló üzemanyagfelhasználás az activity sikertelen végét jelentheti.

43

A Player Service (később Traffic Service) ablak OK gombbal bezárásakor a .SRV fájlba elmentődnek a tevékenység adatai. A fájl az alábbi adatokat tartalmazza: - Az összes bejegyzést a Service_Definition ( bejegyzés foglalja keretbe. - A Serial ( bejegyzés nem tudom, mire való. - A Name ( bejegyzés a tevékenység nevét tartalmazza. - A Train_Config ( bejegyzés a Consist nevét tartalmazza. - A PathID ( a nyomvonal nevét tartalmazza. - A MaxWheelAcceleration ( bejegyzéssel – feltételezem – a jármű maximális gyorsulása adható meg. Sosem használtam, AE-ből nem állítható. - Az Efficiency ( értéke a menetrend szorosságára utal (lásd: Expected player performance). - A TimeTable ( bejegyzés a nevével ellentétben nem a menetrendet, csak a megállások helyét tartalmazza. A StartingSpeed (, EndingSpeed ( bejegyzésekkel a korábban megismert indulási- és végsebességek állíthatók be. A StartInWorld (, EndInWorld ( bejegyzések jelentése számomra rejtély. A StationStop ( bejegyzésben a megállóhelyek adatai láthatók: a PlatformStartID ( a peron kezdetének hivatkozási számát, a DistanceDownPath ( bejegyzés a kezdőponttól mért távolságát tartalmazza. A SkipCount ( egy számláló. 7.7. Egyéb műveletek A térkép bizonyos pontjaira klikkelve a jobb gombbal különböző lehetőségeket felsorakoztató menü jelenik meg. A vágányon klikkelve a következők a lehetőségeink: - A Place loose consist menüponttal helyezhetünk a pályára álló szerelvényeket. Vigyázzunk, hogy hova helyezzük ezeket, mert ezek ugyanúgy foglaltságot okoznak a jelzők számára mint bármely más vonat! A felugró ablakban megjelenő legördülő menüből választhatunk szerelvényt, illetve a már jól ismert New, Edit, Use as template, Delete gombokkal kezelhetjük azokat. Az OK gomb lenyomására a kiválasztott szerelvényt jelképező lila téglalapok jelennek meg a vágányon. A kocsikat ekkor nem tudjuk szétkapcsolni, a szerelvényt egyben kell mozgatnunk a megfelelő helyre. A téglán lévő karika a jármű hátulját szimbolizálja. - A Place location event menüponttal hely elérésekor aktivizálódó hatás állítható be. A hatásokról később részletesen írok. - A Define restricted speed zone (start) menüpontokkal kijelölhetjük az ideiglenesen lassan bejárandó pályarészek kezdő- és végpontját. A kijelölt helyre piros zászlót tesz, majd az egér mozgatásával a vágány mellé piros vonalat húzhatunk. Újabb klikkelésre rögzítődik a piros vonal vége. Ez lesz az ideiglenesen lassan bejárandó pályaszakasz. Az activity folyamán ezen a szakaszon a Route Editorban külön meghatározott sebességgel lehet csak haladni. Egy már lerakott loose consiston klikkelve a következők a lehetőségeink: - A Toggle consist direction menüponttal a szerelvényt meg tudjuk fordítani a vágányon. - A Propeties paranccsal előhívhatjuk a Consist Editor ablakot, és módosíthatjuk azt. - A Delete paranccsal letörölhetjük azt a pályáról. Egy jelzőn klikkelve a következők a lehetőségeink: - A Toggle signal failed paranccsal a jelző működését felfüggeszthetjük, a Track Monitoron a jelzőt ábrázoló pont szürke lesz majd, és a jelző meghaladása is csak a TAB gomb lenyomásával lehetséges. Egy peron egyik végén klikkelve a következők a lehetőségeink: - A Properties paranccsal megnyílik egy ablak, ahol a peronon fel- és leszálló utasok mennyisége állítható be. Az utasok mennyisége alapvetően a Route Editorban a Platform objektum tulajdonságainál szerepel, de ezt itt megváltoztathatjuk. Az utasmennyiség a vonat kötelező várakozási idejét befolyásolja, így az AI-vonatok hosszabb tartózkodása is beállítható vele (2 utas = kb. 1 sec.)

44

7.7.1. Consist készítése Explore Route módhoz Amennyiben csak az Explore Route módhoz szeretnénk egy szerelvényt összeállítani (és nem rendelkezünk a ConBuilder segédprogrammal) úgy a legegyszerűbb módon így hozhatunk létre szerelvényt: - Indítsuk el az Activity Editort. - Válasszunk ki egy tetszőleges pályát. - Kezdjünk egy új activityt a File menü New parancsával. - A térkép megjelenése után klikkeljünk jobb gombbal a vágányok valamelyikére, - majd a menüből válasszuk ki a Place loose consist pontot. - A megjelenő ablakban válasszuk a New gombot, majd a korábban leírt módon készítsünk szerelvényt. - A Save & Exit gomb megnyomásával elmentjük a szerelvényt. - A kis ablakból ezután már kiléphetünk a Cancel gomb segítségével, majd az Activity Editort is bezárhatjuk mentés nélkül. 7.8. Hogyan ér véget a activity – hatások Az eddigiek folyamán létrehoztuk a szerelvényt, az útvonalat, összefoglaltuk öket a tevékenységben, elvégeztünk szükséges beállításokat. Még egy fontos dolgunk van: meghatározni a feladato(ka)t, hogy mi is legyen a célja az activitynek. A célokból akár több is lehet: akár több végkifejlet, vagy több, egymásra előfeltételként épülő feladat is. Mindezek beállítása hatások (Event) segítségével lehetséges. Háromféle Event létezik a TS-ben: - Location Event: A hatás aktivizálója egy hely - Action Event: A hatás aktivizálója egy körülmény - Time Event: A hatás aktivizálója egy időpont Mindhárom hatás egyformán működik, a beállító ablakuk is csak a kiváltó ok résznél tér el egymástól. A beállított hatások listája a három típusnak megfelelően három ablakban látható. Ezek alapesetben nincsenek nyitva, de megjeleníthetők a Window menü Action event window, Time event window, Location event window parancsaival. Mindhárom ablakban egy New gombot (közvetlenül a fejléc alatt; Ott van az! Na ugye...) és egy listát lehet látni. Új activity esetén csupán az Action event ablakában van egy Default event bejegyzés. Mindhárom hatás ezekből az ablakokból készíthető, illetve kezelhető. A listában szereplő Event-re klikkeléssel megnyílik az Event properties ablaka (lásd lent). 7.8.1. Hely elérésére aktivizálódó hatás A Location event lehelyezésekor először is meg kell adni a hatás helyét. Ehhez a vágányra kell klikkelni, ahol megjelenik egy kör és mellette egy szám. A megjelenő Location event propeties ablak legfelső részén a Location részben állítható be a hatást kiváltó hely tulajdonságai: - A Location event number a hely sorszámát adja meg. - A Radius (meters) számlálóban 1-99 méter értékben adhatjuk meg a lehelyezett kör sugarát. Az aktivizálódás a kör elérésekor következik be. - A Train must stop opció bejelölésével kiköthetjük, hogy a vonat csak akkor aktivizálja a hatást, ha a körön belül áll meg. 7.8.2. Körülményre aktivizálódó hatás Action event létrehozásakor szintén meg kell adni a kiváltó okot. Az Action event propeties ablak felső részében ilyenkor egy Action rész látható, benne a következő sorokkal: - Egy legördülő menü, melyből kiválasztható a kiváltó ok. Ezek az alábbiak lehetnek: o Stop at final station: Megállás az utolsó állomáson. Személyszállító vonatok esetén a Player Service ablak megállóhelyek listájában utolsónak bepipált állomáson való megállás és az utasok leszállítására (Enter gomb megnyomására) aktivizálódik. A Default event-nek is ez van beállítva. o Pick up passangers: Utasok felvétele. Ez körülbelül ugyanaz, mint az előző, csak nincs helyhez (utolsó megállóhoz) kötve. Amennyiben a személyszállító vonat megáll, és (Enter megnyomására) utasokat vesz fel, ez a hatás aktivizálódik. o Make a pickup: Üzemanyagfeltöltés. Feltehetően ez a hatás üzemanyag feltöltéskor aktivizálódik. o Reach speed: Sebesség elérése. A beállított sebesség elérésekor aktivizálódik. Az elérendő sebességet külön ablakban kell megadni. o Pick up cars: Kocsik felvétele. A pályára helyezett Loose consist szerelvények kiválasztott kocsijainak a játékos vonatához kapcsolására aktivizálódó hatás.

45

Drop off cars at location: Kocsik lerakása adott helyen. A pályára helyezett Loose consist szerelvények kiválasztott kocsijainak adott helyen való lekapcsolásakor aktivizálódik a hatás. A hely vagy Siding lesz, vagy egy névtelen vágány. Míg előbbi esetben a program automatikusan beírja a nevét, addig a második esetben nekünk kell megadni nevet a vágány számára. o Assemble train: Vonatösszeállítás. Egy szerelvény kocsijainak megadott sorrendben való összeállítására aktivizálódik. A kocsik sorrendjének egyezni kell a megadottal (Work order). o Assemble train at location: Vonatösszeállítás adott helyen. Egy szerelvény kocsijainak megadott sorrendben, megadott helyen való összeállítására aktivizálódik. A hely vagy Siding lesz, vagy egy névtelen vágány. Míg előbbi esetben a program automatikusan beírja a nevét, addig a második esetben nekünk kell megadni nevet a vágány számára. A kocsik sorrendjének egyezni kell a megadottal (Work order). A következő sorban az egyes esetekben kötelezően megadandó vágány neve lesz látható. Az alatta lévő listában az esetenként szükséges Loose consist szerelvények kocsijainak száma, esetenként kijelölt helye látható. A listába kocsik az Add gombbal egyenként vehetők fel. A Delete gomb segítségével törölhetők a kocsik a listából. A listában azonos kocsi kétszer ne szerepeljen, mert ez a TS fagyását okozhatja! o

-

7.8.3. Időpontban aktivizálódó hatás Time event létrehozásakor egy időpontot kell megadni a Time event propeties ablak felső Time részében. Az óra, perc és másodperc számlálókon nem az aktuális időt, hanem az activity kezdési időpontjától eltelt időpontot kell megadni. Tehát pl.: ha egy activity 10:00-kor kezdődik, és azt szeretnénk, hogy 15 perc múlva aktivizálódjon egy hatás, akkor ide 0 óra 15 perc 0 másodpercet kell beírnunk. 7.8.4. Az aktivizált hatás Míg a hatások különböző kiváltó okokra aktivizálódnak, a kiváltott hatás és beállítása mindhárom esetben ugyanaz. Mindhárom Event propeties ablak a felső részt kivéve azonos tartalmú. Az Event részben a következők állíthatók be: - Activation level: aktivizálódási szint. Ahhoz hogy egy hatás aktivizálódjon nem csak a kiváltó oknak, hanem az úgynevezett aktivizálódási szintnek is 1 értékűnek kell lennie. Itt ez az aktivizálódási szint állítható más értékre. Ennek később lesz jelentősége. (Lásd a következő fejezetet.) - Triggered text: szöveg aktivizálódott állapot esetén. Az ide beírt szöveg fog megjelenni a végső értékeléskor, ha a hatás aktivizálódott. - Untriggered text: szöveg nem aktivizálódott állapot esetén. Az ide beírt szöveg fog megjelenni a végső értékeléskor, ha a hatás nem aktivizálódott. - Notes: megjegyzések. Az activity készítője számára hely jegyzetek beírására. Az activityben nem jelenik meg. A kiváltó ok hatást vált ki. A kiváltott hatások száma egytől 4-ig terjedhet (03-ig számozva.) A hatások számát a Number of outcomes számlálóban adhatjuk meg. A hatások ez alatt láthatók, több hatás esetén egymás alatt – ekkor a fülekkel válthatunk köztük. A hatások tartalma a következő: - Outcome: kimenetel. A legördülő menüből a következő hatásokat választhatjuk ki: o None: nincs kiváltott hatás. Erre is szükség lehet… o Increase an event’s activation level by one: eggyel növeli a kijelölt hatás aktivizálódási szintjét. Ezzel az opcióval lehet a korábban 1 értékről alacsonyabb értékre állított hatás aktivizálódási szintjének 1 egységgel emelését (egyesével, azaz egy hatás eggyel emel) megvalósítani. (Lásd a következő fejezetet.) o Decrease an event’s activation level by one: eggyel csökkenti a kijelölt hatás aktivizálódási szintjét. Ezzel az opcióval lehet a korábban 1 értékről magasabb értékre állított hatás aktivizálódási szintjének 1 egységgel csökkentését (egyesével, azaz egy hatás eggyel csökkent) megvalósítani. (Lásd a következő fejezetet.)

46

Activate an event: 1-re állítja a kijelölt hatás aktivizálódási szintjét. Ezzel az opcióval lehet a korábban 1 értékről magasabb, vagy alacsonyabb értékre állított hatás aktivizálódási szintjének 1-re állítását (egyszere, azaz mindegy mennyi volt, 1 lesz) megvalósítani. (Lásd a következő fejezetet.) o Restore an activation event level to original value: visszaállítja a kijelölt hatás aktivizálódási szintjét az eredeti értékre. Ezzel az opcióval lehetséges a játék folyamán módosult aktivizálódási szint eredeti értékre való visszaállítása. (Lásd a következő fejezetet.) o Display a message: üzenet kiírása a játék során ablakba. o Complete activity sucessfully: activity sikeres befejezése. A hatás aktivizálódására befejeződik az activity, pozitív eredménnyel. o End activity without sucess: activity sikertelen befejezése. A hatás aktivizálódására befejeződik az activity, negatív eredménnyel. o Start ignoring speed limits: a hatás feloldja a sebességkorlátozás betartásának kötelezettségét. o Stop ignoring speed limits: a hatás megszünteti a sebességkorlátozás betartásának kötelezettségének feloldását. A sebességkorlátozást ettől a ponttól újra be kell tartani. A Reversable pipa kijelölésével amennyiben megszűnik a kiváltó ok, a változások is megszűnnek. Pl.: ha kocsi felkapcsolása (Pick up cars) okára a hatás emeli egy másik hatás aktivizálódási szintjét eggyel, akkor ha ez az opció be van jelölve, és a kocsit leakasztjuk, a kimenetel is megszűnik, azaz a kijelölt másik hatás aktivizálódási szintje vissza lecsökken eggyel. Event: ráhatás valamire. Egyes kimenetelek, hatások esetén meg kell adnunk egy másik hatást, amire az hat. Edit message gomb segítségével a Display a message kimenetel esetén adhatunk meg a képernyőn a játék közben ablakban megjelenő maximum 256 karakter hosszú szöveget. o

-

-

7.8.5. Az aktivizálódási szint – magyarázat Az aktivizálódási szint egy számérték. Alapesetben 1 az értéke. A játék indulásakor az aktivizálódási szint értéke minden beállított hatás (Event) esetében 1. Amennyiben az egyes Event-eknél az aktivizálódási szintet (Activation level) átállítjuk más értékre, úgy a hatás csak akkor aktivizálódik, ha a feltétel teljesülése mellett az aktivizálódási szintje is visszaállításra kerül 1 értékre. Ez történhet lépésenként fel és le is, és történhet egyszerre is, de lehetőség van az eredeti kiindulási érték visszaállítására is. Nézzünk egy egyszerű példát: Action0

Location0

Location1

A Location0 egy Location Event (hely elérésére aktivizálódó hatás): - Az aktivizálódási szintje: 1 - Az egyetlen kimenetele: Display a message – azaz szöveg kiírása a képernyőre. (A váltó után állj meg, tolass vissza, majd kapcsod a vonathoz az ott álló kocsit. 10 perced van a műveletre.) Az Action0 egy Action Event (körülményre aktivizálódó hatás): - A kiválasztott ok: Pick up cars – azaz kocsik felvétele. A listába a rakodóvágányon álló kocsit kell felvenni. - Az aktivizálódási szintje: 1 - Az 1. kimenetele: Display a message – azaz szöveg kiírása a képernyőre. (Rendben, mehetünk előre.) - A 2. kimenetele: Increase an event’s activation level by one – azaz növelje a megjelölt Event aktivizálódási szintjét eggyel. - Az megjelölt Event: Location1 A Location1 egy Location Event (hely elérésére aktivizálódó hatás): - Az aktivizálódási szintje: 0 ! - Az 1. kimenetele: Display a message – azaz szöveg kiírása a képernyőre. (Sikeresen teljesítetted a feladatot.) - A 2. kimenetele: Complete activity sucessfully – azaz az activity sikeres befejezése. A Time0 egy Time Event (időre aktivizálódó hatás): - Időbeállítása: 0 óra 10 perc - Az aktivizálódási szintje: 1 - Az 1. kimenetele: Display a message – azaz szöveg kiírása a képernyőre. (Nem teljesítetted időben a feladatot.) - A 2. kimenetele: End activity without sucess – azaz sikertelenül végződik az activity. A feladat nagyon egyszerű: egy tolatás folyamán a rakodóvágányon álló kocsi felvétele a vonatba adott idő alatt. A Location0 hatás kiírja számunkra a feladatot. A Location1 hatás még nem aktív, mivel az aktivizálódási szintje 0, így

47

amikor a vonat eléri, nem aktivizálódik. A vonattal a csonkavágányba visszatolatva felkapcsoljuk az ott álló kocsit. Amint ez a kocsi hozzákapcsolódik a szerelvényhez, az Action0 hatás aktivizálódik, mivel a feltétele teljesült, és az aktivizálódási szintje is 1 értékű volt. Az Action0-nak két kimenetele van: kiír egy információt a képernyőre, és megemeli eggyel a Location1 hatás aktivizálódási szintjét eggyel, azaz 0-ról 1-re. Ezzel a Location1 hatás is élesedett, és amikor a vonat odaér, aktivizálódik. A Location1 kimenetelei információt írnak ki és sikerrel befejezik az activity-t. Az időkorlátról a Time0 hatás gondoskodik: 10 perc letelte után kiír egy szöveget a képernyőre és sikertelen eredménnyel zárja az activity-t. Amennyiben az Action0 hatásnál bejelöljük a Reversable opciót, úgy a Location1 hatás kimenetelei csak akkor hajtódnak végre, ha a vonat a felkapcsolt kocsival együtt ér a Location1 helyéhez. Amennyiben a kocsit korábban újra lekapcsolnánk, a Location1 aktivizálódási szintje újra visszaesne 0 értékre, kikapcsolva ezzel a Location1 aktivizálódásának lehetőségét. Ha nincs bejelölve a fenti opció, úgy a kocsi felkapcsolása után akár le is kapcsolhatnánk, a Location1 aktivizálódási szintje visszavonhatatlanul megnőtt eggyel, azaz Location1 élesedett. 7.9. Activity-k speciális beállításai - időjárás és veszélyek Az Activity Editor jobb alsó sarkában található Conditions and Hazards részben a következő beállítások közül válogathatunk: - Season: évszak. Beállítható, hogy nyár, tél vagy ősz legyen. - Weather: időjárás. Beállítható, hogy napos idő, eső, vagy havazás legyen. - Hazard freq: veszély gyakorisága. A két csúszka segítségével beállítható, hogy a két „mászkáló” objektumfajta milyen valószínűséggel jelenjen meg a pályán. A százalékos érték a letelepített objektumok százalékos megjelenésére vonatkozik. 7.10. Az activity-k kézi módosítása – az .ACT fájl Mint korábban említettem az activity is egy szöveges fájlba kerül elmentésre (az Activity könyvtárba), melyet ugyanúgy lehet kézzel szerkeszteni, mint bármely más fájlt a TS-ben. Természetesen csak azokat a funkciókat érdemes kézzel átírni (alhúzással jelölve), amit az AE-vel nem tudunk megvalósítani. Az .ACT fájl tartalma a következő: - A fájl a Tr_Activity ( bejegyzéssel indul. - A Serial ( bejegyzés nem tudom mire vonatkozik. - A Tr_Activity_Header ( bejegyzésben az activity alap- és speciális beállítása vannak felsorolva, úgy mint: o A RouteID ( bejegyzésben a pálya neve. o A Name ( bejegyzésben az activity neve. o A Desription ( bejegyzésben a leírása. o A Briefing ( bejegyzésben a játék elején megjelenő szöveges információ. o A CompleteActivity ( bejegyzésben feltehetően a befejezhetőségét adhatjuk meg? o A Type ( bejegyzésben a típusát adhatjuk meg (nem tudom mire gondolt itt a Kuju). o A Mode ( bejegyzésben az activity fajtáját adhatjuk meg. A 2 érték játszható activity-re, a 0 érték az ITR-re (Introductory Train Drive – bemutató jellegű vonatozás) vonatkozik. Csak így lehetséges ITR készítése (activity készítése, majd a 2 érték átírása 0-ra). o A StartTime ( bejegyzésben az indulási időt adhatjuk meg. (Feltételezem, hogy ez csak az információs jellegű időadat.) o A Season ( bejegyzésben az évszak adható meg. o A Weather ( bejegyzésben az időjárás adható meg. o A PathID ( bejegyzésben a nyomvonal hivatkozási neve látható. o A StartingSpeed ( bejegyzésben a kezdési sebesség adható meg. o A Duration ( bejyegyzésben az activity időtartama látható. o A Difficulty ( bejegyzésben a nehézségi fok állítható be. o A FuelWater (, FuelCoal (, FuelDiesel ( bejegyzésekben az üzemanyag mennyiségének százalékos értéke látható. - A Tr_Activity_File ( bejegyzésben az activity egyéb adatai láthatók: o A Player_Service_Definition ( részben a játékos tevékenysége szerepel. Első adat az indulási idő (másodpercben 0:00-tól). Ez után következik a Player_Traffic_Definition ( részben az egyes megállási helyek felsorolása. Az ArrivalTime ( az érkezési idő adata, a DepartTime ( az indulási idő adat (másodpercben 0:00-tól). A SkipCount ( egy számláló, majd a DistanceDownPath ( bejegyzés következik, amely a peron helyét adja meg az indulási ponttól méterben. Hasznos lehet menetrend írásánál, ahol fel akarjuk tüntetni a megállók közti távolságokat. A PlatformStartID ( bejegyzés a peron kedőpontjának hivatkozási száma. Ezután a következő megálló hasonló adatai következnek. Ebben a részben – ha szükséges – csak az időadatokat módosítsuk, máshoz ne nyúljunk.

48

Az UID ( egy hivatkozási szám, feltehetően ez a játékban az F7 gombra megjelennő kocsiszámozás első száma. o Az Efficiency ( bejegyzés az egyes megállókhoz megadott nehézsgi fok. o A SkipCount (, DistanceDownPat (, és PlatformStartID ( bejegyzések jelentését lásd fennt. Lehetőleg ne piszkáljuk őket. A NextServiceUID ( bejegyzés a következő tevékenység lehetsége hivatkozási száma. (Tudtomma csak egy lehet, így ennek nem tudom mi értelme van.) NextActivityObjectUID ( bejegyzés feltehetően a követező lehetséges Loose consist „vonatszámát” adja meg. Az Events ( részben kerülnek ffelsorolásra a hatások. Nem részletezném, de itt is ugyanazok az információk találhatók meg, amik az AE-ben is beállíthatók. o

-

7.11. Mesterséges intelligenciájú forgalom – az AI-vonatok Az AI (artifical intelligence – mesterséges intelligencia) vonatok közlekedését a jobb alsó sarokban található Traffic pattern részben adhatjuk meg. Az AI-vonatokat a számítógép vezeti mindenféle körülmény (nyomvonal, jelzők, stb.) figyelembevételével. Az AI-vonatok egyre nem képesek: kocsikat fel- és lekapcsolni, illetve ezen ok miatt a játékos vonatával egyesülni. Érdekességük, hogy amennyiben a jelzők, vagy más körülmény nem akadályozza meg, képesek egymáson keresztülhajtani, de csak abban az esetben nem fog ez problémát okozni, ha egy olyan tile-on történik mindez, ami épp nincs betöltve a memóriába, vagyis a játékos ettől a helytől messze jár. Amennyiben ez a játékos közelében történik, az activity megszakad, az okot siklásnak megjelölve. (Ez akkor lehet bosszantó, ha nem is látja a játékos, hogy 1-2 km-rel távolabb két AI-vonat ütközött.) Ezért, és mert egy rosszul beállított AI-vonat az activity játszhatatlanságát okozhatja, nagy körültekintéssel kell lenni az AI-vonatok beállításánál. A Traffic pattern részben a következő elemeket láthatjuk: - A legördülő listából kiválasztható a meglévő forgalmak valamelyike - A New, Edit, Use as template, Delete gombok ugyanúgy működnek, mint a korábban megismert esetekben (csak azt nem tudom, miért cserélték fel a jól megszokott sorrendet). 7.11.1. Forgalom létrehozása Új forgalom a Traffic pattern részben New gomb megnyomására hozható létre. A gomb megnyomása után két nevet kell megadnunk két ablakban. Az első a fájl neve lesz (a pálya Traffic könyvtárában .TRF kiterjesztéssel), a második a TS-beli hivatkozási név. Ezután a Traffic pattern ablak nyílik meg: - A Name sorban az előbb beírt fájlnév látható. - A Display name sorban az előbb beírt hivatkozási név látható. - A Select service részben az AI-vonat tevékenysége hozható létre. - A legördülő listából a már létrehozott Service választható ki. - Az ez alatt található New, Edit, Use as template, és Delete gombok a fent megismert módon használhatók. - Az ezek alatt található Insert selected service gomb segítségével tudjuk az egyes AI-tevékenységeket az alatta található listába felvenni. A gomb megnyomásakor meg kell adnunk az AItevékenység indulási idejét. - A listában az Insert selected service gombbal felvett tevékenységek neve és indulási ideje látható. A lista egy elemére kattintva az adott AI-vonat menetrendje látható, a Recalculate this gombbal a menetrendje újraszámolható (a korábban megismert módon.). A lista egy elemére jobb gombbal kattintva egy apró menü jön elő, melynek Start time parancsával az indulási idő módosítható, a Delete parancsával pedig a kiválasztott elem törölhető a listából. - A legalsó széles Recalculate all gomb segítségével újraszámolható az összes AI-vonat menetrendje. AI-vonat közlekedtetéséhez készítsünk új Service-t számára. A New gombra klikkelve ugyanaz az ablak jön fel, mint a játékos tevékenységének (Player service) létrehozásakor. Tulajdonképpen ugyanúgy kell eljárnunk, mint akkor: szerelvényt és nyomvonala kell készítenünk (választanunk). A tevékenység létrehozásakor válasszuk ki a listából, majd az Insert selected service gomb megnyomásával az indulási időpont megadása után máris van egy AI-vonatunk. Egy tevékenység több időponttal is beilleszthető a játékba, de túl sűrűn ne indítsuk őket. Arra azért legyünk tekintettel, hogy adott vonatnak el kell hagynia a vágányszakaszt ahhoz, hogy a következő megjelenhessen (különben a játékban hibaüzenetet kapunk). Az sem utolsó szempont, ha hagyunk időt az elsőnek eltávolodni, legalább annyira, hogy legyen mögötte egy jelző, mely fedezi.

49

7.11.2. Az elkészült forgalom tesztelése Az elkészült forgalom tesztelése a térkép alatti eszközökkel lehetséges: - A Time sorban az aktuális időt láthatjuk. - A Time acceleration legördülő listában az idő múlásának gyorsaságát állíthatjuk be a teszt során. Egy több órás activity esetén igen hasznos lehet. - A Play gombbal indíthatjuk el a teszt lejátszását. Elindítás után ez a gomb Stop feliratúra változik, ezzel állíthatjuk meg a teszt futását. - A lenti csúszka is az aktuális időt mutatja, mozgatásával beállítható az idő értéke. Itt kell megemlítenem a Tools menü Verify Starting State parancsát, mely az időpontot az activity kezdési időpontjához állítja, miközben a korábban indított AI-vonatok helyzetét is kiszámítja. A különböző elemek (player service, loose consist, jelzők, AI-vonatok) megjelenítését a View menüben szabályozhatjuk. Ezekre érdemes figyelni, hogy a tesztelés folyamán minden részletet láthassunk. A tesztelés folyamán a vonatok meghatározott sebességgel haladnak, a jelzők szabad és tilos jelzést mutatnak. (Nem látszik, de használják mind a 8 különböző jelzésfogalmat – lásd később). A tesztelés működésében biztosan ugyanúgy játszódik, mint a TS-ben, viszont a vonatok – főként a játékos vonatának – sebessége nem mindig azonos a játékban lévővel. Hogy ez miből adódik, azt nem tudom biztosan. Mindenesetre az Activity Editorban jó eredményt hozó teszt után mindenképpen a játékban is le kell tesztelni az activityt. Ilyenkor ugyanis egy kiélezett helyzetben az AE-ben számított és a játékban megjelenő sebességkülönbségből adódhatnak olyan késések, melyek nagyban befolyásolni tudják egy activity menetét. Acitivity készítés közben többször mentsünk. A Service, Path és Traffic a beállításablakuk bezárásával mentődik, de ahhoz, hogy az Activity is mentve legyen, a File menü Save vagy Save as... parancsát kell használnunk. A Compute and Save parancs hatására képződik egy .ASV kiterjesztésű fájl az Activity könyvtárban, mely a játék számára tartalmaz olyan adatokat, melytől az activity betöltése gyorsabbá válik. 7.12. Javaslat Kezdőknek javasolnám, hogy csak apránként készítsenek activityket. Nem legyen egyből 100 AI-vonat egyvágányú pályán. Először csak Player service-t csináljanak. Majd ha ezt már értik, készítsenek olyan AI-vonatokat, amelyek nem keresztezik a játékos útvonalát. Erre alkalmas egy kétvágányú vonal másik vágány a (szembejövő vonatok.). Aztán később lehet bonyolítani a helyzetet, de mindenképp javasolnám apránként, mert különben nem fogják érteni, mi mitől nem megy. Csak kitartást tudok kívánni! J

50

8. Jelzők programozása A jelzők programozása a SIGCFG.DAT és SIGSCR.DAT fájlokban történik. A SIGCFG.DAT fájlban a jelzők beállítása, a SIGSCR.DAT fájlban a működésük programja (feltételei), a script található. 8.1. A jelzők beállítása – SIGCFG.DAT fájl A fájl első bejegyzése a LightTextures ( bejegyzés. Ezen belül adató meg a fények textúrája. A LightTextures ( bejegyzés után a LightTex ( bejegyzések számát kell megadni. A LightTex ( bejegyzésben sorrendben a következőket kell megadni: - Idézőjelben a textúra hivatkozási nevét. Ezt fogjuk később használni. - A használandó textúrafájl nevét. - Négy számjegyet annak meghatározására, hogy az adott textúrafájl melyik darabját használjuk a fényhez. Az első két szám a bal alsó, a második kettő a jobb felső sarkát adja meg a használandó textúradarabnak 0-1 közötti értékben. Ha az egész textúrát használjuk – általában – akkor ide 0 0 1 1 értékeket kell írni. A LightsTab ( bejegyzésben a fények színeit kell megadnunk. Az összes a későbbiekben használatos színt fel kell itt sorolnunk. A bejegyzésben meg kell adnunk a LightsTabEntry ( bejegyzések számát. A LightsTabEntry ( bejegyzésben az alábbi adatokat kell megadni: - Idézőjelben a fény nevét. Később ezt használjuk hivatkozásul. - A Colour ( bejegyzést, azon belül négy számot. Az első az átlátszóságot adja meg (255 teljesen látszik, 0 egyáltalán nem látszik), a másik három érték pedig a vörös, zöld és kék színek arányát (255 0 0 – piros, 255 255 0 – sárga, stb.). Ügyeljünk rá, hogy itt sem mindegy, milyen típusú textúrát használunk, és a fény megjelenését befolyásolhatja a számítógép grafikus beállítása is. Ezután következik az egyes jelzőtípusok beállítása. Egy jelzőhöz a későbbiek folyamán több típus is tartozhat majd, illetve egy típus tartozhat több jelzőhöz is. A SignalTypes ( bejegyzésben a SignalType ( bejegyzések száma után kell felsorolni a SignalType ( bejegyzéseket, melyek az alábbi adatokat kell, hogy tartalmazzák: -

Idézőjelben a hivatkozási neve. A SignalFnType ( bejegyzésben a típus funkciója adható meg. Ezek lehetséges értékei: NORMAL, INFO, DISTANCE, REPEATER, és SHUNTING. Ezek közül a NORMAL típusú jelzési képei jelennek meg a Track Monitoron és az adott járművek vezetőállásában a jelzőkön. A többi csak programozási feltételek továbbítására használható, a játékban állapotuk nem lesz látható. A Kuju filozófiája alapján ezeket a típusokat előjelzési, ismétlőjelzési, tolatásjelzési és információs funkciókra szánta felhasználni, de mivel a rendszer nyitott, bármire használhatók. (Pl.: a MÁV V2.0 jelzőrendszerben NORMAL típusú minden olyan jelző, mely után a vezetőállásjelző (sátorjelző) jelzési képe megváltozhat, az INFO típusúak a funkcióval nem bíró elemek, illetve a csak helyi funkcióval bíró elemek: a váltók és a fénysorompók, és utóbbi esetben az adott jelző sebességjelzési képének kiválasztása, REPEATER a váltók animációjának működtetése, és DISTANCE a virtuális jelzők működtetésével kapcsolatos funkció – ezekről majd később szólnék). A nem NORMAL típusú jelzők esetén van egy bosszantó hibája a TS-nek: amennyiben egy NEM NORMAL típusú jelző elsőként érintett egy vágány vége felől, az a TS fagyásához vezet. Az ábrán látható, a helyes és hibás elhelyezkedés. FAGYÁS!

A többi mind NORMAL típus

Nem NORMAL típusok Például fénysorompók

FAGYÁS! NINCS PROBLÉMA!

Megoldás:

A narancsszínű vonalak a váltóállásokból adódó lehetséges útvonalakat jelölik. A pálya betöltésekor az összes váltó egyenes állásban van. Ekkor a jobb alsó sarokban elhelyezkedő vágányvégnél keletkezik hiba (narancs nyíl). Van olyan eset, mely egy váltó kitérő állásba állításakor jön elő: ez a kék körrel jelölt váltó átállításakor a bal felső sarokban látható hiba. Az összes többi esetben van a nem NORMAL típusú jelző előtt egy másik NORMAL, mely megszünteti a hibalehetőséget (narancs pont). A megoldás a fagyás elkerülésére, hogy azokba a vágányvégekbe, amelyek miatt a fagyás keletkezik, egy

51

tetszőleges NORMAL típusú jelzőt helyezük. Ez a játékban az állása miatt nem vesz részt, használata nem okoz zavart (a shapejét természetesen illik a föld alá rejteni). -

A SignalFlags ( bejegyzésben a karos (animációval rendelkező) jelzőtípusra hívhatjuk fel a TS figyelmét a SEMAPHORE szöveggel. Lehetséges itt a NO_GANTRY bejegyzés is, de nem tudom, akkor mit csinál.

-

A SemaphoreInf ( bejegyzés értéke mindig 1. Csak karos jelzők esetén szükséges.

-

A villogó fényeket is tartalmazó jelzőtípusok esetén alkalmazzuk a SigFlashDuration ( bejegyzést, mely a villogó fények világítási és nem világítási időközét adja meg. Az első szám a világítás, a második a nem világítás százalékos arányát adja meg 0-1 közötti értékben. Sajnos a felváltva villogás tényét nem ismeri a TS, ezért ezekben a speciális esetekben trükközni kell, de erről egy kicsit később.

-

A SignalLightTex ( bejegyzésben idézőjelek között azt a textúranevet kell megadnunk, amelyet már korábban a LightTextures ( bejegyzésben meghatároztunk. Minden jelzőtípusra csak egy alkalmazható. Amennyiben egy adott jelzőhöz több is szükségeltetne, úgy mindenképpen több jelzőtípusból kell a jelzőt összerakni.

-

Ezután következik a jelzőn látható fények megjelenésének megadása. A SignalLights ( bejegyzésben a SignalLight ( bejegyzések számát kell megadni, majd az egyes SignalLight ( bejegyzések következnek. A SignalLight ( bejegyzésben a következőket kell felsorolni: a fény hivatkozási számát, a fény színét, pozícióját és sugarát illetve az esetleges animációt. A fények számozása mindig 0-val kezdődik. A színét idézőjelek közt kell megadni, és olyan nevet kell beírni, amelyet már korábban a LightsTab ( bejegyzésben meghatároztunk. A pozíciót a Position ( bejegyzésben kell megadni három szám felsorolásával, az adott objektum (HEAD részobjektum!!!) PIVOT pontjától számítva. A fény a PIVOT pont irányítottságától függő irányban fog látszani. A sugarát a Radius ( bejegyzésben kell megadni, értéke méterben értendő. Ugyancsak a SignalLight ( bejegyzésen belül kell megadni animációval rendelkező alakjelzők esetén az animáció lefuttatását. Ezt a SignalFlags ( SEMAPHORE_CHANGE ) bejegyzéssel tehetjük meg.

-

Ezután a jelzési képek megadása történik a SignalDrawStates ( bejegyzésen belül. A szokásos módon itt is először a SignalDrawState ( bejegyzések számát kell megadni, majd felsorolni a SignalDrawState ( bejegyzéseket. Ezeken belül kell kiválasztani az egyes elnevezett jelzési képekhez tartozó – akár több együtt égő – fényt. Először itt is a jelzési kép számát adjuk meg 0-tól kezdve. Ezután egy szabadon választott nevet kell megadni idézőjelek között. Ez lesz később az adott jelzési kép hivatkozási neve. (Személy szerint ide legtöbbször magyar neveket szoktam írni: Megallj, Szabad, Hivo, Tolatas, stb. A Kuju ide is fényneveket írt, ami szerintem megtévesztő lehet. Ez már nem a fényekről szól, hanem a jelzési képekről, amelyeket akár több fénnyel is kifejezhetünk. A nevek használata kötelező, de mint később láthatjuk, a programozásban már nem lesz sok jelentőségük.) Ezután történik a fények felsorolása az adott jelzési képhez a DrawLights ( bejegyzésben. Először ide is az összes DrawLight ( bejegyzés számát kell írni, majd felsorolni a DrawLight ( bejegyzés(eke)t, amely(ek)be a SignalLights ( részben megadott konkrét pozícióval rendelkező fény sorszáma kerül. Villogó fény esetén a sorszám után áll egy SignalFlags ( FLASHING ) bejegyzés is (a DrawLight ( bejegyzés zárójelén belül!), melytől a fény villogni fog a korábban megadott paraméterekkel. Itt kell megemlítenem a korábban ígért trükköt, mellyel rávehető a TS a felváltott villogásra (pl.: MÁV fénysorompó vörös fényei). Mivel a TS felváltott villogást nem ismer, az egyik fényt a normál villogás helyett át kellett alakítani. Míg a másik fény normál villogást produkál, addig az egyiket fix fényűvé alakítottam, és közvetlenül elé elhelyeztem egy fekete fényt, amely viszont a másik vörössel együtt villog. Így a villogás „világító” fázisában a fekete fény „világítása” eltakarja a mögötte lévő vörös fényt, ekkor csak a másik fény látszik. A villogás „nem világító” fázisában csak az állandóan világító vörös fény ég. A sötét fény színe nem átlátszó, mivel csak így tudja eltakarni a mögötte lévő másik fényt. A SignalDrawState ( bejegyzésen belül kell elhelyezni a SemaphorePos ( bejegyzést, mely egy számmal utal animációval rendelkező jelzők esetén az animált részobjektum (HEAD) helyes helyzetére. Fényjelzők esetén és alaphelyzetben ez az érték mindig 0, míg animáció esetén 0 vagy 2 a kar állásától függően.

-

A következő lépés a jelzési helyzet meghatározása, azaz a jelzési kép összehozása a jelzésfogalmakkal és az engedélyezett sebességekkel. Ezt a SignalAspects ( részben tehetjük meg, ahol először a SignalAspect ( bejegyzések számát, majd azok felsorolását kell elvégezni. A SignalAspect ( bejegyzésen belül a jelzési fogalom nevét, idézőjelben az általunk megadott jelzési kép nevét, majd az ez eseben alkalmazható sebességet kell megadni. A jelzési fogalmak neve fix érték a TS-ben! Lehetséges értékei: STOP, STOP_AND_PROCEED, RESTRICTING, APPROACH_1, APPROACH_2, APPROACH_3, CLEAR_1, és CLEAR_2 (Gyakorlatilag ezek nem csak neveik alapján, hanem számozásban is élnek, ebben a sorrendben 1-

52

8-ig. Mindemellett létezik a 0 érték is, amely az Activity Editorban kikapcsolt jelzőt jelenti. Ez utóbbinak lehet, hogy van neve, de ez nem ismeretes – illetve még sosem próbáltam a FAILED nevet.) Ezek a jelzési fogalmak határozzák meg a Track Monitoron megjelenő, a jelzőket ábrázoló pontok színét (az első három piros, a második három sárga, az utolsó kettő zöld), ezek a nevek jelennek meg (kis módosítással) a Track Monitor alsó részén, illetve ezek a jelzési fogalmak irányítják a vezetőállásjelzők megjelenését. A jelzési fogalmak neveit, bár – két kivétellel – szinte mindegy milyen jelzési fogalomként használjuk, érdemes az APPROACH neveket a csökkentett sebességgel való haladáshoz, a CLEAR neveket a sebességcsökkentés nélküli haladáshoz felhasználni. A két kivétel a STOP és a STOP_AND_PROCEED. A STOP fogalmú jelző melletti elhaladás az activity végét is jelentheti, ha egy másik vonat a jelző mögött – a következő jelzőig tartó – szakaszban tartózkodik. STOP állású jelző mellett el lehet haladni, a TAB gomb lenyomására, amennyiben a következő szakaszban nincs vonat. Hogy van-e vonat, vagy nincs a következő szakaszban, arra a TAB gomb megnyomására megszólaló bemondásból következtethetünk. A STOP_AND_PROCEED jelzésfogalomra az AI-vonatok a jelző előtti megállással, majd lépésben való továbbhaladással reagálnak. (Sajnos ez a MÁV V2.0 jelzőrendszer megmaradt hibája, mivel a STOP_AND_PROCEED jelzésfogalom a nem főjelzők esetében a következő főjelzőn Megállj! jelzés várható fogalom továbbadására lett felhasználva. Így egy AI-vonat Megállj! állású jelzőhöz közelítve az előző jelzőnél (előjelzőnél) is nem kívánt sebességcsökkentést tesz. A hiba oka kiderült, de kijavítása csak a teljes rendszer átírásával lehetséges, így ez majd csak a V3.0-ban fog megjelenni.) A következő lépés a korábban a SignalDrawStates ( bejegyzésben megadott jelzési kép nevének idézőjelek közti beillesztése. NORMAL típusú jelző esetén az alkalmazható sebesség megadása a SpeedKPH ( bejegyzésben tehető meg. Ez a bejegyzés el is hagyható, ha a jelzési fogalomhoz nem tartozik sebességcsökkentésre utaló jelzés. Ez a sebesség íródik ki a Track Monitorra, illetve a megfelelően kialakított járművek vezetőállásában is ez jelenik majd meg. Ez a sebesség független a pályasebességtől, és a jelző meghaladásától a következő NORMAL típusú jelzőig tart, illetve annak a jelzőnek a jelzési fogalmához tartozó sebességértékre módosul. Amennyiben egy jelzési fogalomhoz nem írunk SpeedKPH ( bejegyzést, úgy azon jelzési fogalom esetében oldódik az előző jelző által megkövetelt sebesség. Ha a pályasebesség kisebb, mint a jelző által megadott sebesség, úgy csak a pályasebesség lesz az engedélyezett sebesség, addig, amíg a pályán megadott sebesség meg nem haladja a jelzők által kikövetelt sebességet. A mellékelt ábrán látható a végleges sebességgrafikon. Ide beírható egy SignalFlags (ASAP) bejegyzés („as soon as posible” rövidítése), amely valami olyasmit jelent, hogy a vonat a lehető legnagyobb sebeséggel haladhat tovább. Szerintem, ha nem írunk be semmit, akkor is ez történik. De lehet, hogy ilyenkor a Track Monitoron megjelenik ugyan a sebességkorlátozás, de nem kell betartani? Az amerikai alappályáknál található ez meg. (Európai szemmel ezt egyáltalán nem értem.) A másik tippem erről a funkcióról, hogy ez esetben csak a jelző melletti elhaladáshoz követeli meg a sebesség betartását, majd lehet gyorsítani, nem szükséges a sebesség tartása a következő jelzőig. Ez csak tipp, ezt a funkciót még tüzetesebben ki kell vizsgálni. Pályasebesség S e b e s s é g

Jelzősebesség Engedélyezett sebesség (TM)

Megtett út -

A jelzési helyzet meghatározása után még van egy fontos bejegyzés, mely működését még mindig kisebb bizonytalanság övezi. Ez lenne a SignalNumClearAhead ( bejegyzés, melybe egy egész számot kell beírni. Ez a szám határozza meg egy vonat esetében, hogy hány jelző távolságra előre állítsa a rendszer a jelzőket szabadra a vonat érkezése előtt. A korábban az activityket magyarázó részben leírt vonattalálkozások esetén igen fontos jelentőségű, hogy mennyivel előre állítódnak szabadra a jelzők, hiszen ekkortól fixen lezáródnak a váltók és más vonat ettől fogva nem tudja állítani azokat a vonat elhaladásáig. (Ebből adódik a MÁV V2.0 jelzőrendszer esetén az esetlegesen előforduló, „Következő jelzőn Megállj! jelzés várható” jelzésű – egy sárga fényű jelzők jelenléte. Az itt meghatározott jelzők számába ugyanis nem csak a látható főjelzők, hanem a

53

virtuális jelzők is beletartoznak, és adott esetben ezek is korlátozhatják a jelzőállítási távolságot. Ezt megelőzendő a virtuális jelzők nagyobb számmal rendelkeznek.) Ezzel zárul egy SignalType ( bejegyzés, majd az összes jelzőtípus felsorolása után a SignalTypes ( bejegyzés is. Ne felejtsük kitenni a bezáró zárójeleket! Ezzel elérkeztünk a legfontosabb dologhoz, a jelzőtípusok shape fájlhoz rendeléséhez. Ezt a SignalShapes ( bejegyzésben tehetjük meg, ahol a szokásos forma szerint először a SignalShape ( bejegyzések számát kell megadnunk, majd jöhet a felsorolás. Egy SignalShape ( bejegyzésben az alábbiakat kell megadnunk: Elsőként idézőjelben a shape fájl nevét adjuk meg. Ezután kövezkezik a jelző neve, az a név, ami a Route Editorban megjelenik. A jelző részobjektumok felsorolása ezután történik a SignalSubObjs ( bejegyzésben a szokásos módon: az összes SignalSubObj ( bejegyzés száma, majd azok felsorolása következik. A SignalSubObj ( bejegyzés a következőket tartalmazza: o Egy sorszámot nullától kezdve. o Az adott részobjektum választott nevét. Animált objektumnál ennek meg kell egyezni a shape fájl részobjektum nevével (?), de mindenképpen javasolt a „szabványos” elnevezések használata. o A következő, idézőjelben szereplő név a Route Editor jelzőbeállítással foglalkozó ablakában jelenik meg az adott részobjektum sorában. o A SignalSubTyp ( bejegyzésben a típusát lehet megadni. Ennek fix értékei: § SIGNAL_HEAD: jelzőfej, azaz a jelzőhöz tartozó programozható funkcionális rész § NUMBER_PLATE, GRADIENT_PLATE, USER1, USER2, USER3, USER4: nevesített, illetve nem nevesített olyan opciók, melyek egy állapotot jelölnek, és a programozáson belül megadva akár más-más hatás vezérlésére használhatók § DECOR: csak információs célokat szolgál o A SignalSubSType ( bejegyzésben (nem ugyanaz, mint az előző!) a Signal Type ( bejegyzésekben megadott nevet kell megadni idézőjelben. A SignalSubSType ( bejegyzés megadása csak a SignalSubTyp ( SIGNAL_HEAD ) értéke esetén szükséges. o A SignalFlags ( bejegyzésben több lehetséges opció közül választhatunk: § Az OPTIONAL bejegyzés az adott jelzőrész, vagy opció kiválasztható jellegére utal. Amennyiben ezt nem írjuk ide, a felhasználó nem tud választani, az értéke fix érték lesz. § A DEFAULT bejegyzés az adott opció kiválasztott állapotára utal, azaz ilyenkor az értéke bekapcsolt, ha nincs beírva, akkor kikapcsolt állapotú lesz. § A JN_LINK bejegyzés a Link gombot teszi aktívvá, és szükségessé teszi a Route Editorban egy útirány kiválasztását. Ez azt jelenti, hogy ezzel egy adott útirányhoz tehetünk függővé működési funkciókat a jelzőnél. (Pl.: sebességcsökkentésre utaló jelzés használatának kiválasztása, stb.) A linkelés (útirány kiválasztás) a TS korlátai miatt csak 4 db váltó távolságra összesen 16 irányban lehetséges, így emiatt nem érdemes túl bonyolult vágányhálózatot felépíteni. A linkelésnél nem kötelező az utolsó váltó utáni (összes) irány megadása, elegendő egy olyan váltó egyik ágának kiválasztása, amely után a feltételek már azonosak. § A BACK_FACING bejegyzés a jelző alapesethez képest megfordított állapotára utal. Ez a jelzőrész a jelzőnek háttal álló vonatokra érvényes („hátsó” jelzőfej iker jelzők esetében) Ezekből a feltételekből szóközzel elválasztva akár mind a négy is szerepelhet a bejegyzésben. Pl.: ( OPTIONAL DEFAULT ): kiválasztható, de alapra bekapcsolt; ( OPTIONAL JN_LINK ) bekapcsolás esetén meg kell adni a linkelést; stb. o A SigSubJnLinkIf ( bejegyzésben a a jelzőfejhez csatolhatjuk a többi részelem linkelését, így egy másik elemről átvihető az információ az adott jelzőfejre. A bejegyzésbe a lehetséges linkelések számát, majd azoknak a SignalSubObj ( bejegyzéseknek a sorszámát kell beírni, amelyben szerepel a SignalFlags ( bejegyzésben a JN_LINK beírás. Ezzel szinte véget is ért a SIGCFG.DAT fájl. Ne felejtsük el kitenni minden SignalSubOj ( , SignalSubObjs ( , SignalShape ( , és SignalShapes ( bejegyzés bezáró zárójelét. A SignalShapes ( bejegyzés bezárása után már csak egy formális bejegyzésre van szükség, a script fájl megadására. Ez a ScriptFiles ( bejegyzésben tehető meg, a ScriptFile ( bejegyzésbe beírt sigscr.dat névvel. Elvileg más nevet is lehetne a script fájlnak adni, de ezt még senki sem próbálta, (és lehet, hogy a TS-nek sem tetszene,) ezért maradjunk a SIGSCR.DAT elnevezésnél. -

Nem baj, ha nem érted, nem vagy egyedül! J

54

A jelzőprogramozás nem egyszerű feladat. Kicsit összefoglalom a lényeget: - Add meg a lehetséges textúrákat (Pl.: üveg optika) - Add meg a lehetséges színeket (Pl.: vörös és zöld) - A jelző típusában add meg, hogy egy-egy fénynek milyen a textúrája, színe, pozíciója, mérete (pl.: a felső fény vörös, és 6 cm sugarú, az alsó zöld és 6 cm sugarú); mely fények alkotják a jelzési képeket (pl.: a Megállj!-t egy vörös fény, a Szabadot egy zöld fény), és ezekhez a jelzési képekhez milyen jelzésfogalom kapcsolódik (pl.: a vörös fény a TS-ben STOP-ot jelent, a zöld CLEAR_1-t). - Majd add meg, hogy a fent összeállított jelzőtípus milyen shape-eken jelenjen meg. (A fenti típus legyen a két fényű jelző shape-jén). Ez még csak a jelzők összeállítása volt. Nagyon fontos, hogy a TS ezeknek az adatoknak egy részét a jelző pályára helyezésekor beépíti a pálya adatbázisába, így a jelzők lehelyezése után lehetőleg NE módosítsd a SIGCFG.DAT fájlt! Amennyiben cserélni akarod, szedj le minden jelzőt a pályáról, cseréld a SIGCFG.DAT fájlt, és telepítsd le az új jelzőket. (Adott jelzőcsomag – például a MÁV V2.0 – frissítései esetén ez nem szükséges, illetve a jelzőcsomag készítője ad erről utasítást.) Amennyiben nem így jársz el, a pályába beépített jelzők hivatkozási nevei miatt keresni fogja a TS a SIGCFG.DAT fájlban az adatokat, de mivel nem találja, le fog fagyni! A jelzők törlésénél is fontos az óvatosság! NEM SZABAD egyszerre egy tile-nál többről a jelzőket mentés nélkül törölni!!! Amennyiben törölsz egy jelzőt, mentsd el a pályát, mielőtt az adott tile-ról „elrepülnél”, illetve mielőtt az a távolodás miatt eltűnne a Route Editorban a látható tile-ok közül! A TS bizonyos adatokat csak a mentéskor aktualizál, de csak a betöltött tile-ok eseténben. Ekkor előfordulhat (elég nagy valószínűséggel), hogy a jelző látszólag törlésre került a pályán, de egyes működő részei mégis bennmaradnak a TS pálya adati között, és a játék során nemkívánt jelzőműködést okozhatnak! Jó módszerek a szemét kiszűrésére: - Ptrmarci által készített Statisztika programmal jelzőstatisztikát kell végeztetni, majd meg kell nézni, hogy nincs-e listában olyan jelző, vagy jelző-rész, amely a pályánkon nem látszik. Ugyancsak érdemes figyelni rá, hogy egy jelző minden részobjektuma azonos koordinátákra essen. Amennyiben egy jelző helyére – környezetébe – több helykoordinátát is kiad a Statisztika program, úgy azt a jelzőt törölni kell, és újratelepíteni, ügyelve arra, hogy a törlés ténylegesen megtörténjen (újabb elenőrzés a Statisztikával). - Ha a Statisztika program sem hoz ki semmi hibát, és mégis hibás, megmagyarázhatatlan működést vélünk felfedezni a jól beállított jelzők között, úgy még lehet egy esélyünk a tényleges hiba kiszűrésére. Ez csak akkor lehetséges, ha a „szemét” jelzőobjektumrészből másik nem található a pályán. Ilyenkor ugyanis a Script Optimalizáló program lefuttatása után ha a TS hibával indul, biztosak lehetünk, hogy a pálya nem kívánatos jelzőelemet tartalmaz. A fent nevezett Script Optimalizáló program használata más okból hasznos, alapvetően nem is hibakeresésre, hanem mint a nevében is adott, optimalizálásra szolgál. A TS ugyanis a játék indításakor betölti a Routes könyvtárban található pályákat, azok jelzőprogramozásával együtt. Mivel egy-egy nem általunk készített jelzőcsomag több olyan jelzőt is tartalmazhat, melyet fel sem használtunk a pályánkon, ezért a jelzőscript betöltése felesleges időpocsékolás. Az optimalizáló program végignézi a pályát majd kigyűjti a használt jelzők listáját. Ezek után a jelzőprogram fájlokat veszi kezelésbe és törli belőle azokat a bejegyzéseket, melyek a pályán fel nem használt jelzőkre vonatkoznak. Ettől ezek a fájlok akár lényegesen meg is rövidülhetnek, gyorsabbá téve ezzel egy pálya betöltését. Használata nagyon egyszerű, és mindenképp kívánatos.

55

8.2. Jelzőprogramozás – SIGSCR.DAT Nincs más hátra, ruházzuk fel jelzőnket tulajdonságokkal. Ez egy egyszerű programnyelv segítségével történik. A script fájl több hosszabb-rövidebb programot tartalmazhat. Fő formai követelmény, hogy minden program SCRIPT szóval, és utána a jelzőtípus neve (lásd SignalType ( bejegyzés, vagy a SignalShape ( - SignalSubObj ( bejegyzésen belül a SigSubSType ( bejegyzésben megadott név ). A scriptben feltételeket adhatunk meg az if () { } else { <egyébként> } függvénnyel. Ha a igaznak bizonyul, akkor az parancs hajtódik végre, ha nem akkor az <egyébként> parancs. A kapcsos zárójelek több végehajtandó parancs kiadásakor kellenek. Az else kifejezés után rögtön álhat újabb if parancs is: if () { } else if () { } else { <egyébként> } Elvileg még a következő parancsok használhatók: for (ciklus), while (ciklus), do while (ciklus), break (kilépés a ciklusból), continue, return. Ezeket soha senki nem használta. A feltételek csak rögzített változókhoz adható meg, ezek a következők: -

-

-

-

enabled; Az enabled függvény értéke igaz, ha a jelző mellett elhalad a nyomvonal. A !enabled függvény jelentése ellentétes, akkor lesz igaz az értéke, ha nem megy el a nyomvonal a jelző mellett. block_state (); A block_state () függvény a következő jelzőig tartó szakasz vonat által foglaltsági állapotát mondja meg. A block_state ()-nek három értéke lehet: o block_state () ==# BLOCK_CLEAR; a szakasz szabad, ott vonat nem tartózkodik o block_state () ==# BLOCK_OCCUPIED; a szakasz foglalt, ott vonat tartózkodik o block_state () ==# BLOCK_JN_OBSTRUCTED; a szakaszban nem áll a váltó, ott valamilyen okból nem nekünk áll a váltó. Természetesen itt is lehetséges a negatív hozzárendelés: o block_state () !=# BLOCK_CLEAR; a szakasz nem szabad, ott vonat tartózkodik o block_state () !=# BLOCK_OCCUPIED; a szakasz nem foglalt, ott vonat nem tartózkodik o block_state () !=# BLOCK_JN_OBSTRUCTED; a szakaszban áll a váltó, ott nekünk áll a váltó. route_set (); A route_set () függvény a beállított linkelésre utal, és értéke igaz, ha van legalább egy beállított linkelés az adott jelzőnél. Értéke hamis, ha nincs egyetlen egy linkelt útvonal sem (választható linkelésnél van értelme használni). sig_feature (); A sig_feature () függvény a SignalSubType ( bejegyzésben megadott állapotot jelölő opciók értékének beolvasására szolgál. Ezek a fenti bejegyzésnek megfelelően: sig_feature (SIGFEAT_NUMBER_PLATE), sig_feature (SIGFEAT_GRADIENT_PLATE), sig_feature (SIGFEAT_USER1), sig_feature (SIGFEAT_USER2), sig_feature (SIGFEAT_USER3), és sig_feature (SIGFEAT_USER4). Ezen opciók bepipált értéke igaz, nem bejelölt értéke hamis érték. (akkor is beolvasható, ha a DEFAULT megjelöléssel fixált értékről van szó!) next_sig_lr (); A következő jelző legkevésbé engedélyező (?) jelzési képét adja vissza. A zárójelen belülre a jelző típusát kell megadni, ennek is fix értékei vannak.: next_sig_lr (SIGFN_NORMAL), next_sig_lr (SIGFN_DISTANCE), next_sig_lr (SIGFN_INFO), next_sig_lr (SIGFN_REPEATER), és next_sig_lr (SIGFN_SHUNTING). A függvény eredménye egy jelzési fogalom: SIGASP_STOP, SIGASP_STOP_AND_PROCEED, SIGASP_RESTRICTING, SIGASP_APPROACH_1, SIGASP_APPROACH_2, SIGASP_APPROACH_3, SIGASP_CLEAR_1, SIGASP_CLEAR2. Pl.: next_sig_lr (SIGFN_NORMAL) ==# SIGASP_CLEAR_1 feltétel akkor igaz, ha a következő NORMAL típusú jelzőn CLEAR_1 jelzési fogalom van. this_sig_lr (); Ez a függvény az előző függvényhez hasonlóan, de jelen jelző egyéb részelemeinek legkevésbé engedélyező (?) jelzési képét adja vissza. opp_sig_lr (); Ez a függvény az előző függvényekhez hasonlóan, de a szemközt háttal álló (?) jelző egyéb részelemeinek legkevésbé engedélyező (?) jelzési képét adja vissza. Sosem láttam használni. Szívesen veszek olyan scripteket, amelyekben a gyakorlatban használva van. next_sig_mr (); Ez a függvény az előző függvényekhez hasonlóan, de a következő jelző egyéb részelemeinek leginkább engedélyező (?) jelzési képét adja vissza. Sosem láttam használni. Szívesen veszek olyan scripteket, amelyekben a gyakorlatban használva van. this_sig_mr (); Ez a függvény az előző függvényekhez hasonlóan, de jelen jelző egyéb részelemeinek leginkább engedélyező (?) jelzési képét adja vissza. Sosem láttam használni. Szívesen veszek olyan scripteket, amelyekben a gyakorlatban használva van. opp_sig_mr (); Ez a függvény az előző függvényekhez hasonlóan, de szemben háttal álló jelző egyéb részelemeinek leginkább engedélyező (?) jelzési képét adja vissza. Sosem láttam használni. Szívesen veszek olyan scripteket, amelyekben a gyakorlatban használva van.

56

-

-

-

dist_multi_sig_lr (); Ez a függvény az előző függvényekhez hasonlóan, de a következő megadható típusú jelző egyéb részelemeinek legkevésbé engedélyező (?) jelzési képét adja vissza. Elvileg alkalmas lenne több jelző távolságában egy adott típusú jelzőnél meglévő másik jelzőtípus állapotának beolvasására. (Pl.: a következő NORMAL jelzőnél, amelyik rendelkezik DISTANCE résszel, beolvassa annak állapotát.) Sosem láttam használni. Szívesen veszek olyan scripteket, amelyekben a gyakorlatban használva van. def_draw_state (); Visszaadja a draw_state; bejegyzés számára a SIGCFG.DAT fájlban beállított alapvető jelzési képet. Ennek használatával elegendő megadni a jelzésfogalmat, a jelzési kép az előre beprogramozott lesz. (draw_state = def_draw_state ( state );) state; A jelzési fogalom határozható meg vele. state = SIGASP_<jelzési fogalom>; (SIGASP_STOP, SIGASP_STOP_AND_PROCEED, SIGASP_RESTRICTING, SIGASP_APPROACH_1, SIGASP_APPROACH_2, SIGASP_APPROACH_3, SIGASP_CLEAR_1, SIGASP_CLEAR2.) draw_state; A jelző jelzési képe adható meg vele. Itt vagy a def_draw_state (); függvény alkalmazásával az eredetileg beállított értéket adjuk meg, vagy akár bármely a SIGCFG.DAT fájlban a SignalDrawState ( bejegyzésekben megadott jelzési képek sorszáma is megadható. A jelzés teljes kivezérléséhez mind a state;, mind a draw_state; függvény szükséges. debug_header (); Hibakeresésre használható. Ez a logfájlba írás kezdősora. Valószínűleg ez irja ki az időpontot is. debug_out (); A debug_header (); sor után ezekben a sorokban lehet megadni a kívánt paraméterek állapotának kiíratását. Pl.: debug_out ( block_state () ); kiírja a foglaltsági állapot változását. Kicsit nehézkes a követése, de egyszerű fejlesztéseknél, egyszerű példákban a hibakeresésre, a működés megértésére hasznos lehet.

Ezeket a függvényeket minden scriptben a használat előtt „elő kell jegyezni”. Ezen azt értem, hogy mielőtt az if-else feltételeket leírnánk, minden egyes függvényt egy extern float bejegyzéssel meg kell hívni, különben nem fogja értelmezni a scriptünket. Pl.: extern float enabled; használhatóvá teszi az enabled függvényt. Más, külső változókat is bevezethetünk a scriptbe. Ennek csak a gépelés leegyszerűsítése a célja. Ilyenkor egy float sorral kell bevezetni az új változó nevét. Pl.: float next_state; ezután elnevezhetjük az új függvényünket: next_state = next_state_lr (SIGFN_NORMAL); ezután a next_state_lr (SIGFN_NORMAL); függvény értelme a next_state;-ben is lehívható, tehát pl.: if ( next_state ==# SIGASP_CLEAR ) … A dupla perjel (//) lehetővé teszi kommentárok hozzáírását. 8.3. Néhány példa Az első példa egy nagyon egyszerű jelzőt mutat. Ez mindössze csak azt mondja meg, hogy elhaladhatunk-e a jelző mellett vagy sem. Ezt két tényező vizsgálatával végzi: egyrészt, hogy a nyomvonal egyáltalán elmegy-e a jelző mellett, másrészt, hogy a következő jelzőig a nyomvonalnak megfelelően állnak-e a váltók. Ha ezen feltételek nem teljesülnek STOP lesz az eredmény, ha nem , akkor CLEAR jelzés. SCRIPT ELSOPELDA extern float extern float extern float extern float

block_state (); state; draw_state; enabled;

// vágányfoglaltsági függvény meghívása // jelzésfogalom függvény meghívása // jelzéskép függvény meghívása // „nyomvonal elhalad a jelző mellett” függvény meghívása

if (!enabled || block_state() ==# BLOCK_JN_OBSTRUCTED ) // ha nem megy a jelző mellett a nyomvonal, vagy nem áll a váltó a következő szakaszon { state = SIGASP_STOP; // akkor STOP jelzés draw_state = 1; // és 1-es jelzési kép (vörös fény) } else // egyébként { state = SIGASP_CLEAR_1; // CLEAR_1 jelzési kép draw_state = 0; // és 0-s jelzési kép } A második példa az első példánál annyival tud többet, hogy a szabad jelzési képet a következő jelzőtől teszi függővé. A script elején itt is megtalálható a fenti feltétel, de ennek megléte után továbbvizsgál: szabad-e a térköz. Ha ott vonat van

57

szintén STOP lesz az eredmény. Ezután megvizsgálja a következő NORMAL jelző állapotát, és attól teszi függővé a saját állapotát és jelzési képét. SCRIPT MASODIKPELDA extern float extern float

block_state (); next_sig_lr ();

extern float extern float extern float

draw_state; enabled; sig_feature();

extern float

state;

if (!enabled || block_state() ==# BLOCK_JN_OBSTRUCTED ) {

state = SIGASP_STOP; draw_state = 0;

// Ha a nyomvonal nem halad el a jelző mellett vagy nem áll a váltó.

// Akkor megállj! } else if (block_state() !=# BLOCK_CLEAR) // Ha foglalt a térköz { state = SIGASP_STOP; draw_state = 0; // Akkor megállj! } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_CLEAR_1) // Ha a következő CLEAR_1 { state = SIGASP_CLEAR_1; // Akkor CLEAR_1 draw_state = 4; // és egy zöld fény } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_CLEAR_2) // Ha a következő CLEAR_2 { state = SIGASP_CLEAR_1; // Akkor CLEAR_1 draw_state = 4; // és egy zöld fény } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_APPROACH_1) // Ha a következő APPROACH_1 { state = SIGASP_CLEAR_1; // Akkor CLEAR_1 draw_state = 3; // és egy villogó zöld fény } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_APPROACH_2) // Ha a következő APPROACH_2 { state = SIGASP_CLEAR_1; // Akkor CLEAR_1 draw_state = 3; // és egy villogó zöld fény } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_APPROACH_3) // Ha a következő APPROACH_3 { state = SIGASP_CLEAR_1; // Akkor CLEAR_1 draw_state = 2; // és egy villogó sárga fény } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_RESTRICTING) // Ha … { state = SIGASP_CLEAR_1; draw_state = 1; // Egy sárga fény } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_STOP_AND_PROCEED) { state = SIGASP_CLEAR_1; draw_state = 1; // Egy sárga fény } else if (next_sig_lr (SIGFN_NORMAL) ==# SIGASP_STOP) { state = SIGASP_CLEAR_1; 58

} else { }

draw_state = 1;

// Egy sárga fény //Egyébként értelmetlen

state = SIGASP_STOP_AND_PROCEED; draw_state = 0;

// Vörös fény

A harmadik példa a linkelés megvalósítására hoz egy példát. Az elején hozzá kell tenni, hogy ez a jelző tartalmaz egy vagy több INFO_MAX, INFO_SHUNT, és INFO_HIVO INFO típusú részt is, amelyek mindegyike linkelhető egy útirányhoz. Ez az útirány akkor vagy maximális sebességgel lesz járható, vagy tolatásjelzést vált ki, vagy Hívó-jelzés jelenik meg. A scriptben a szokásos (de nem kötelező!) feltétel után azt vizsgálja, hogy a nyomvonal olyan irányban halad-e, ahova linkelés van beállítva. Ha nem (route_set () = igaz), akkor a következő szakasz foglaltságától teszi függővé, hogy megállj, vagy szabad jelzés jelenjen-e meg. Ha a nyomvonal linkelt irányban halad tovább, akkor megvizsgálja az INFO típus értékét, és ettől teszi függővé a jelzési képet. Mivel az INFO-ban is szerepelnek ugyanazok a feltételek, ezért ha az INFO linkelt állapotban mégis STOP állapotban lenne, a legutolsó feltétellel jelezzük a hiba meglétét. (Pl.: jelző TS-beli szétesése, vagy programozási hiba: nem megfelelő INFO részek kapcsolása a jelzőhöz.) SCRIPT HARMADIKPELDA extern float extern float extern float extern float extern float extern float extern float extern float float

block_state (); route_set (); next_sig_lr (); this_sig_lr (); state; draw_state; enabled; sig_feature(); this_state;

this_state = this_sig_lr (SIGFN_INFO); if (!enabled || block_state() ==# BLOCK_JN_OBSTRUCTED ) {

state = SIGASP_STOP; draw_state = 0;

// Ha a nyomvonal nem halad el a jelző mellett vagy nem áll a váltó.

// Akkor megállj! } else if ( route_set() ) // Ha nincs linkelés útvonalra { // Akkor if (block_state() !=# BLOCK_CLEAR) // Ha foglalt a térköz { state = SIGASP_STOP; draw_state = 0; // Akkor megállj! } else { state = SIGASP_CLEAR_1; draw_state = 1; // Egyébként szabad } } else // Ha van linkelve valamilyen útvonal { if (this_state ==# SIGASP_CLEAR_1 && block_state() ==# BLOCK_CLEAR ) // Ha valamely helyi INFO típus CLEAR_1 azaz INFO_MAX linkelt { state = SIGASP_CLEAR_1; draw_state = 1; // zöld fény

59

}

} else if (this_state ==# SIGASP_RESTRICTING) // Ha vmely h. INFO típ. RESTRICTING azaz INFO_SHUNT linkelt { state = SIGASP_RESTRICTING; draw_state = 3; // fehér fény (Szabad a tolatás) } else if (this_state ==# SIGASP_STOP_AND_PROCEED) // Ha vmely h. INFO típ. STOP_AND_PROCEED azaz INFO_HIVO linkelt { state = SIGASP_STOP_AND_PROCEED; draw_state = 2; // vörös fény + villogó fehér (Hívó-jelzés) } else // Hiba van { state = SIGASP_STOP_AND_PROCEED; draw_state = 0; // Vörös fény }

SCRIPT INFO_Max extern float extern float extern float extern float

block_state (); route_set (); state; enabled;

if (!enabled || block_state() !=# BLOCK_CLEAR || !route_set() ) // Ha nyomvonal nem megy el a jelző mellett vagy nem szabad a térköz, vagy ha nincs útvonal linkelve. { state = SIGASP_STOP; // Akkor STOP állapot } else { state = SIGASP_CLEAR_1; // Egyébként CLEAR_1 állapot } SCRIPT INFO_SHUNT if (!enabled || block_state() !=# BLOCK_CLEAR || !route_set() ) // Ha nyomvonal nem megy el a jelző mellett vagy nem szabad a térköz, vagy ha nincs útvonal linkelve. { state = SIGASP_STOP; // Akkor STOP állapot } else { state = SIGASP_RESTRICTING; } SCRIPT INFO_HIVO if (!enabled || block_state() !=# BLOCK_CLEAR || !route_set() ) // Ha nyomvonal nem megy el a jelző mellett vagy nem szabad a térköz, vagy ha nincs útvonal linkelve. { state = SIGASP_STOP; // Akkor STOP állapot } else { state = SIGASP_STOP_AND_PROCEED; }

60

A feltételek természetesen szabadon változtathatók. A logiaki felépítés is lehet sokféle. Ezt mindenki szabadon programozhatja. A valósághű működéshez ismerni kell az alapokat, a megfelelő működéshez a jól kell tudni programozni. 8.4. Összegzés A jelzők programozása igen bonyolult, sok türelmet és figyelmet igénylő dolog. Előny ha a fejlesztő már jártas más programozási nyelvekben. Csak olyanok álljanak neki, akik nagy kitartással rendelkeznek, és a megvalósítandó szakterületben is jártasak. Én személy szerint hónapokat töltöttem el vele, mire sikerült egy nagyjából hibamentes, a MÁV jelzési rendszerét nagyrészt hűen megvalósító jelzőcsomag leprogramozása. Ez még sajnos ma sem tökéletes. Remélhetőleg az újabb verzió kiküszöböli a jelenleg is fennálló problémákat. Magyar jelzőrendszerek - történeti áttekintés: - V1.0; Shapeket készítette: Magyar Szabolcs, programozta: Magyar Szabolcs. A leglényegesebb fényjelzőtípusokat tartalmazza. Az előjelzők, tolatásjelzők, ismétlőjelzők a korábban említett fagyási problémát okozzák. Működése ezen kívül megbízható. Funkcióiban viszont nem túl fejlett (különböző sebességgel járható vágányutak száma csekély). Akkoriban örültünk, hogy volt valami. - V1.5; Shapeket készítette: Magyar Szabolcs, programozta: Iván Zoltán. A leglényegesebb fényjelzőtípusokat tartalmazza. Az előjelzők, tolatásjelzők, ismétlőjelzők a korábban említett fagyási problémát okozzák. Működése ezen kívül megbízható. Funkcióiban továbbfejlesztett,de továbbra sem túl fejlett (a V1.0-hoz késest jobban kezeli a tolatásjelzővel egyesített főjelzők tolatási jelzését). - V2.0; Shapeket készítette: Németh Csaba, programozta: Iván Zoltán. A csomag a jelzők széles skáláját tartalmazza. Megtalálhatók már az alakjelzők mellett a váltójelzők, fénysorompók és a vágányzáró sorompó is. Mellékelve félcsapórudas sorompót is tartalmaz. A jelzők programozhatósága sokrétű, a különböző útvonalak száma az előzőekhez képest bővült. - V2.05; Hibajavítás a V2.0-hoz. - V2.10; Távolról látható jelzőfények megjelenése - Tervezet: V3.0; Shapeket készíti: ???, programozza Iván Zoltán. A csomag kiküszöböli a V2.0 rendszertechnikai hibáit, feltehetően kijavításra kerül a váltójelzők animációs problémája, illetve megjelennek a jelzőhídra helyezhető jelzők, illetve kibővítésre kerül az ikerjelzők választéka. Nagy valószínűséggel tartalmazni fog egy, a V3.0-val kompatíbilis, egyszerűsített jelzőscriptet, mely a tolatási mozgások kihagyásával, leegyszerűsíti a pályaépítők jelzőbeállítási műveleteit.

61

Felhasznált irodalom - Kuju: Techdocs - Rudolf Richter: Manual for .eng- and .wag-files of the MSTS 1.0 Ver 2.0e - Herbert Maggale: Wag-file Beispiel Tutorial - Herbert Maggale: Eng-file Beispiel Tutorial - Martin ’Tinting’ Söchting: Licht-Tutorial für den MSTS - Jürgen Herzog: Das Lichtsystem im Train Simulator - Hint and Tips for MSTS at Steam4me Site - HFL ill. VMW tutorialok - Forum: MSTS Activity Design at www.trainsim.com - Richard Garber: Activity Editor basic tutorial for MSTS - Jim "Sniper" Ward: Activity Editor - The Idiot' s Guide - How to edit signal configuration and scripting files - A marci.triak.hu oldal MSTS-Fórumában (ill. annak előd-fórumában az index.hu-n) megjelent hozzászólások és még sok más weboldal, ahonnan az apró információkat, trükköket összecsipegetve összeállt ez a leírás. Köszönöm mindenkinek a segítségét az információk összegyűjtésében.

Ajánlott irodalom Ptrmarci: MSTS Pályaépítési leírás (http://marci.triak.hu)

Copyright Használjátok egészséggel! Pénzért árusítani szigorúan tilos! Az esetlegesen előforduló hibákért előre is elnézést kérek. Javaslatokkal, hibajavítással, véleménykülönbséggel a http://marci.triak.hu/msts MSTS fórumban jelentkezzetek.

62