Proseguiamo il tutorial entrando nel vivo del file tracks.bin
Per analizzare la struttura di base, partiamo da una route con un solo binario lungo esattamente 500m e perfettamente diritto.

Faccio una piccola premessa che vale per tutto il tutorial. RW crea dei macro tag che hanno un solo figlio che sembrerebbero inutili, ma che evidentemente servono per una ricerca veloce in-game o per motivi a me non chiari. Per far capire, collasso alcuni di questi livelli.

Alla fin fine si vede che tutto il contenuto è all’interno del costrutto Network-cTrackNetwork. Ho fatto questa premessa perché situazioni di questo tipo si trovano anche all’interno di questo costrutto e quando ciò succede, io analizzerò solo i tag che hanno interesse, non quelli che sembrano solo di contenimento e evidentemente di uso specifico del motore di gioco.

Continuiamo. Dopo aver salvato e analizzando il file tracks.bin, si notano le strutture di base, che sono uguali per qualsiasi route, ma i cui singoli elementi verranno poi complicati a seconda del contenuto.

La prima parte di contenuto inizia con una il tag NetworkID, che contiene ID univoci per tutto il piano binari. Appare qui per la prima volta al suo interno il tag DevString. Di nuovo questo è un GUID univoco che definisce uno specifico dato/oggetto. Non è fondamentale questo specifico caso per il tutorial, ma vedremo che ogni oggetto in RW, compreso scenery object, loft, e in questo tutorial i binari, hanno un DevString che lo identifica univocamente.
Dopo inizia la sezione che ci interessa. Ciò su cui dobbiamo porre la nostra attenzione è la parte interna al tag Network-CRibbonContainerUnstreamed. All’interno di questo costrutto risiede tutto il nostro piano binari.

Questa porzione è divisa in due macro costrutti (nell’immagine sono collassati):
Ribbon. All’interno ci sono tutti i binari con la loro definizione di lunghezza, posizionamento, altitudine, tipo di binario, etc, che vedremo tra poco
Node. Contiene tutti i nodi dei binari, vale a dire inizio-fine di ogni tratto posato, eventuali giunzioni con altri binari, etc.
Avendo posato un solo binario, mi aspetto quindi di vedere 1 elemento sotto Ribbon (1 binario) e 2 elementi sotto Node (inizio e fine).
Espandendo a un livello inferiore il nodo Ribbon e il nodo Node, ottengo effettivamente quanto previsto (linea 17 – 140 – 190):

Ognuna delle nuove voci è identificata anche da un ID. Questo ID è usato in qualche modo da RW, ma non bisogna farci molto affidamento, perché ad ogni salvataggio viene generato da zero, e quindi non è univoco e fisso.
Passo successivo è analizzare il Network-cTrackRibbon. Malgrado il binario sia semplice e senza particolarità quali segnali, milepost o scambi, il numero di linee è elevato. Cominciamo con la prima parte:

Il primo tag è chiaro, definisce la lunghezza del tratto di binario che abbiamo posato, che ricordo essere diritto, di esattamente 500m.
Il secondo tag è il nome univoco di questo tratto di binario all’interno di RW e di conseguenza all’interno di tutti i file della nostra route. Il nome univoco è come detto precedentemente quello all’interno del tag DevString.

Si passa poi alla definizione delle altezze. Preambolo è che la route con il singolo binario è a altezza zero e che il binario non ha variazioni di altezza.
All’interno del tag Height ci sono quindi due coppie di valori relativi ai due estremi. La distanza lineare dell’inizio del binario (0) e la relativa sua altezza (0,3m), e la distanza lineare della fine del binario (500m) e la relativa sua altezza (0,3m). Il valore 0,3 invece di zero è perché il binario e rialzato di 30cm per definizione costruttiva del binario stesso.

Il tag successivo è il RouteVector, che specifica la tile a cui il binario è stato assegnato. La tile è evidentemente univoca se il binario sta completamente al suo interno. Nel caso il binario (come è il caso dell’esempio) attraversa due tile, il motore di gioco ne deve definire una, che usualmente è quella da cui si parte a posare il binario stesso. In questo caso la tile è -000001+000000 e nell’immagine sotto si legge proprio quel numero di tile in basso a sinistra (riquadro rosso).

