(Avancerad) Breakdown av statiska objekters .bin/xml-filer

[ADDE]

Hejsan! I denna guide tänkte jag lära dig lite tips och tricks hur du ska hantera en objekts egenskaper när du t.ex. klonar den för en repaints och hur du kan skapa en objekt med hjälp av child objects. Jag kommer här ta fram några enkla exempel på hur du kan göra detta. Se till att göra backup på dina filer såvida du inte gör detta med TS-Tools. (TS-tools automatiserar det mesta gällande backup och serz.exe men jag använder notepad++ för dess redigeringsvy.)

I exempel 1 så öppnar jag filen ...\Assets\newS\sweden\RailNetwork\signs\sign-u.xml

Bild 1:
På rad 5 hittar vi: <Name d:type="cDeltaString"></Name>
Här kan man ge objektet ett internt namn. i newS skyltar så är de för det mesta tomma, men det kan vara bra att skilja dem åt.

Rad 9-15 så har vi <Localisation-cUserLocalisedString> följt av några språk. Dessa fält är för att visa vad skylten heter i objekt set-filtret i valda språk. Om simulatorn använder annat språk så är English standard. På vissa filer så har jag endast sett enlish varit ifyllt med ett namn. I mitt exempel så har jag döpt om objektet till SE Tavla U Blå, så det är vad man kommer se när man ska välja objektet och placera ut den i rutteditorn.

På rad 18 hittar vi <Category d:type="cDeltaString">eTrackInfrastructure</Category>. Denna definierar vilken kategori objektet ska synas i. Kategorier man kan välja emellan är (för objekt): eDomesticBuildings, eCommercialIndustrialBuildings, eFoliageWater, eStations, ePeopleAnimalsVehicles, eTrackInfrastructure, eClutter, eBridgesViaductsTunnels, eSounds & eMisc.

På rad 19 hittar vi: <ValidInScenarios d:type="cDeltaString">eFalse</ValidInScenarios>
eFalse = Listas inte när du redigerar i scenarioläget. eTrue = listas även i scenarioläget. Detta kan komma till nytta i vissa scenarier där man vill simulera ett banarbete och behöver tillfälliga skyltar.

Bild2:
På rad 46 så hittar vi GeometryID. Detta är filsökvägen till .GeoPcDx-filen som ska renderas i simulatorn. Skriv inte med filändelsen .GeoPcDx, istället ska [00] ange före filnamnet.

På rad 48 har vi Pickable, detta definierar om du kan klicka på objektet i editorläget för att flytta eller ta bort den. jag rekommenderar eTrue. Är den satt på eFalse så kan man inte välja objektet.
På rad 56 och 57 ska dessa sättas på 10 för att garantera att objektet alltid syns i simulatorn, även för användare som har satt sin detail level lägre än max. Detta kan vara viktigt att ha för signaler och tavlor som ska förmedla tågföraren något.

[ADDE]

I exempel 2 så tittar vi på ett signalobjekt och på childobjekts. I detta exempel så tar jag fram..\Assets\SummerADDE\SwedenV2\RailNetwork\Sign als\SE H3 5L SP.xml

Till en början hittar vi några rader jag har redan gått igenom i exempel 1 ovan. här finns det också en <Description> som jag lämnat tomt just nu. (jag har inte undersökt funktionen närmare.)

Bild 1:
Vi hittar <PrimaryNamedTextureSet> och <SecondaryNamedTextureSet> och där hittar man Provider/product. Lämnar man detta tomt så kommer simulatorn att leta efter en texturfil som .geoPcDx-filen pekar mot relativt till vart .bin/xml-filens provider och product ligger i- Om du däremot fyller i provider och product så kommer texturfilen läsas in relativt till nämna provider/product. Min rekommendation är att ha .bin-filen, .geopcdx-filen och texturfilen udner samma provider/product, men i de fall texturfilen ligger under en annan provider/product så måste du uppmana spelaren att bocka i denna provider/product. (geopcdx-filen läses alltid in.)

