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.