Ora ci sono due costrutti che definiscono inizio e fine a livello di posizionamento all’interno della tile (o delle tile nel caso il binario sia tra due). E’ corretto che ci sia questo costrutto perché finora sappiamo che il punto iniziale e finale hanno una certa altezza, sappiamo quale è la tile interessata, ma non sappiamo dove e come va posizionato all’interno della tile.

Il primo nodo RBottomLeft definisce X e Z (Y in RW è considerata altezza) del punto di partenza. Per verificarlo nello screenshot qui sotto ho posizionato un cartello esattamente all’inizio del binario e nel riquadro giallo che rappresenta quindi sia il posizionamento del cartello sia il punto iniziale del binario, si vede che sia la X che la Z sono, a meno di approssimazioni dell’editor, identiche a quanto riportato nel file.

NOTA PARTICOLARE: in alcuni casi rari potrebbe succedere che la coordinata sembri diversa, e normalmente succede quando l’oggetto posato per verifica (in questo caso il cartello) ha coordinate date da RW negative. In realtà quando ciò succede, basta fare il complemento a 1024 (che ricordo essere la larghezza della tile) della coordinata dell’oggetto e si ottiene nuovamente il numero corretto. Per es la prima volta che ho posato il cartello, RW ha assegnato alla X il valore -28,9. Se faccio la differenza
1024-28,9 = 995,1 che è di nuovo esattamente cosa è salvato nel file.

Il nodo successivo RExtents è la posizione relativa in X e Z del nodo di arrivo rispetto al punto di partenza. In questo caso io ho steso un binario diritto e parallelo alla direzione X e quindi il primo valore è 0 (non mi sposto a destra o a sinistra rispetto al reticolo di RW). Il secondo, essendo il binario perfettamente diritto, è esattamente uguale alla lunghezza, quindi 500 (a parte ovviamente a piccoli errori di ordine 5 che comunque vengono tenuti in conto). In poche parole il punto di arrivo è allineato al punto di partenza (X=0) e 500m oltre (Z=500).

Gli ultimi due nodi non sono a me chiari, nel senso che sono sempre uguali. Presumo siano nodi per la gestione della fase di editing della route. Ad ogni modo non ho mai visto valori differenti.

Riassumendo, quanto visto finora definisce i punti principali per la gestione del tratto di binario. Non definisce però nessuna delle sue proprietà, per esempio che track rule ho usato, che velocità ho impostato, segnali, curvature, altezze diverse, etc…
Su questo viene in aiuto la sezione successiva, definita nel suo complesso sotto il tag Property che è situato all’interno del tag Network-cPropertyContainer.

Il tag Property può essere piccolo o molto lungo a secondo delle proprietà che sono da applicare a questo tratto di binario. Ovviamente nel nostro caso semplice, siamo proprio al minimo; non abbiamo segnali, abbiamo una sola track rule, non abbiamo variazione di velocità, il binario è di un solo tipo, etc…
All’interno del tag Property nel nostro semplice caso ci devono quindi essere un minimo “sindacale” di sezioni.

NOTA PARTICOLARE. L’ordine di queste sezioni varia salvataggio dopo salvataggio o modifica dopo modifica, quindi elencherò le sezioni ma non aspettatevi di trovarle sempre in quell’ordine, proprio perché per la struttura di RW e dei file xml, l’ordine delle sezioni non è importante, ma è importante il livello a cui sono poste (che è in un xml correttamente scritto equivalente al livello visivo di indentazione del file stesso).

Cominciamo. Una delle sezioni è quella che registra i limiti di velocità del tratto di binario:
E’ importante notare che questa sezione viene creata da RW se e solo se almeno uno dei due limiti è differente da quello di default della trackrule applicata. In questo caso io ho impostato il primario 130km/h invece del default di 120 km/h.

La struttura è chiara, essendo i limiti uguali per tutto il binario. La sezione ci dice quindi che dall’origine (0m) alla fine (500m) la velocità primaria è di 130 e la secondaria di 100.