Bild2: Dessa rader berör signalobjektets olika funktioner. På rad 87 hittar vi <NumberOfTrackLinks>. Detta räknar antal länkar INKLUSIVE grundlänken. Så om du ska ha en signal som ska ge dig 5 tågvägar så behöver du 6 länkar, 1 länk vid signalen + 5 länkar för varje tågväg.
Vi har också <_script> och i rad 95 så anger du filsökvägen till signalscriptet (en .lua-fil eller en .out-fil, som är en krypterad .lua-fil). Återigen, ange inte filändelse här.

Bild 3:
Nu kommer vi till en intressant del, denna del behandlar child objects. Allting mellan <Children> och </Children> behandlar egenskaper hos child-objekten och flera <Children>-kod kan dyka upp efter varandra för att läsa in olika objekt. Jag brukar använda en metod där filen inte ska läsa in någon geopcdx-fil utan enbart <Children>-objekt. På så vis kan jag få mer kontroll över objektets storlek och orientering.
I rad 103 har vi ChildName, detta används internt för att särskilja på olika child objekt. Sedan har vi provider/product och återigen är det viktigt att användaren bockar i alla provider/products i objekt set-filtret för att alla child object ska läsas in korrekt. I rad 112 så läser vi sedan in filsökvägen till .bin-filen som ska vara child-objektet. Tänk på att den länkade .bin/xml-filen inte kommer läsa in några scripts eller andra egenskaper som den har när den är som ett eget objekt.

Sedan kommer vi till raderna 118-133 och dessa värden definierar childobjektets orientering mot centrumpunkten i ett 4x4 3D-matrix. fördjupning på Matrix här. Man brukar räkna matrixen från 1-16 och värdena påverkar följande: Rad 1, storlek i X-led (vänster-höger) där 1 är standard och 0 är helt platt. Rad 6 är storlek i Y-ed (upp-ner) och rad 11 storlek i Z-led (fram-bak). Rad 13, 14 och 15 är objektets placering i X, Y och Z-led gentemot huvudobjektets orienteringspunkt. Rad 16 är objektets storlek i XYZ-led tillsammans. Övriga värden berör objektets olika vinklar där 0 är objektets standardorientering. För att få objektet att titta åt annat håll så krävs det kombinationer av dessa värden, vilket den länkade guiden ovan länkar till.

Dock kan jag ge exempel på värden för att få objektet att rotera i Y-axeln.
-För att rotera 180 grader så ska rad 2, 7 och 12 ha värdet 1 och resten 0.
-För att rotera 90 grader (åt höger) så ska rad 4 och 7 ha värde 1, rad 10 ha värdet -1 och resten 0.
-För att rotera -90 grader (åt vänster) så ska rad 4 ha -1 och rad 7 och 10 ha värdet 1, resten 0.

[ADDE]

Ursprungligen postat av ADDE

På rad 18 hittar vi <Category d:type="cDeltaString">eTrackInfrastructure</Category>. Denna definierar vilken kategori objektet ska synas i. Kategorier man kan välja emellan är (för objekt): eDomesticBuildings, eCommercialIndustrialBuildings, eFoliageWater, eStations, ePeopleAnimalsVehicles, eTrackInfrastructure, eClutter, eBridgesViaductsTunnels, eSounds & eMisc.

Jag glömde lägga till eExcludeFromBrowserList - som gör att det inte listas med utan blir osynlig.

[ADDE]

Ursprungligen postat av ADDE

Bild 3:
Nu kommer vi till en intressant del, denna del behandlar child objects. Allting mellan <Children> och </Children> behandlar egenskaper hos child-objekten och flera <Children>-kod kan dyka upp efter varandra för att läsa in olika objekt. Jag brukar använda en metod där filen inte ska läsa in någon geopcdx-fil utan enbart <Children>-objekt. På så vis kan jag få mer kontroll över objektets storlek och orientering.
I rad 103 har vi ChildName, detta används internt för att särskilja på olika child objekt.

ChildName har en funktion för att i .lua-scriptning ska man kunna peka mot en childobjekts funktion för att kunna animera och visa rätt signalbilder även på child object. Där är det viktigt att varje child object har ett unikt namn och att varje unikt namn kan pekas rätt i signalscriptet. Men signalscript är nog överkurs i denna guide.