Vediamo immediatamente cosa succede (anche se sta diventando intuitivo) se modifico il binario e a un certo punto cambio il limite primario a 110 km/h.
Come era prevedibile, questa sezione viene splittata in due parti. La prima viene solo modificata sostituendo a 500 il valore in cui la velocità di 130km/h ora termina, in questo caso 347.713m. Il resto ovviamente non cambia.

La seconda sezione “nuova” (che come detto non necessariamente è subito dopo quella sopra) viene quindi creata con una struttura equivalente.

Come era già chiaro però, lo start point diventa 347.713m, l’ending point rimane 500m, e la velocità primaria è scesa a 110km/h. Da questo piccolo esempio si capisce bene come il file tracks.bin gestisce una certa proprietà del binario (in questo caso la proprietà è la velocità), e come registra i cambiamenti di questa proprietà lungo il tratto di binario stesso. Vedremo questo tipo di strategia ancora in altri casi e per altre proprietà.

La seconda sezione sempre presente anche in casi semplici è quella inclusa nel tag Network-cSectionGenericProperties e che definisce la rappresentazione grafica del binario:

A questo punto è chiaro come procedere. In questo caso il mio binario è di un solo tipo (Cemento usura media, binari bianchi e senza buffer finale il cui modello si chiama RI_Bin_Cem_E3_BBi_NoBuf).

Di nuovo start e end sono chiari, essendo un binario di un solo tipo, si parte da 0 e si finisce a 500m.
Viene poi specificato quale è il Blueprint da applicare (sotto BlueprintID) in termini di provider, product e nome del modello con path completo).
Segue poi una sotto-sezione SecondaryBlueprintID, vuota perché a mia conoscenza non viene usata mai per i binari.
Infine una sotto-sezione simile per il template dell’elettrificazione. Qui viene inserito in fase di salvataggio il blueprint di elettrificazione (catenaria, terza rotaia etc) che RW applica in automatico durante la stesura dei binari (ricavandola dalla track-rule), quando il binario stesso ha elettrificazione di tipo catenaria, terza rotaia o quarta rotaia. Nel mio caso il binario era di tipo terza rotaia senza blueprint assegnato per poter inserire una catenaria customizzata di tipo loft, e quindi rimane vuoto.

Con queste sottosezioni ci sono quindi tutte le informazioni grafiche per poter renderizzare il binario in game.
Abbiamo ormai capito che se ci fossero stati due binari diversi nello stesso tratto, la rispettiva sezione sarebbe state splittata con lo stesso concetto dell’esempio sulla velocità fatto precedentemente.

L’ultima sotto-sezione di Property che manca all’appello è la trackrule da applicare al binario che, appropriatamente, sta all’interno di un tag chiamato Network-cTrackNetworkTrackRule:

Non c’è molto di nuovo da dire qui, se non che di nuovo avendo una sola track rule, la sezione ha i soliti start 0 e end 500 e nelle righe successive è indicato il provider, product e blueprintID della trackrule da applicare.

Per il nostro semplice caso, le proprietà sono terminate e rimangono un paio di costrutti prima di chiudere finalmente il tag che definisce il tratto di binario (ricordo essere il Network-cTrackRibbon):

Prima di chiudere il tag Property, c’è ancora un costrutto che per le esperienze che ho fatto dovrebbe essere un numero progressivo che identifica le modifiche attuate dalla prima posa del binario.

E’ poco importante, mentre sono più importanti i tag Explicit-cDirection e Superelevated. E’ abbastanza intuitivo che il primo registri le direzioni ammesse di transito in quel binario (in questo caso either vuol dire entrambe le direzioni), mentre il secondo indichi se ci sia o no il flag di inclinazione binario attivato (0 vuol dire non attivato).
A differenza di altri tag, questi due valgono per l’intero tratto di binario e non è possibile avere queste caratteristiche settate in maniera diversa all’interno dello stesso tratto di binario.

A questo punto siamo giunti alla fine della parte del nodo di Ribbon del nostro semplicissimo binario. Nel prossimo tutorial faremo una deviazione sulla trackrule, che rimetterà un po’ in discussione quanto fatto finora, per poi analizzare il Node e il file sotto la cartella Track Tile.