TrainzOnline - User contributions [en]

Routes compatibility with enhanced interlocking towers

2023-12-08T14:31:12Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : VR 2pos sem home signals bt VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : VR 2pos sem signals by VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : G style trilight signal 04 et 06 by Ryanstrains (using G Signal Library from Jointed Rails)
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : Sig AS Signals by Francelinetony, Sig LMS by Francelinetony, Sig UK by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T14:30:00Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : VR 2pos sem home signals bt VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : VR 2pos sem signals by VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : G style trilight signal 04 et 06 by Ryanstrains (using G Signal Library from Jointed Rails)
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : Sig AS Signals by Francelinetony, Sig LMS by Francelinetony, Sig UK by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T14:29:23Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : VR 2pos sem home signals bt VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : VR 2pos sem signals by VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : G style trilight signal 04 et 06 by Ryanstrains (using G Signal Library from Jointed Rails)
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : Sig AS Signals by Francelinetony, Sig LMS by Francelinetony, Sig UK by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T14:22:01Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : VR 2pos sem home signals bt VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : VR 2pos sem signals by VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : G style trilight signal 04 et 06 by Ryanstrains (using G Signal Library from Jointed Rails)
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T14:12:56Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : VR 2pos sem home signals bt VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : VR 2pos sem signals by VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - some signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T14:10:54Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : VR 2pos sem home signals bt VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : VR 2pos sem signals by VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T14:07:12Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : VR 2pos sem home signals bt VicTrainz
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
CRM Ottertail to Castle Jct
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T14:00:53Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : VSM Hv-Hsig, VSM Hv-Vsig, VSM Zusatzsignal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
CRM Ottertail to Castle Jct
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T13:57:40Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : UZ a bixod 4, UZ a bixod 5, UZ a bxod5, UZ a Karlik bixod 3, UZ a Karlik bixod 4, ...
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
CRM Ottertail to Castle Jct
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T13:43:37Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
CRM Ottertail to Castle Jct
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T13:43:03Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : Sig BR(W) Cornish 04, Sig BR(W) Cornish 08, Sig BR(W) Home 15ft, Sig BR(W) Home 20ft, Sig BR(W) Home 20ft RHS+18
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
CRM Ottertail to Castle Jct
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T13:39:10Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : Safetran Clight Signal 04, Safetran Clight Signal 05, Safetran Clight Signal 06, Safetran Clight Signal 08
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
CRM Ottertail to Castle Jct
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T13:36:19Z

Pguy:

{{FUN-top}}

<table bgcolor="green">
<tr><td>
<span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been checked for main signals compatibility with Trainz standards, en entry will be added to the list of checked routes to indicate if the route is compatible or not with Interlocking Towers and Enhanced Interlocking Towers</span>
</td></tr>
</table>

===Builtin and DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Healesville
</span>
</td></tr></table>
::signals used on route : VR 2Pos sem signal family
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Avery - Drexel
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Warwick to Wallangarra
</span>
</td></tr></table>
::signals used on route : NSW Semaphore home
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
The BiDye Traction Railroad
</span>
</td></tr></table>
::signals used on route : Signal US&S type B Block distant semaphore
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Season Town Northern Rail Road
</span>
</td></tr></table>
::signals used on route : TUME 23135, TUME 23136 Signal
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS19 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Canadian Rocky Mountains - Golden BC
</span>
</td></tr></table>
::signals used on route : SL2 SL Supersignal and RRS SL Supersignal library
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Cornish Mainlines and Branches - TRS19
</span>
</td></tr></table>
::signals used on route : GWR Semaphores by jetstreamsky
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
ECML Kings Cross - Edinburgh
</span>
</td></tr></table>
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Kickstarter County 2
</span>
</td></tr></table>
::signals used on route : Sig_US1_01L, Sig_US1_01R,Sig_US1_02L, Sig_US1_02R,Sig_US1_03L,Sig_US1_03R,Sig_US1_04,Sig_US1_05 ... by Auran
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="red">
<tr>
<td>
<span style="color: white; font-weight: 700;">
:Niddertalbahn - TRS19
</span></td>
</tr>
</table>
::main signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not fully compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Sebino Lake Italy
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

====TRS22 Routes====
-----
<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
West from Denver
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Liskeard to Looe, UK
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Beloreck - South Ural Mountains
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Schwaninger Land
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Bairnsdale to Orbost
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
CRM Ottertail to Castle Jct
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
VR Healesville 1913-1920
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Andrushivka - Vinnitsa UZ
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Coal Country
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

<table bgcolor="green"><tr><td>
<span style="color: white; font-weight: 700;">
Trainz Route: Potteries Loop Line
</span>
</td></tr></table>
::signals used on route : IS FS Signals
::ITs/EITs compatibility : <span style="color: green;">YES - signals scripts are compliant to Trainz signals scripts standard</span>

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with enhanced interlocking towers

2023-12-08T10:10:07Z

Pguy:

Routes compatibility with enhanced interlocking towers

2023-12-08T09:34:42Z

Pguy:

Routes compatibility with Enhanced Interlocking Tower

2023-12-08T07:52:41Z

Pguy: Redirected page to Routes compatibility with enhanced interlocking towers

#REDIRECT [[Routes_compatibility_with_enhanced_interlocking_towers]]

DLC Routes compatibility with Enhanced Interlocking Tower

2023-12-08T07:50:57Z

Pguy: Redirected page to Routes compatibility with enhanced interlocking towers

#REDIRECT [[Routes_compatibility_with_enhanced_interlocking_towers]]

DLC Routes compatibility with Enhanced Interlocking Tower

2023-12-08T07:48:55Z

Pguy: Pguy moved page DLC Routes compatibility with Enhanced Interlocking Tower to Routes compatibility with Enhanced Interlocking Tower

#REDIRECT [[Routes compatibility with Enhanced Interlocking Tower]]

Routes compatibility with Enhanced Interlocking Tower

2023-12-08T07:48:55Z

Pguy: Pguy moved page DLC Routes compatibility with Enhanced Interlocking Tower to Routes compatibility with Enhanced Interlocking Tower

Enhanced Interlocking Tower

2023-12-08T07:46:27Z

Pguy:

{{FUN-top}}

===Enhanced Interlocking Tower assets===
[[Poste de Contrôle et de Régulation|Version française : Postes de Contrôle et Régulation]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

'''Enhanced Interlocking Tower''' assets are 3rd party scripted assets which extend the Interlocking Tower with some extra features. By doing some pre-processing before calling standard interlocking tower processing and doing some post-processing on return, these new assets enable the user to take the best from interlocking towers and to offer some enhanced functionalities by default or on option.

Among these added functionalities you will find :

: '''at the path level :'''

::* path supports that an exit signal is also an entry signal from another tower<br>
::* path will be activated only if there are no extra consist currently occupying the path. If it is not the case, path activation will be delayed until there is no longer any extra consist on path.<br>
::* path can be cancelled using a specific driver command or using the enhanced interlocking manager rule run time monitor. Cancelling a path can occur at any time for an owning train which is stopped, and for an owning train moving only if there are at least two signals between the train position and the path entry signal. To avoid any derailment risk, paths junctions currently overlapped by a consist will not restore their initial direction.<br>
::* path can use several clear method : clear on cancel is the traditional clear method used with standard IT ; clear_on_drive enables to release junctions and signals when your train has left the junction or signal so that these objects are made available for any waiting other path before the initial path is cleared ; clear_on_last_junction will clear the path when the last junction along the path has been left : this method may be used at terminal station with path having the buffer at the end of the track being the exit signal - though the exit signal will never be reached, the path will be cleared when the last junction will be left.<br>
::* path can optionally check if a track circuit block embedding the exit signal is occupied or not, and will lock the track circuit block name until the path is cleared. It is also possible to request that all track circuit blocks embedding any path objects (except the path entry signal) will be processed in a similar manner. Using exit signal TCB can help a lot to protect terminal or through station platforms.<br>
::* path can optionally choose either to restore path junctions initial direction when a path is cleared or to do not restore path junctions initial direction and keep the current target direction when the path was active.<br>
::* path can optionally be member of an exclusive set name, and will have their activation delayed as long as any other path referencing the same exclusive set name is active. This feature enables to protect easily track crossing without using some invisible junctions or signals.<br>

: '''at the tower level :'''

::* it is possible to choose if the yellow disc used to reselect a target path is displayed or not.<br>
::* processing on train schedule blocked can be choosen : you may either use the standard IT implementation that will try to cancel and reactivate later unused paths (paths owned but not already entered) which may help activating a path for a train with schedule blocked at an entry signal.You may also avoid this standard processing by disabling the option.<br>
::* since release 47 available in 03/2018 on DLS, you can choose between static and dynamic ownership for path objects ownership. Path entry signals are in both cases always owned by the interlocking tower for all the session duration. With static ownership, all paths objects are also owned by the tower for the session duration. With dynamic ownership, ownership for path objects not being an entry signal is taken only on path activation and is released when the path is released. With this dynamic option, path objects ownership last only for the duration of the path being active (for all objects except path entry signals which are always owned for the session duration).<br>
::* trc compatibility : it is possible to choose at the tower level if crossing conformant to TRC system will be managed by the interlocking tower or by the trc system.<br>
::* tower debug level : this option is mainly for session developers. It enables to have either no logging (for production), or only logging to the system log, or to have both logging and messages on screen.<br>
::* since release 60 available in 02/2019 on DLS, EIT supports PathTrigger object placed on track, that makes possible to adjust (increase or decrease) the distance to the entry signal at which automatic path selection is done for the incoming train.

=== Enhanced Interlocking Tower : How to use them ?===

To use enhanced interlocking tower, you need to drop on your route an enhanced interlocking tower like the enhanced trc3 interlocking tower <kuid2:61392:8101:4> available on dls. Some other content creators will shortly also release some other enhanced interlocking tower asset. In fact any scenery asset can be defined as an enhanced interlocking tower by using the adequate configuration file.

'''List of available enhanced interlocking tower on DLS (at current date 03/03/2018) :'''

Enhanced trc3 invisible interlocking tower <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

[[CDE Enhanced TRC3 invisible Interlocking Tower]] <kuid:647907:100961> by Christopher824 (added 6/9/2021)

When you have installed on your route the enhanced interlocking tower you want to use, you only need to edit the object property by clicking on it to open the standard editor window. For enhanced interlocking tower, the editor window includes options that can be selected in the header at the top of the tower object properties window.

==== Editing enhanced Interlocking tower : options available in the tower editor window ====

[[File:Help-eit-assets-img02.png | 768px | none ]]

The available options in the header at the tower level are :

:* '''tower display yellow disc option :'''
::by clicking on the link on the right, you can either choose display yellow disc enabled or disabled

:* '''tower path requery option :'''
::this option is on how to process AI trains with schedule blocked. It can either be '''try requery path on schedule blocked''' or '''do not requery path on schedule blocked'''. With requery path option active, when an AI train has its schedule blocked, the enhanced IT will try to release unused paths (paths owned but not entered) to enable some other paths to be activated. The unused paths released are requeued for later activation. This standard processing done in standard IT may help to find a solution to some AI schedule blocked, but may have some side effects as some activated path may be cancelled before being later reactivated. If you do not want this behavior, just change the option to do not requery path on schedule blocked and no processing will be done when an AI train has its schedule blocked.

:* '''tower dynamic ownership option (available since release 47 march 2018) :'''
::this option is on how the tower will take ownership of all its paths objects (entry signal, exit signal, other signals, junctions, crossings, ...). Entry signals are always owned by the tower for all the session duration whatever the option choosen. With static ownership, it is the same for all paths objects for which ownership will also be taken for all the session duration. With dynamic ownership, path object ownership is taken only on path activation and will be released when the path returns to path not set state. With dynamic ownership, a path object belonging to one or several paths currently not activated is no longer owned by the tower and can be used by other components for manual operation. This may be usefull for sidings where you can have the junctions unlocked available for manual operations when no paths using this junction are active.

:* '''tower trc compatible mode :'''
::when this option is active, crossings conformant to trc system specification will not be managed by interlocking tower. Trc crossing objects will be skipped with no tower ownership and will remain managed by the trc system. if the option is inactive, interlocking tower will manage all the crossings along its path.

:* '''tower debug level :'''
::tower debug level option is an option available that help session developper to understand interlocking tower problems. Interlocking tower have an integrated debugging facility by default disabled. By selecting only log debug information or log and print debugging information, you will activate the debugging facility which may help to understand some conflicting or deadlock problems using interlocking tower.

at the bottom of the header area, you will find a link '''Restore default options''' that enables to reset all the current enhanced options to the default values defined by the enhanced tower asset content creator.

==== Editing enhanced Interlocking tower path : options available in the path editor window ====

[[File:Help-eit-assets-img03.png | 768px | none ]]

The available options in the header at the path level are :

:* '''Path clear method to use :'''
::you can here select the path clear method to be used between '''Clear on cancel (when a path is either complete or cancelled)''' , '''Clear on drive (following train progress along the path)''' and '''Clear after last junction (when the train leaves the last junction along the path)'''. Clear on cancel is the standard IT clear method that can still be selected. Clear on cancel will release path objects locks when the owning train leaves the path object. With clear on drive, the path will still be cleared and cancelled only when the train will leaves the exit signal, but path objects are unlocked as soon as the train has left them and are made available for other conflicting paths to be activated earlier. Clear after last junction will clear and cancel the path as soon as the owning train has left the last junction along the path and will not wait for the train to reach and leave the exit signal. Clear on last junction may be an interesting option for path leading to an and of track with a buffer. You can use the buffer as the exit signal, and though the owning train will never leave the buffer exit signal, the path will be cleared as soon as the train will have left the last junction along the path.

:* '''Path track circuit blocks mode :'''
::this option can either be '''no tcb processing''' , '''process only tcb for exit signal''' or '''process all tcbs along path'''. With process only tcb for exit signal, before activation, the path will look if its exit signal is embedded in some track circuit block, and if it is the case will check that the track circuit block is not occupied and not locked. If it is not the case, path activation will be delayed until the previous conditions are met. When the exit tcb is unoccupied and unlocked, path will be activated but will also lock the tcb name while the path is active. Doing so enables to guarantee that a path is activated only when a tcb embedding the exit signal is not occupied and locking its name enables to prevent other paths to activate while the initial path is active even if there are no common paths objects between the paths. Exit signal tcb are very usefull for terminal station platforms, for through station platforms and for unique track between two several passing places. As several interlocking tower paths from distinct towers can have their exit signal embedded in the same tcb, this facility also enables to do some interlocking between paths form distinct towers. Using the process all tcbs option along path enables to do the same processing for all the tcbs embedding some path objects and not only for the exit signal tcb.

:* '''Path clear option for owned junctions :'''
::this option enable to either restore the junction initial direction (default used by standard it) or to do not restore junctions initial direction when a path is cleared. This option is available mainly for prototypical behavior as sometimes it is not very prototypical to have a junction having its initial direction restored because a path has been cleared followed by rechanging the direction due to another path being activated. With this option you avoid successive inadequate direction changes for junctions.

:* '''Exclusive sets membership :'''
::exclusive sets membership is an option that has been designed to help protect a crossing of tracks without the need to add some invisible junctions using these junctions as external object reference. When you add an exclusive set name in this field, the path will only be activated if no other paths in any tower with also the same exclusive set name is active. Paths sharing the same exclusive set name cannot be simultaneously active and this works inside the same tower as inside any tower on your route. To protect a crossing of track, you need only to give a unique name to this crossing of track and reference this name as an exclusive set name in all your paths using this crossing of tracks. It is much more easy to use than using invisible junctions with external references in paths.
::You can enter in this field either only one name or several names separated by a comma. Exclusive set name A will be displayed in the field as A. Exclusive set names A , B will be displayed as an exclusive set names list [A,B]. What is important is that you can enter either one name or several names separated by commas. When several names have been listed, the path belongs to all the exclusive set names and will check that no paths active are referencing any of these names before activating the path. This feature is very usefull to protect crossing tracks, and also slips and double-slips.

At the bottom of the header, you have also two links available : the '''restore default options''' link will restore all the default values for the enhanced options for the current path. The '''make current path options default options''' will change the default options in the current tower to be the current path options. Using these options link, it is quite easy to retrieve some path options and to propagate them to some other paths.

===== And now below a few tips on how to use some of the enhanced options =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]]

===== How to ajust the default distance for automatic path selection =====

By default, automatic path selection is called when an incoming train approaches an entry signal at about 0.5 mile. But since version 60 available from DLS in 02/2019, you can adjust (increase or decrease) this default distance by using specific path trigger object ( <kuid2:61392:8121:1> ). When you place a path trigger object, automatic path selection will be called when the incoming train reaches the last path trigger object before the entry signal (the train needs to have the track already set in the correct direction to go to the entry signal). If the path trigger is reached before the standard 0.5 mile distance, automatic path selection will be done with an increased distance from the entry signal. If when the train arrives at the standard distance, the system find there is a path trigger between the train and the entry signal, automatic path selection will be delayed until the train reaches the path trigger, and automatic path selection will be done at a reduced distance from the entry signal. Path trigger works only with EIT and not at all with standard ITs.

===== How to activate easily a path for a train using ITSetPath family driver commands =====

An easy method to activate a path for a train is to use one of the three driver commands ITSetPath (<kuid:61392:8111>) , ITSetPathAndWaitNotRed (<kuid:61392:8112>) or ITSetPathAndWaitActive ( <kuid:61392:8113>). These three driver commands enable the user to choose the interlocking tower and the path to request for the current driver when the driver command is executed. ITSetPath will only request the path activation and will immediately terminates, giving control to the next driver command in the train schedule. ITSetPathAndWaitNotRed will also request the path activation, but will wait until the path has been activated and the entry signal is not red before terminating and giving control to the next command. ITSetPathAndWaitActive will request the path activation and will wait for the path being active but will terminates giving control to the next command even if entry signal is still red. This last command may be usefull to set a path to drive and couple to another consist just after the entry signal.

==== Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file ====

Like for standard interlocking tower, any scenery asset can be transformed in an enhanced interlocking tower asset by making a few modifications to the config file.

You will find below as an example, taken from the config.txt file for the enhanced trc3 invisible interlocking tower, all the lines you need to have in your own asset config.txt so that your asset becomes an enhanced interlocking tower. Other lines like your asset kuid number, description, username, ... should remain unchanged.

'''List of lines needing to be present for a scenery asset to become an enhanced interlocking tower asset (in SP2 or later) :'''

<nowiki>
trainz-build 4.5
kind "interlocking-tower"
script "dummyinterlockingtower.gs"
class "DummyInterlockingTower"
category-class "IT"

extensions
{
generic-61392
{
assetid "enhancedinterlockingtower"

eitoptions
{
displayyellowdisc 0
pathrequeryonscheduledblocked 1
trcsupport 1
debuglevel 0
clearmethod 1
checktcb 1
resetjunctions 1
edityellowdisc 2
editpathrequery 2
edittrcsupport 2
editdebuglevel 2
editclearmethod 2
editchecktcb 2
editresetjunctions 2
editexclusivesets 2
}

colors-61392
{
cunselect "bbf5bb"
cselect "f5bbbb"
clink "ffffff"
cnrm "c0c0c0"
cwhite "ffffff"
calert "ff0000"
}
}
}

script-include-table
{
commondata <kuid:61392:4050>
esvlib <kuid:61392:4052>
eitlib <kuid:61392:8190>
trcitlib <kuid:61392:8191>
}

kuid-table
{
sessvar <kuid:-3:10197>
sessvars <kuid:-3:10197>
commondata <kuid2:61392:4050:51>
esvlib <kuid2:61392:4052:4>
eitlib <kuid2:61392:8190:47>
trcitlib <kuid:61392:8191>
0 <kuid:61392:4050>
1 <kuid:61392:8190>
2 <kuid:61392:4052>
}
</nowiki>

Just only a few comments on some of these mandatory lines in config.txt file :

The trainz-build tag needs to be at least 4.5 for any interlocking tower in SP2 or later. The kind tag should always be "interlocking-tower". The script and class should be "dummyinterlockingtower.gs" and "DummyinterlockingTower" and should respect the case for the class tag. And the category-class tag should be "IT". These tags are mandatory and should not be changed.

In the extensions part, default values for enhanced options are defined and may be changed if you wish to change the default values in your enhanced interlocking tower asset.

displayyellowdisctag is 0 for yellow disc disabled or 1 for yellow disc enabled.

pathrequeryonscheduleblocked should be 0 to disable requery and 1 to enable requery when an ai train has its schedule blocked.

trcsupport should be 1 to support trc system and 0 if not.

debug level should be 0 for no debugging, 1 for log only debugging message and 2 for log and print debugging messages

clear method should be 1 to clear on cancel, 2 for clear on drive, and 101 for clear after last junction. Other values may lead to unexpected results.

checktcb should be 0 for no tcb processing, 1 for process only exit tcb, 2 for process all tcbs along path.

reset junctions should be 0 to avoid reseting junctions direction when a path is cleared and 1 to reset junctions when a path is cleared.

and that's all for default values settings. The following tags will define if an enhanced option is not visible (0), displayed only (1), or displayed and editable (2).
the tags edityellowdisc, editpathrequery, edittrcsupport, editdebuglevel, editclearmethod, editchecktcb, editresetjunctions, editexclusivesets can be set to one of these values (0, 1, 2) to make the enhanced option not visible, displayed in read-only mode, or displayed and editable.
By configuring these extensions tags, an enhanced interlocking tower content creator can choose the default values for an option, and decide if it can be viewed or not, and if the end user can change the default values. For example, if trcsupport is set to 1 and edittrcsupport is set to 0, the tower will have the trc support option enabled, but not displayed and so not updatable by the end user. Using these tags the asset content creator can enforce any of the enhanced options value.

the other tags cunselect, cselect, clink, cnrm, cwhite, calert defines the colors to be used in the interface. You should not normally alter these values, but if you don't like the colors scheme used, you may alter these values to change the colors used in the interface. The string values defined for each tag are only the RGB hexadecimal values for the color to be used for this category of information.

and the last containers script-include-table and kuid-table should be left unchanged for the enhanced interlocking tower to work correctly.

=== Enhanced Interlocking Tower Manager Rule : How to monitor at run time your towers, paths and trains ===

Enhanced Interlocking Tower Manager Rule is a session rule that is released with the Enhanced Interlocking Tower package. Under Surveyor it enables editing of your towers and paths from a centralized interface, and under Driver it provides a run time monitor to display current available information on your towers, paths and trains using or waiting for any path.

The rule is available on DLS under the KUID <kuid2:61392:8130:47>. The rule works with both standard interlocking towers and enhanced interlocking towers.

To get more details on what this rule can display, just click on the following link to the [[Enhanced Interlocking Tower Manager Rule]] dedicated page.:

That is currently all for Enhanced Interlocking Tower assets wiki documentation.
I hope you will enjoy these new assets to help you using more versatile and powerfull interlocking tower.
And if you need more details or have unanswered questions, do not hesitate to post in the forums or to send me a private message.
Regards. Pierre GUY (61392)

==See Also==
*[[Routes_compatibility_with_enhanced_interlocking_towers|Routes compatibility with Enhanced Interlocking Towers]]
*[[HowTo/Configure_An_Interlocking_Tower]]
*[[Enhanced_Interlocking_Tower_Manager_Rule]]
*[[Enhanced_Interlocking_Tower_Tip_001]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with Enhanced Interlocking Tower

2023-12-08T07:36:24Z

Pguy: Blanked the page

Routes compatibility with enhanced interlocking towers

2023-12-08T07:35:15Z

Pguy: Created page with "{{FUN-top}} <table bgcolor="green"> <tr><td> <span style="color: white; font-weight: 700;">This page is under construction. After a builtin or a DLC route will have been chec..."

Routes compatibility with Enhanced Interlocking Tower

2023-12-08T06:44:36Z

Pguy:

Routes compatibility with Enhanced Interlocking Tower

2023-12-08T04:05:43Z

Pguy:

{{FUN-top}}

===DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====

:Chesapeake & Ohio RR, Hinton Division
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:ECML Kings Cross
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES</span>

:Healesville
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Kickstarter County
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Avery - Drexel
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Warwick to Wallangarra
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:The BiDye Traction Railroad
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Season Town Northern Rail Road
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

... to be completed ...

====TRS19 Routes====

:Niddertalbahn - TRS19
::signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not compliant to Trainz signals scripts standard</span>

... to be completed ...

====TRS22 Routes====

... to be completed ...

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Enhanced Interlocking Tower

2023-12-08T04:04:04Z

Pguy:

{{FUN-top}}

===Enhanced Interlocking Tower assets===
[[Poste de Contrôle et de Régulation|Version française : Postes de Contrôle et Régulation]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

'''Enhanced Interlocking Tower''' assets are 3rd party scripted assets which extend the Interlocking Tower with some extra features. By doing some pre-processing before calling standard interlocking tower processing and doing some post-processing on return, these new assets enable the user to take the best from interlocking towers and to offer some enhanced functionalities by default or on option.

Among these added functionalities you will find :

: '''at the path level :'''

::* path supports that an exit signal is also an entry signal from another tower<br>
::* path will be activated only if there are no extra consist currently occupying the path. If it is not the case, path activation will be delayed until there is no longer any extra consist on path.<br>
::* path can be cancelled using a specific driver command or using the enhanced interlocking manager rule run time monitor. Cancelling a path can occur at any time for an owning train which is stopped, and for an owning train moving only if there are at least two signals between the train position and the path entry signal. To avoid any derailment risk, paths junctions currently overlapped by a consist will not restore their initial direction.<br>
::* path can use several clear method : clear on cancel is the traditional clear method used with standard IT ; clear_on_drive enables to release junctions and signals when your train has left the junction or signal so that these objects are made available for any waiting other path before the initial path is cleared ; clear_on_last_junction will clear the path when the last junction along the path has been left : this method may be used at terminal station with path having the buffer at the end of the track being the exit signal - though the exit signal will never be reached, the path will be cleared when the last junction will be left.<br>
::* path can optionally check if a track circuit block embedding the exit signal is occupied or not, and will lock the track circuit block name until the path is cleared. It is also possible to request that all track circuit blocks embedding any path objects (except the path entry signal) will be processed in a similar manner. Using exit signal TCB can help a lot to protect terminal or through station platforms.<br>
::* path can optionally choose either to restore path junctions initial direction when a path is cleared or to do not restore path junctions initial direction and keep the current target direction when the path was active.<br>
::* path can optionally be member of an exclusive set name, and will have their activation delayed as long as any other path referencing the same exclusive set name is active. This feature enables to protect easily track crossing without using some invisible junctions or signals.<br>

: '''at the tower level :'''

::* it is possible to choose if the yellow disc used to reselect a target path is displayed or not.<br>
::* processing on train schedule blocked can be choosen : you may either use the standard IT implementation that will try to cancel and reactivate later unused paths (paths owned but not already entered) which may help activating a path for a train with schedule blocked at an entry signal.You may also avoid this standard processing by disabling the option.<br>
::* since release 47 available in 03/2018 on DLS, you can choose between static and dynamic ownership for path objects ownership. Path entry signals are in both cases always owned by the interlocking tower for all the session duration. With static ownership, all paths objects are also owned by the tower for the session duration. With dynamic ownership, ownership for path objects not being an entry signal is taken only on path activation and is released when the path is released. With this dynamic option, path objects ownership last only for the duration of the path being active (for all objects except path entry signals which are always owned for the session duration).<br>
::* trc compatibility : it is possible to choose at the tower level if crossing conformant to TRC system will be managed by the interlocking tower or by the trc system.<br>
::* tower debug level : this option is mainly for session developers. It enables to have either no logging (for production), or only logging to the system log, or to have both logging and messages on screen.<br>
::* since release 60 available in 02/2019 on DLS, EIT supports PathTrigger object placed on track, that makes possible to adjust (increase or decrease) the distance to the entry signal at which automatic path selection is done for the incoming train.

=== Enhanced Interlocking Tower : How to use them ?===

To use enhanced interlocking tower, you need to drop on your route an enhanced interlocking tower like the enhanced trc3 interlocking tower <kuid2:61392:8101:4> available on dls. Some other content creators will shortly also release some other enhanced interlocking tower asset. In fact any scenery asset can be defined as an enhanced interlocking tower by using the adequate configuration file.

'''List of available enhanced interlocking tower on DLS (at current date 03/03/2018) :'''

Enhanced trc3 invisible interlocking tower <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

[[CDE Enhanced TRC3 invisible Interlocking Tower]] <kuid:647907:100961> by Christopher824 (added 6/9/2021)

When you have installed on your route the enhanced interlocking tower you want to use, you only need to edit the object property by clicking on it to open the standard editor window. For enhanced interlocking tower, the editor window includes options that can be selected in the header at the top of the tower object properties window.

==== Editing enhanced Interlocking tower : options available in the tower editor window ====

[[File:Help-eit-assets-img02.png | 768px | none ]]

The available options in the header at the tower level are :

:* '''tower display yellow disc option :'''
::by clicking on the link on the right, you can either choose display yellow disc enabled or disabled

:* '''tower path requery option :'''
::this option is on how to process AI trains with schedule blocked. It can either be '''try requery path on schedule blocked''' or '''do not requery path on schedule blocked'''. With requery path option active, when an AI train has its schedule blocked, the enhanced IT will try to release unused paths (paths owned but not entered) to enable some other paths to be activated. The unused paths released are requeued for later activation. This standard processing done in standard IT may help to find a solution to some AI schedule blocked, but may have some side effects as some activated path may be cancelled before being later reactivated. If you do not want this behavior, just change the option to do not requery path on schedule blocked and no processing will be done when an AI train has its schedule blocked.

:* '''tower dynamic ownership option (available since release 47 march 2018) :'''
::this option is on how the tower will take ownership of all its paths objects (entry signal, exit signal, other signals, junctions, crossings, ...). Entry signals are always owned by the tower for all the session duration whatever the option choosen. With static ownership, it is the same for all paths objects for which ownership will also be taken for all the session duration. With dynamic ownership, path object ownership is taken only on path activation and will be released when the path returns to path not set state. With dynamic ownership, a path object belonging to one or several paths currently not activated is no longer owned by the tower and can be used by other components for manual operation. This may be usefull for sidings where you can have the junctions unlocked available for manual operations when no paths using this junction are active.

:* '''tower trc compatible mode :'''
::when this option is active, crossings conformant to trc system specification will not be managed by interlocking tower. Trc crossing objects will be skipped with no tower ownership and will remain managed by the trc system. if the option is inactive, interlocking tower will manage all the crossings along its path.

:* '''tower debug level :'''
::tower debug level option is an option available that help session developper to understand interlocking tower problems. Interlocking tower have an integrated debugging facility by default disabled. By selecting only log debug information or log and print debugging information, you will activate the debugging facility which may help to understand some conflicting or deadlock problems using interlocking tower.

at the bottom of the header area, you will find a link '''Restore default options''' that enables to reset all the current enhanced options to the default values defined by the enhanced tower asset content creator.

==== Editing enhanced Interlocking tower path : options available in the path editor window ====

[[File:Help-eit-assets-img03.png | 768px | none ]]

The available options in the header at the path level are :

:* '''Path clear method to use :'''
::you can here select the path clear method to be used between '''Clear on cancel (when a path is either complete or cancelled)''' , '''Clear on drive (following train progress along the path)''' and '''Clear after last junction (when the train leaves the last junction along the path)'''. Clear on cancel is the standard IT clear method that can still be selected. Clear on cancel will release path objects locks when the owning train leaves the path object. With clear on drive, the path will still be cleared and cancelled only when the train will leaves the exit signal, but path objects are unlocked as soon as the train has left them and are made available for other conflicting paths to be activated earlier. Clear after last junction will clear and cancel the path as soon as the owning train has left the last junction along the path and will not wait for the train to reach and leave the exit signal. Clear on last junction may be an interesting option for path leading to an and of track with a buffer. You can use the buffer as the exit signal, and though the owning train will never leave the buffer exit signal, the path will be cleared as soon as the train will have left the last junction along the path.

:* '''Path track circuit blocks mode :'''
::this option can either be '''no tcb processing''' , '''process only tcb for exit signal''' or '''process all tcbs along path'''. With process only tcb for exit signal, before activation, the path will look if its exit signal is embedded in some track circuit block, and if it is the case will check that the track circuit block is not occupied and not locked. If it is not the case, path activation will be delayed until the previous conditions are met. When the exit tcb is unoccupied and unlocked, path will be activated but will also lock the tcb name while the path is active. Doing so enables to guarantee that a path is activated only when a tcb embedding the exit signal is not occupied and locking its name enables to prevent other paths to activate while the initial path is active even if there are no common paths objects between the paths. Exit signal tcb are very usefull for terminal station platforms, for through station platforms and for unique track between two several passing places. As several interlocking tower paths from distinct towers can have their exit signal embedded in the same tcb, this facility also enables to do some interlocking between paths form distinct towers. Using the process all tcbs option along path enables to do the same processing for all the tcbs embedding some path objects and not only for the exit signal tcb.

:* '''Path clear option for owned junctions :'''
::this option enable to either restore the junction initial direction (default used by standard it) or to do not restore junctions initial direction when a path is cleared. This option is available mainly for prototypical behavior as sometimes it is not very prototypical to have a junction having its initial direction restored because a path has been cleared followed by rechanging the direction due to another path being activated. With this option you avoid successive inadequate direction changes for junctions.

:* '''Exclusive sets membership :'''
::exclusive sets membership is an option that has been designed to help protect a crossing of tracks without the need to add some invisible junctions using these junctions as external object reference. When you add an exclusive set name in this field, the path will only be activated if no other paths in any tower with also the same exclusive set name is active. Paths sharing the same exclusive set name cannot be simultaneously active and this works inside the same tower as inside any tower on your route. To protect a crossing of track, you need only to give a unique name to this crossing of track and reference this name as an exclusive set name in all your paths using this crossing of tracks. It is much more easy to use than using invisible junctions with external references in paths.
::You can enter in this field either only one name or several names separated by a comma. Exclusive set name A will be displayed in the field as A. Exclusive set names A , B will be displayed as an exclusive set names list [A,B]. What is important is that you can enter either one name or several names separated by commas. When several names have been listed, the path belongs to all the exclusive set names and will check that no paths active are referencing any of these names before activating the path. This feature is very usefull to protect crossing tracks, and also slips and double-slips.

At the bottom of the header, you have also two links available : the '''restore default options''' link will restore all the default values for the enhanced options for the current path. The '''make current path options default options''' will change the default options in the current tower to be the current path options. Using these options link, it is quite easy to retrieve some path options and to propagate them to some other paths.

===== And now below a few tips on how to use some of the enhanced options =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]]

===== How to ajust the default distance for automatic path selection =====

By default, automatic path selection is called when an incoming train approaches an entry signal at about 0.5 mile. But since version 60 available from DLS in 02/2019, you can adjust (increase or decrease) this default distance by using specific path trigger object ( <kuid2:61392:8121:1> ). When you place a path trigger object, automatic path selection will be called when the incoming train reaches the last path trigger object before the entry signal (the train needs to have the track already set in the correct direction to go to the entry signal). If the path trigger is reached before the standard 0.5 mile distance, automatic path selection will be done with an increased distance from the entry signal. If when the train arrives at the standard distance, the system find there is a path trigger between the train and the entry signal, automatic path selection will be delayed until the train reaches the path trigger, and automatic path selection will be done at a reduced distance from the entry signal. Path trigger works only with EIT and not at all with standard ITs.

===== How to activate easily a path for a train using ITSetPath family driver commands =====

An easy method to activate a path for a train is to use one of the three driver commands ITSetPath (<kuid:61392:8111>) , ITSetPathAndWaitNotRed (<kuid:61392:8112>) or ITSetPathAndWaitActive ( <kuid:61392:8113>). These three driver commands enable the user to choose the interlocking tower and the path to request for the current driver when the driver command is executed. ITSetPath will only request the path activation and will immediately terminates, giving control to the next driver command in the train schedule. ITSetPathAndWaitNotRed will also request the path activation, but will wait until the path has been activated and the entry signal is not red before terminating and giving control to the next command. ITSetPathAndWaitActive will request the path activation and will wait for the path being active but will terminates giving control to the next command even if entry signal is still red. This last command may be usefull to set a path to drive and couple to another consist just after the entry signal.

==== Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file ====

Like for standard interlocking tower, any scenery asset can be transformed in an enhanced interlocking tower asset by making a few modifications to the config file.

You will find below as an example, taken from the config.txt file for the enhanced trc3 invisible interlocking tower, all the lines you need to have in your own asset config.txt so that your asset becomes an enhanced interlocking tower. Other lines like your asset kuid number, description, username, ... should remain unchanged.

'''List of lines needing to be present for a scenery asset to become an enhanced interlocking tower asset (in SP2 or later) :'''

<nowiki>
trainz-build 4.5
kind "interlocking-tower"
script "dummyinterlockingtower.gs"
class "DummyInterlockingTower"
category-class "IT"

extensions
{
generic-61392
{
assetid "enhancedinterlockingtower"

eitoptions
{
displayyellowdisc 0
pathrequeryonscheduledblocked 1
trcsupport 1
debuglevel 0
clearmethod 1
checktcb 1
resetjunctions 1
edityellowdisc 2
editpathrequery 2
edittrcsupport 2
editdebuglevel 2
editclearmethod 2
editchecktcb 2
editresetjunctions 2
editexclusivesets 2
}

colors-61392
{
cunselect "bbf5bb"
cselect "f5bbbb"
clink "ffffff"
cnrm "c0c0c0"
cwhite "ffffff"
calert "ff0000"
}
}
}

script-include-table
{
commondata <kuid:61392:4050>
esvlib <kuid:61392:4052>
eitlib <kuid:61392:8190>
trcitlib <kuid:61392:8191>
}

kuid-table
{
sessvar <kuid:-3:10197>
sessvars <kuid:-3:10197>
commondata <kuid2:61392:4050:51>
esvlib <kuid2:61392:4052:4>
eitlib <kuid2:61392:8190:47>
trcitlib <kuid:61392:8191>
0 <kuid:61392:4050>
1 <kuid:61392:8190>
2 <kuid:61392:4052>
}
</nowiki>

Just only a few comments on some of these mandatory lines in config.txt file :

The trainz-build tag needs to be at least 4.5 for any interlocking tower in SP2 or later. The kind tag should always be "interlocking-tower". The script and class should be "dummyinterlockingtower.gs" and "DummyinterlockingTower" and should respect the case for the class tag. And the category-class tag should be "IT". These tags are mandatory and should not be changed.

In the extensions part, default values for enhanced options are defined and may be changed if you wish to change the default values in your enhanced interlocking tower asset.

displayyellowdisctag is 0 for yellow disc disabled or 1 for yellow disc enabled.

pathrequeryonscheduleblocked should be 0 to disable requery and 1 to enable requery when an ai train has its schedule blocked.

trcsupport should be 1 to support trc system and 0 if not.

debug level should be 0 for no debugging, 1 for log only debugging message and 2 for log and print debugging messages

clear method should be 1 to clear on cancel, 2 for clear on drive, and 101 for clear after last junction. Other values may lead to unexpected results.

checktcb should be 0 for no tcb processing, 1 for process only exit tcb, 2 for process all tcbs along path.

reset junctions should be 0 to avoid reseting junctions direction when a path is cleared and 1 to reset junctions when a path is cleared.

and that's all for default values settings. The following tags will define if an enhanced option is not visible (0), displayed only (1), or displayed and editable (2).
the tags edityellowdisc, editpathrequery, edittrcsupport, editdebuglevel, editclearmethod, editchecktcb, editresetjunctions, editexclusivesets can be set to one of these values (0, 1, 2) to make the enhanced option not visible, displayed in read-only mode, or displayed and editable.
By configuring these extensions tags, an enhanced interlocking tower content creator can choose the default values for an option, and decide if it can be viewed or not, and if the end user can change the default values. For example, if trcsupport is set to 1 and edittrcsupport is set to 0, the tower will have the trc support option enabled, but not displayed and so not updatable by the end user. Using these tags the asset content creator can enforce any of the enhanced options value.

the other tags cunselect, cselect, clink, cnrm, cwhite, calert defines the colors to be used in the interface. You should not normally alter these values, but if you don't like the colors scheme used, you may alter these values to change the colors used in the interface. The string values defined for each tag are only the RGB hexadecimal values for the color to be used for this category of information.

and the last containers script-include-table and kuid-table should be left unchanged for the enhanced interlocking tower to work correctly.

=== Enhanced Interlocking Tower Manager Rule : How to monitor at run time your towers, paths and trains ===

Enhanced Interlocking Tower Manager Rule is a session rule that is released with the Enhanced Interlocking Tower package. Under Surveyor it enables editing of your towers and paths from a centralized interface, and under Driver it provides a run time monitor to display current available information on your towers, paths and trains using or waiting for any path.

The rule is available on DLS under the KUID <kuid2:61392:8130:47>. The rule works with both standard interlocking towers and enhanced interlocking towers.

To get more details on what this rule can display, just click on the following link to the [[Enhanced Interlocking Tower Manager Rule]] dedicated page.:

That is currently all for Enhanced Interlocking Tower assets wiki documentation.
I hope you will enjoy these new assets to help you using more versatile and powerfull interlocking tower.
And if you need more details or have unanswered questions, do not hesitate to post in the forums or to send me a private message.
Regards. Pierre GUY (61392)

==See Also==
*[[DLC_Routes_compatibility_with_Enhanced_Interlocking_Tower|DLC Routes compatibility with Enhanced Interlocking Towers]]
*[[HowTo/Configure_An_Interlocking_Tower]]
*[[Enhanced_Interlocking_Tower_Manager_Rule]]
*[[Enhanced_Interlocking_Tower_Tip_001]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with Enhanced Interlocking Tower

2023-12-08T03:58:58Z

Pguy:

{{FUN-top}}

===DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====

:Chesapeake & Ohio RR, Hinton Division
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:ECML Kings Cross
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility : <span style="color: green;">YES</span>

:Healesville
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Kickstarter County
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Avery - Drexel
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Warwick to Wallangarra
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:The BiDye Traction Railroad
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Season Town Northern Rail Road
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

... to be completed ...

====TRS19 dlc routes====

:Niddertalbahn - TRS19
::signals used on route : Hl H, Hl H +Ra12, Hl H-60 + Zs7 +Zs8 +Ra12, ... by scara
::ITs/EITs compatibility : <span style="color: red;">NO - signals scripts are not compliant to Trainz signals scripts standard</span>

... to be completed ...

====TRS22 dlc routes====

... to be completed ...

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Routes compatibility with Enhanced Interlocking Tower

2023-12-08T03:49:59Z

Pguy: Created page with "{{FUN-top}} ===DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers=== '''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets t..."

{{FUN-top}}

===DLC Routes compatibility with Interlocking Towers/Enhanced Interlocking Towers===

'''Interlocking Towers''' and '''Enhanced Interlocking Tower''' are assets that enables to add some efficient protection between conflicting traffic operations inside a route/session. Many Trainz users who are creating sessions for DLC routes often ask if they can use ITs or EITs for a specific DLC route. The answer mainly depends on which signalling system is installed on the DLC route and if it is fully compliant for all scripted signals used to the Trainz script signal standard rules.

This page tries to give information for each DLC route available for Tane, TRS19 and TRS22 on which underlying signalling system is used and if these signals are compatible or not with Interlockig Towers or Enhanced Interlocking Towers usage.

====TANE Routes====

:Chesapeake & Ohio RR, Hinton Division
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:ECML Kings Cross
::signals used on route : Sig2A, Sig3A, Sig4A, ... by Bloodnok
::ITs/EITs compatibility :<span style="color: green;">YES</span>

:Healesville
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Kickstarter County
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Avery - Drexel
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Warwick to Wallangarra
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:The BiDye Traction Railroad
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

:Season Town Northern Rail Road
::signals used on route : ... to be checked ...
::ITs/EITs compatibility : ... to be verified ...

... to be completed ...

====TRS19 dlc routes====

... to be completed ...

====TRS22 dlc routes====

... to be completed ...

==See Also==
*[[Enhanced_Interlocking_Tower|Enhanced Interlocking Towers]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Poste de Contrôle et de Régulation

2021-02-18T16:30:47Z

Pguy: /* utilisation de la famille de commandes conducteur de type PCR - enclencher itinéraire (et attendre actif ou attendre voie libre */

===Postes de Contrôle et Régulation===
[[Enhanced Interlocking Tower|Version anglaise : Enhanced Interlocking Tower]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

Les '''Postes de Contrôle et Régulation''' sont des composants tiers scriptés, qui étendent la notion d'Interlocking Tower au standard N3V avec des fonctionnalités supplémentaires intéressantes. Ceci se fait en rajoutant des pré traitements avant d'appeler les scripts standards N3V et aussi des post traitements. Cette méthode permet de vous proposer des composants compatibles avec les "Interlocking Towers" et supportant des fonctionnalités supplémentaires avancées.

Parmi ces fonctionnalités ajoutées, on trouvera entre autres :

: '''au niveau itinéraire :'''

::* un itinéraire accepte que son signal de sortie soit aussi un signal d'entrée au sein d'un autre poste de contrôle régulation<br>
::* un itinéraire ne sera enclenché que si il n'y a aucun convoi actuellement présent sur le parcours de l'itinéraire. Si ce n'est pas cas, l'enclenchement sera différé tant qu'il restera un convoi sur le parcours de l'itinéraire.<br>
::* un itinéraire peut être annulé en utilisant une commande conducteur adéquate ou en utilisant la règle de gestion des Postes de Contrôle et Régulation. Pour éviter tout risque de déraillements en cas d'annulation les aiguilles en recouvrement sous un convoi ne seront pas restaurées dans leur direction originelle.<br>
::* un itinéraire peut utiliser différentes méthodes de libération d'un itinéraire. La libération sur fin d'itinéraire ou annulation est la méthode traditionelle utilisée avec les interlocking towers. La libération progressive au fur et à mesure de l'avancement du train permet de libérer les objets pour une autre utilisation avant la libération finale de l'itinéraire. La libération après la dernière aiguille permet de libérer l'itinéraire dés que le train a quité la dernière aiguille.<br>
::* un itinéraire peut optionnellement vérifier la présente d'un TCB (track circuit block) autour du signal de sortie et vérifier si le TCB est occupé ou non. Les TCB sont utiles pour protéger une voie unique ou les voies le long des quais d'une gare voyageur.<br>
::* un itinéraire peut choisir de restaurer ou non ses aiguilles dans leur direction initiale après passage du train.<br>
::* un itinéraire peut optionnellement être membre d'un ensemble exclusif. Dans ce cas, l'enclenchement de l'itinéraire sera différé tant un autre itinéraire fera réfèrence au même ensemble exxclusif.<br>

: '''au niveau du poste de contrôle et régulation :'''

::* Il est possible d'afficher ou non le symbole disque jaune utilisé par N3V.
::* Il est possible de choisir un mode de possession staatique ou dynamique. Avec le mode statique tous les objets de l'itinéraire sont possédés par le poste de contrôle commande pour toute la session. En mode dynamique, seul le signal d'entrée est possédé pour toute la durée de la session ; les autres signaux et objets le long de l'itinéraire seront pris en possession uniquement pendant la durée où l'itinéraire est enclenché.<br>
::* compatibilité trc : il est possible de choisir au niveau du poste de contrôle régulation si l'on gère les passages à nuveau TRC au niveau de la règle TRC ou au niveau du poste.<br>
::* niveau de deboggage : Cette option à destination des développeurs permet de choisir entre l'absence de toute log et un logging plus complet.<br>
::* Les Postes de Contrôle Régulation permette via l'utilisation d'un composant additionnel adéquat eit pathtrigger d'ajuster à la baisse ou à la hausse la distance avant déclenchement d'un nouvel itinéraire.

=== Poste de Contrôle et de Régulation : Comment les utiliser ? ===

Pour utiliser un Poste de Contrôle et de Régulation, vous devez placer sur votre carte un objet Poste de Contrôle et Régulation comme le PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:76>. D'autres créateurs ont mise à disposition sur la DLS d'autres objets de type Poste de Contrôle Régulation ou Interlocking Tower. En fait tout objet de type "scenery" peut être transformé en un objet Poste de Contrôle Régulation par ajout de la configuation adéquate dans son fichier de configuration.

'''Liste au 18/02/2021 de tous les Postes de Contrôle Régulation disponible sur la DLS :'''

PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

Après avoir placé sur votre carte le poste de contrôle régulation que vous voulez utiliser, vous n'avez plus qu'à éditer les propriétés de l'objet en cliquant dessus pour ouvrir la fenêtre standard d'édition des propriétés du Poste de Contrôle Régulation. Pour cet objet, l'ensemble des options à configurer sera dans le paneau supérieur de la fenêtre des propriétés.

==== Edition d'un Poste de Contrôle Régulation : les options disponibles dans la fenêtre d'édition ====

[[File:Edit-pcr-img01.png | 768px | none ]]

Les options disponibles dans le paneau supérieur sont :

:* '''option affichage disque jaune :'''
::en cliquant sur le lien sur la partie droite, vous pouvez choisir d'afficher ou non les disques jaunes en mode conducteur

:* '''option de ré enclencheent des itinéraires :'''
::Cette option permet de préciser le comportement des trains AI quand ils sont bloqués. On peut au choix autoriser ou non une tentative de ré enclenchement des itinéraires sur situation de blocage. Si le ré enclenchement est autorisé, en cas de blocage, le poste de contrôle régulation va libérer tous les itinéraires actifs mais non encore utilisés (pas de train sur l'itinéraire) pour essayer de débloquer d'autres itinéraires en attente. Les itinéraires libérés sont remis dans la file d'attente des itinéraires à activer. Cette option peut parfois permettre de débloquer une situation de blocage, mais est sans garantie de résultat et ne correspond pas à la réalité des opérations ferroviaires. La valeur recommandée pour cette option est de ne pas autoriser ces ré enclenchements.

:* '''mode de détention des objets :'''
::Cette option préciser si le mode de détention des objets est de type statique ou dynamique. En mode statique le Poste de Contrôle Régulation prend le contrôle de tous les objets (signal d'entrée, signal de sortie, aitres signaux, aiguilles, passage à niveau) dés le début de la session conducteur et ne libère jamais ces objets qui restent sous son contrôle pendant toute la session. En mode dynamique, seul le signal d'entrée est placé sous contrôle du Poste de Contrôle Régulation en début de session et les autres objets sont placés sous le contrôle du poste uniquement tant que l'itinéraire enclenché reste actif. L'option dynamique permet donc à l'utilisateur d'intervenir sur les aiguilles quand aucun itinéraire comprenant cette aiguille n'est actif et permet aussi de partager les objets autres que les signaux d'entrée entre plusieurs postes de contrôle distincts.

:* '''mode de compatibilité trc :'''
::quand cette option est active, le poste de contrôle régulation ne gère pas les passages à niveau de type TRC mais laisse le système TRC gérer lui même ses passages à niveaux. Cette option doit être mis sur actif si vous utiliser des passages à niveau TRC sur votre carte. Elle doit être mis sur inactif si vous n'utiliser pas de passage à niveau TRC.

:* '''niveau de deboggage :'''
::Cette option est disponible pour aider les développeurs des scripts du Poste de Contrôle Régulation, en leur offrant différentes modalités d'entregistrement des informations utiles pour le deboggage dans le journal Trainz. L'utilisateur standard n'a pas besoin d'activer ces modalités (option pas de deboggage) sauf si le développeur le demande.

Vous trouverez en dessous des options un lien Restaurer les options par défaut pour rétablir si besoin l'ensemble des valeurs initiales des options du Poste de Contrôle Régulation.

==== Edition d'un itinéraire : les options disponibles dans la fenêtre de l'éditeur ====

[[File:Edit-pcr-img02.png | 768px | none ]]

Les options disponibles au niveau de l'itinéraire sont :

:* '''Méthode de libération :'''
::Cette option permet de choisir la méthode de libération de l'itinéraire : '''Libération en fin d'itinéraire (itinéraire terminé ou annulé)''' , '''Libération progressive de l'itinéraire (au fur et à mesure de l'avancement du train)''' et '''Libération après la dernière aiguille (quand le train quitte la dernière aiguille)'''. La libération en fin d'itinéraire est la méthode standard utilisé pour les ITs standard de N3V. Cette méthode libère l'ensemble des objets de l'itinéraire quand le train quitte le signal de sortie. Avec la libération progressive, les objets sont libérés au fur et à mesure de l'avancement du train quand le train quitte l'objet concerné. Celà permet de remettre à disposition plus tôt des objets attendues par d'autres itinéraires. Attention celà ne permet pas à un autre train de rentrer sur le même itinéraire. Un autre train ne pourra rentrer sur le même itinéraire que lordque le train précèdent aura quitté l'itinéraire. Libérer après la dernière aiguille permet de libérer totalement l'itinéraire une fois que le train a quitté la dernière aiguille sans attendre que le train quitte le signal de sortie. Celà est nottament utile quand un itinéraire se termine avec comme signal de sortie un buttoir. Dans ce cas il est impératif pour libérer l'itinéraire d'utiliser l'option de libération après la dernière aiguille.

:* '''mode de traitement des blocs de circuits de voie (TCB) :'''
::Cette option permet de choisir entre '''pas de traitement des TCB''' , '''Traiter uniquement les TCB des signaux de sortie''' et '''traiter tous les TCB'''. Un TCB permet de savoir si une portion de voie sur un parcours est occupé par un train ou non. Si on demande le traitement des TCB du signal de sortie, le Poste de Contrôle Régulation vérifiera avant d'enclencher un itinéraire si le ou les TCB englobant le signal de sortie sont occupés ou réservés par un train. si c'est le cas, l'itinéraire ne sera pas enclenché mais différé. Si l'ensemble des TCB sont non occupés, alors le PCR va réserver lesdits TCB et va enclencher l'itinéraire. L'usage de TCB avec cette option est pratique pour vérifier en particulier la disponibilité des voies dans les gares, sous réserve de placer les TCB adéquats.

:* '''option de réinitialisation des aiguilles :'''
::Cette option permet de choisir entre restaurer et ne pas restaurer l'état initial des aiguilles lors de la libération de l'itinéraire. A utiliser de la manière qui vous cobviendra le mieux sur votre carte.

:* '''Ensemble exclusifs à utiliser :'''
::les ensembles exclusifs à utiliser permettent de rendre facilement un ou plusieurs itinéraires exclusifs, empêchant l'enclenchement d'un autre itinéraire utilisant le même ensemble exclusif. Les ensembles exclusifs sont de simples chaines de carzactères arbitraires (il est conseillé de les garder de longueur courte raisonable) et l'on peut rentrer pour un itinéraire un ou plusieurs noms d'ensemble exclusif séparés par des virgules. Quand une liste d'ensemble exclusif est associé à un itinéraire, l'itinéraire ne pourra être enclenché qu'après vérification que tous les ensembles exclusifs sont libres et n'ont pas été reservés par d'autres itinéraires. L'neclenchement d'un itinéraire entraine la réservation de tous les ensembles exclusifs associés à l'itinéraire et ce jusqu'à la libération de l'itinéraire. Les ensemble exclusif sont en particulier la méthode recommandés pour rendre 2 itinéraires exclusifs pour un croisement de voie par exemple.

En bas de la boîte de dialogue, vous disposez aussi d'un lien '''restaurer les options par défaut''' permettant de revenir aux options initiales pour l'itinéraire.

===== et maintenant quelques conseils sur comment bien utiliser les Postes de Contrôle Régulation et les Itinéraires =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]] (Désolé cette page a été rédigé par un utilisateur anglophone pour expliquer comment protéger les croisements de voie.

===== Comment ajuster la distance par défaut d'enclenchement automatique d'un itinéraire =====

Par défaut le système détecte qu'un train est en approche d'un signal d'entrée à une distance d'environ 0.5 mile = 800 m de ce signal et recherche alors un itinéraire à enclencher pour le train en approche. Il est possible d'ajuster à la hausse ou à la baisse cette distance en utilisant un objet spécial de type path trigger ( <kuid2:61392:8121:1> ). Quand vous placer sur une voie un objet de type pathtrigger, quand un train passe sur le pathtrigger il y aura une recherche automatique vers l'avant du prochain signal d'entrée avec enclenchement automatique éventuel d'un itinéraire. Si vous placer avant la limite des 800 m un pathtrigger la recherche de l'itinéraire à enclencher sera dera donc plus tôt. si vous placer la pathtrigger à moins de 800 m, le sytème détectera lors du frnachissement des 800 m la présence du pathtrigger et retardera l'enclenchement de l'itinéraire juqu'au moment omù le train atteindra le pathtrigger à moins de 800 m du signal d'entrée. On aura donc retardé l'enclenchement de l'itinéraire. Les pathtrigger sont spécifique aux Poste de Contrôle Régulation et ne fonctionne pas avec les ITs standards.

===== utilisation de la famille de commandes conducteur de type PCR - enclencher itinéraire (et attendre actif ou attendre voie libre =====

Ces trois commandes conducteur PCR - enclencher itinéraire (<kuid:61392:8111>) , PCR - enclencher itinéraire et attendre voie libre (<kuid:61392:8112>) ou PCR - enclencher itinéraire et attendre actif ( <kuid:61392:8113>) permettent d'inclure dans la liste des ordres conducteurs une demande explicite d'enclenchement d'un itinéraire (en précisant le nom du PCR et le nom de l'itinéraire) et optionnellement d'attendre soit que le signal d'entrée ne soit plus au rouge soit que l'itinéraire soit bien actif.

=== Règle de Gestion des Postes de Contrôle Régulation : comment suivre en mode conducteur vos Postes de Contrôle Régulation ===

La Règle de Gestion des Postes de Contrôle Régulation est une règle que l'on peut ajouter aux règles de la session. sous Créateur la règle permet d'éditer les Postes de Contrôle Régulation et les Itinéraires depuis un point central. En mode conducteur, elle permet de lancer un moniteur temps réel pour afficher les informations disponibles sur l'état de vos postes de contrôle régulation et de leurs itinéraires. La règle fonctionne à la fois pour les Postes deContrôle Régulation et pour les ITs standards de N3V.

La règle est disponible sur la DLS en tant que Règle de Gestion des Postes de Contrôle Régulation KUID <kuid2:61392:8130:47>.

Pour avoir plus de détails sur comment utiliser cette règle, veuiller juste cliquer sur le le lien suivant [[Enhanced Interlocking Tower Manager Rule]]. La page est actuellement encore en anglais mais devrait être traduite d'ici quelques jours.

Ce sera tout pour ces pages d'information sur les Postes de Contrôle Régulation.
Je vous souhaite de prendre du plaisir à utiliser ces nouveaux outils qui sont très versatiles et relativement puissants.
Et n'hésitez pas à me contacter sur les forums ou par message privé si vous avous avez des questions à poser.

Cordialement.
Pierre GUY (61392)

Poste de Contrôle et de Régulation

2021-02-18T15:57:43Z

Pguy:

Poste de Contrôle et de Régulation

2021-02-18T15:56:17Z

Pguy: /* Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file */

Poste de Contrôle et de Régulation

2021-02-18T15:54:54Z

Pguy: /* Edition d'un itinéraire : les options disponibles dans la fenêtre de l'éditeur */

===Postes de Contrôle et Régulation===
[[Enhanced Interlocking Tower|Version anglaise : Enhanced Interlocking Tower]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

Les '''Postes de Contrôle et Régulation''' sont des composants tiers scriptés, qui étendent la notion d'Interlocking Tower au standard N3V avec des fonctionnalités supplémentaires intéressantes. Ceci se fait en rajoutant des pré traitements avant d'appeler les scripts standards N3V et aussi des post traitements. Cette méthode permet de vous proposer des composants compatibles avec les "Interlocking Towers" et supportant des fonctionnalités supplémentaires avancées.

Parmi ces fonctionnalités ajoutées, on trouvera entre autres :

: '''au niveau itinéraire :'''

::* un itinéraire accepte que son signal de sortie soit aussi un signal d'entrée au sein d'un autre poste de contrôle régulation<br>
::* un itinéraire ne sera enclenché que si il n'y a aucun convoi actuellement présent sur le parcours de l'itinéraire. Si ce n'est pas cas, l'enclenchement sera différé tant qu'il restera un convoi sur le parcours de l'itinéraire.<br>
::* un itinéraire peut être annulé en utilisant une commande conducteur adéquate ou en utilisant la règle de gestion des Postes de Contrôle et Régulation. Pour éviter tout risque de déraillements en cas d'annulation les aiguilles en recouvrement sous un convoi ne seront pas restaurées dans leur direction originelle.<br>
::* un itinéraire peut utiliser différentes méthodes de libération d'un itinéraire. La libération sur fin d'itinéraire ou annulation est la méthode traditionelle utilisée avec les interlocking towers. La libération progressive au fur et à mesure de l'avancement du train permet de libérer les objets pour une autre utilisation avant la libération finale de l'itinéraire. La libération après la dernière aiguille permet de libérer l'itinéraire dés que le train a quité la dernière aiguille.<br>
::* un itinéraire peut optionnellement vérifier la présente d'un TCB (track circuit block) autour du signal de sortie et vérifier si le TCB est occupé ou non. Les TCB sont utiles pour protéger une voie unique ou les voies le long des quais d'une gare voyageur.<br>
::* un itinéraire peut choisir de restaurer ou non ses aiguilles dans leur direction initiale après passage du train.<br>
::* un itinéraire peut optionnellement être membre d'un ensemble exclusif. Dans ce cas, l'enclenchement de l'itinéraire sera différé tant un autre itinéraire fera réfèrence au même ensemble exxclusif.<br>

: '''au niveau du poste de contrôle et régulation :'''

::* Il est possible d'afficher ou non le symbole disque jaune utilisé par N3V.
::* Il est possible de choisir un mode de possession staatique ou dynamique. Avec le mode statique tous les objets de l'itinéraire sont possédés par le poste de contrôle commande pour toute la session. En mode dynamique, seul le signal d'entrée est possédé pour toute la durée de la session ; les autres signaux et objets le long de l'itinéraire seront pris en possession uniquement pendant la durée où l'itinéraire est enclenché.<br>
::* compatibilité trc : il est possible de choisir au niveau du poste de contrôle régulation si l'on gère les passages à nuveau TRC au niveau de la règle TRC ou au niveau du poste.<br>
::* niveau de deboggage : Cette option à destination des développeurs permet de choisir entre l'absence de toute log et un logging plus complet.<br>
::* Les Postes de Contrôle Régulation permette via l'utilisation d'un composant additionnel adéquat eit pathtrigger d'ajuster à la baisse ou à la hausse la distance avant déclenchement d'un nouvel itinéraire.

=== Poste de Contrôle et de Régulation : Comment les utiliser ? ===

Pour utiliser un Poste de Contrôle et de Régulation, vous devez placer sur votre carte un objet Poste de Contrôle et Régulation comme le PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:76>. D'autres créateurs ont mise à disposition sur la DLS d'autres objets de type Poste de Contrôle Régulation ou Interlocking Tower. En fait tout objet de type "scenery" peut être transformé en un objet Poste de Contrôle Régulation par ajout de la configuation adéquate dans son fichier de configuration.

'''Liste au 18/02/2021 de tous les Postes de Contrôle Régulation disponible sur la DLS :'''

PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

Après avoir placé sur votre carte le poste de contrôle régulation que vous voulez utiliser, vous n'avez plus qu'à éditer les propriétés de l'objet en cliquant dessus pour ouvrir la fenêtre standard d'édition des propriétés du Poste de Contrôle Régulation. Pour cet objet, l'ensemble des options à configurer sera dans le paneau supérieur de la fenêtre des propriétés.

==== Edition d'un Poste de Contrôle Régulation : les options disponibles dans la fenêtre d'édition ====

[[File:Edit-pcr-img01.png | 768px | none ]]

Les options disponibles dans le paneau supérieur sont :

:* '''option affichage disque jaune :'''
::en cliquant sur le lien sur la partie droite, vous pouvez choisir d'afficher ou non les disques jaunes en mode conducteur

:* '''option de ré enclencheent des itinéraires :'''
::Cette option permet de préciser le comportement des trains AI quand ils sont bloqués. On peut au choix autoriser ou non une tentative de ré enclenchement des itinéraires sur situation de blocage. Si le ré enclenchement est autorisé, en cas de blocage, le poste de contrôle régulation va libérer tous les itinéraires actifs mais non encore utilisés (pas de train sur l'itinéraire) pour essayer de débloquer d'autres itinéraires en attente. Les itinéraires libérés sont remis dans la file d'attente des itinéraires à activer. Cette option peut parfois permettre de débloquer une situation de blocage, mais est sans garantie de résultat et ne correspond pas à la réalité des opérations ferroviaires. La valeur recommandée pour cette option est de ne pas autoriser ces ré enclenchements.

:* '''mode de détention des objets :'''
::Cette option préciser si le mode de détention des objets est de type statique ou dynamique. En mode statique le Poste de Contrôle Régulation prend le contrôle de tous les objets (signal d'entrée, signal de sortie, aitres signaux, aiguilles, passage à niveau) dés le début de la session conducteur et ne libère jamais ces objets qui restent sous son contrôle pendant toute la session. En mode dynamique, seul le signal d'entrée est placé sous contrôle du Poste de Contrôle Régulation en début de session et les autres objets sont placés sous le contrôle du poste uniquement tant que l'itinéraire enclenché reste actif. L'option dynamique permet donc à l'utilisateur d'intervenir sur les aiguilles quand aucun itinéraire comprenant cette aiguille n'est actif et permet aussi de partager les objets autres que les signaux d'entrée entre plusieurs postes de contrôle distincts.

:* '''mode de compatibilité trc :'''
::quand cette option est active, le poste de contrôle régulation ne gère pas les passages à niveau de type TRC mais laisse le système TRC gérer lui même ses passages à niveaux. Cette option doit être mis sur actif si vous utiliser des passages à niveau TRC sur votre carte. Elle doit être mis sur inactif si vous n'utiliser pas de passage à niveau TRC.

:* '''niveau de deboggage :'''
::Cette option est disponible pour aider les développeurs des scripts du Poste de Contrôle Régulation, en leur offrant différentes modalités d'entregistrement des informations utiles pour le deboggage dans le journal Trainz. L'utilisateur standard n'a pas besoin d'activer ces modalités (option pas de deboggage) sauf si le développeur le demande.

Vous trouverez en dessous des options un lien Restaurer les options par défaut pour rétablir si besoin l'ensemble des valeurs initiales des options du Poste de Contrôle Régulation.

==== Edition d'un itinéraire : les options disponibles dans la fenêtre de l'éditeur ====

[[File:Edit-pcr-img02.png | 768px | none ]]

Les options disponibles au niveau de l'itinéraire sont :

:* '''Méthode de libération :'''
::Cette option permet de choisir la méthode de libération de l'itinéraire : '''Libération en fin d'itinéraire (itinéraire terminé ou annulé)''' , '''Libération progressive de l'itinéraire (au fur et à mesure de l'avancement du train)''' et '''Libération après la dernière aiguille (quand le train quitte la dernière aiguille)'''. La libération en fin d'itinéraire est la méthode standard utilisé pour les ITs standard de N3V. Cette méthode libère l'ensemble des objets de l'itinéraire quand le train quitte le signal de sortie. Avec la libération progressive, les objets sont libérés au fur et à mesure de l'avancement du train quand le train quitte l'objet concerné. Celà permet de remettre à disposition plus tôt des objets attendues par d'autres itinéraires. Attention celà ne permet pas à un autre train de rentrer sur le même itinéraire. Un autre train ne pourra rentrer sur le même itinéraire que lordque le train précèdent aura quitté l'itinéraire. Libérer après la dernière aiguille permet de libérer totalement l'itinéraire une fois que le train a quitté la dernière aiguille sans attendre que le train quitte le signal de sortie. Celà est nottament utile quand un itinéraire se termine avec comme signal de sortie un buttoir. Dans ce cas il est impératif pour libérer l'itinéraire d'utiliser l'option de libération après la dernière aiguille.

:* '''mode de traitement des blocs de circuits de voie (TCB) :'''
::Cette option permet de choisir entre '''pas de traitement des TCB''' , '''Traiter uniquement les TCB des signaux de sortie''' et '''traiter tous les TCB'''. Un TCB permet de savoir si une portion de voie sur un parcours est occupé par un train ou non. Si on demande le traitement des TCB du signal de sortie, le Poste de Contrôle Régulation vérifiera avant d'enclencher un itinéraire si le ou les TCB englobant le signal de sortie sont occupés ou réservés par un train. si c'est le cas, l'itinéraire ne sera pas enclenché mais différé. Si l'ensemble des TCB sont non occupés, alors le PCR va réserver lesdits TCB et va enclencher l'itinéraire. L'usage de TCB avec cette option est pratique pour vérifier en particulier la disponibilité des voies dans les gares, sous réserve de placer les TCB adéquats.

:* '''option de réinitialisation des aiguilles :'''
::Cette option permet de choisir entre restaurer et ne pas restaurer l'état initial des aiguilles lors de la libération de l'itinéraire. A utiliser de la manière qui vous cobviendra le mieux sur votre carte.

:* '''Ensemble exclusifs à utiliser :'''
::les ensembles exclusifs à utiliser permettent de rendre facilement un ou plusieurs itinéraires exclusifs, empêchant l'enclenchement d'un autre itinéraire utilisant le même ensemble exclusif. Les ensembles exclusifs sont de simples chaines de carzactères arbitraires (il est conseillé de les garder de longueur courte raisonable) et l'on peut rentrer pour un itinéraire un ou plusieurs noms d'ensemble exclusif séparés par des virgules. Quand une liste d'ensemble exclusif est associé à un itinéraire, l'itinéraire ne pourra être enclenché qu'après vérification que tous les ensembles exclusifs sont libres et n'ont pas été reservés par d'autres itinéraires. L'neclenchement d'un itinéraire entraine la réservation de tous les ensembles exclusifs associés à l'itinéraire et ce jusqu'à la libération de l'itinéraire. Les ensemble exclusif sont en particulier la méthode recommandés pour rendre 2 itinéraires exclusifs pour un croisement de voie par exemple.

En bas de la boîte de dialogue, vous disposez aussi d'un lien '''restaurer les options par défaut''' permettant de revenir aux options initiales pour l'itinéraire.

===== et maintenant quelques conseils sur comment bien utiliser les Postes de Contrôle Régulation et les Itinéraires =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]] (Désolé cette page a été rédigé par un utilisateur anglophone pour expliquer comment protéger les croisements de voie.

===== Comment ajuster la distance par défaut d'enclenchement automatique d'un itinéraire =====

Par défaut le système détecte qu'un train est en approche d'un signal d'entrée à une distance d'environ 0.5 mile = 800 m de ce signal et recherche alors un itinéraire à enclencher pour le train en approche. Il est possible d'ajuster à la hausse ou à la baisse cette distance en utilisant un objet spécial de type path trigger ( <kuid2:61392:8121:1> ). Quand vous placer sur une voie un objet de type pathtrigger, quand un train passe sur le pathtrigger il y aura une recherche automatique vers l'avant du prochain signal d'entrée avec enclenchement automatique éventuel d'un itinéraire. Si vous placer avant la limite des 800 m un pathtrigger la recherche de l'itinéraire à enclencher sera dera donc plus tôt. si vous placer la pathtrigger à moins de 800 m, le sytème détectera lors du frnachissement des 800 m la présence du pathtrigger et retardera l'enclenchement de l'itinéraire juqu'au moment omù le train atteindra le pathtrigger à moins de 800 m du signal d'entrée. On aura donc retardé l'enclenchement de l'itinéraire. Les pathtrigger sont spécifique aux Poste de Contrôle Régulation et ne fonctionne pas avec les ITs standards.

===== utilisation de la famille de commandes conducteur de type PCR - enclencher itinéraire (et attendre actif ou attendre voie libre =====

Ces trois commandes conducteur PCR - enclencher itinéraire (<kuid:61392:8111>) , PCR - enclencher itinéraire et attendre voie libre (<kuid:61392:8112>) ou PCR - enclencher itinéraire et attendre actif ( <kuid:61392:8113>) permettent d'inclure dans la liste des ordres conducteurs une demande explicite d'enclenchement d'un itinéraire (en précisant le nom du PCR et le nom de l'itinéraire) et optionnellement d'attendre soit que le signal d'entrée ne soit plus au rouge soit que l'itinéraire soit bien actif.

==== Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file ====

Like for standard interlocking tower, any scenery asset can be transformed in an enhanced interlocking tower asset by making a few modifications to the config file.

You will find below as an example, taken from the config.txt file for the enhanced trc3 invisible interlocking tower, all the lines you need to have in your own asset config.txt so that your asset becomes an enhanced interlocking tower. Other lines like your asset kuid number, description, username, ... should remain unchanged.

'''List of lines needing to be present for a scenery asset to become an enhanced interlocking tower asset (in SP2 or later) :'''

<nowiki>
trainz-build 4.5
kind "interlocking-tower"
script "dummyinterlockingtower.gs"
class "DummyInterlockingTower"
category-class "IT"

extensions
{
generic-61392
{
assetid "enhancedinterlockingtower"

eitoptions
{
displayyellowdisc 0
pathrequeryonscheduledblocked 1
trcsupport 1
debuglevel 0
clearmethod 1
checktcb 1
resetjunctions 1
edityellowdisc 2
editpathrequery 2
edittrcsupport 2
editdebuglevel 2
editclearmethod 2
editchecktcb 2
editresetjunctions 2
editexclusivesets 2
}

colors-61392
{
cunselect "bbf5bb"
cselect "f5bbbb"
clink "ffffff"
cnrm "c0c0c0"
cwhite "ffffff"
calert "ff0000"
}
}
}

script-include-table
{
commondata <kuid:61392:4050>
esvlib <kuid:61392:4052>
eitlib <kuid:61392:8190>
trcitlib <kuid:61392:8191>
}

kuid-table
{
sessvar <kuid:-3:10197>
sessvars <kuid:-3:10197>
commondata <kuid2:61392:4050:51>
esvlib <kuid2:61392:4052:4>
eitlib <kuid2:61392:8190:47>
trcitlib <kuid:61392:8191>
0 <kuid:61392:4050>
1 <kuid:61392:8190>
2 <kuid:61392:4052>
}
</nowiki>

Just only a few comments on some of these mandatory lines in config.txt file :

The trainz-build tag needs to be at least 4.5 for any interlocking tower in SP2 or later. The kind tag should always be "interlocking-tower". The script and class should be "dummyinterlockingtower.gs" and "DummyinterlockingTower" and should respect the case for the class tag. And the category-class tag should be "IT". These tags are mandatory and should not be changed.

In the extensions part, default values for enhanced options are defined and may be changed if you wish to change the default values in your enhanced interlocking tower asset.

displayyellowdisctag is 0 for yellow disc disabled or 1 for yellow disc enabled.

pathrequeryonscheduleblocked should be 0 to disable requery and 1 to enable requery when an ai train has its schedule blocked.

trcsupport should be 1 to support trc system and 0 if not.

debug level should be 0 for no debugging, 1 for log only debugging message and 2 for log and print debugging messages

clear method should be 1 to clear on cancel, 2 for clear on drive, and 101 for clear after last junction. Other values may lead to unexpected results.

checktcb should be 0 for no tcb processing, 1 for process only exit tcb, 2 for process all tcbs along path.

reset junctions should be 0 to avoid reseting junctions direction when a path is cleared and 1 to reset junctions when a path is cleared.

and that's all for default values settings. The following tags will define if an enhanced option is not visible (0), displayed only (1), or displayed and editable (2).
the tags edityellowdisc, editpathrequery, edittrcsupport, editdebuglevel, editclearmethod, editchecktcb, editresetjunctions, editexclusivesets can be set to one of these values (0, 1, 2) to make the enhanced option not visible, displayed in read-only mode, or displayed and editable.
By configuring these extensions tags, an enhanced interlocking tower content creator can choose the default values for an option, and decide if it can be viewed or not, and if the end user can change the default values. For example, if trcsupport is set to 1 and edittrcsupport is set to 0, the tower will have the trc support option enabled, but not displayed and so not updatable by the end user. Using these tags the asset content creator can enforce any of the enhanced options value.

the other tags cunselect, cselect, clink, cnrm, cwhite, calert defines the colors to be used in the interface. You should not normally alter these values, but if you don't like the colors scheme used, you may alter these values to change the colors used in the interface. The string values defined for each tag are only the RGB hexadecimal values for the color to be used for this category of information.

and the last containers script-include-table and kuid-table should be left unchanged for the enhanced interlocking tower to work correctly.

File:Edit-pcr-img02.png

2021-02-18T15:07:17Z

Pguy:

Poste de Contrôle et de Régulation

2021-02-18T15:06:45Z

Pguy: /* Editing enhanced Interlocking tower path : options available in the path editor window */

===Postes de Contrôle et Régulation===
[[Enhanced Interlocking Tower|Version anglaise : Enhanced Interlocking Tower]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

Les '''Postes de Contrôle et Régulation''' sont des composants tiers scriptés, qui étendent la notion d'Interlocking Tower au standard N3V avec des fonctionnalités supplémentaires intéressantes. Ceci se fait en rajoutant des pré traitements avant d'appeler les scripts standards N3V et aussi des post traitements. Cette méthode permet de vous proposer des composants compatibles avec les "Interlocking Towers" et supportant des fonctionnalités supplémentaires avancées.

Parmi ces fonctionnalités ajoutées, on trouvera entre autres :

: '''au niveau itinéraire :'''

::* un itinéraire accepte que son signal de sortie soit aussi un signal d'entrée au sein d'un autre poste de contrôle régulation<br>
::* un itinéraire ne sera enclenché que si il n'y a aucun convoi actuellement présent sur le parcours de l'itinéraire. Si ce n'est pas cas, l'enclenchement sera différé tant qu'il restera un convoi sur le parcours de l'itinéraire.<br>
::* un itinéraire peut être annulé en utilisant une commande conducteur adéquate ou en utilisant la règle de gestion des Postes de Contrôle et Régulation. Pour éviter tout risque de déraillements en cas d'annulation les aiguilles en recouvrement sous un convoi ne seront pas restaurées dans leur direction originelle.<br>
::* un itinéraire peut utiliser différentes méthodes de libération d'un itinéraire. La libération sur fin d'itinéraire ou annulation est la méthode traditionelle utilisée avec les interlocking towers. La libération progressive au fur et à mesure de l'avancement du train permet de libérer les objets pour une autre utilisation avant la libération finale de l'itinéraire. La libération après la dernière aiguille permet de libérer l'itinéraire dés que le train a quité la dernière aiguille.<br>
::* un itinéraire peut optionnellement vérifier la présente d'un TCB (track circuit block) autour du signal de sortie et vérifier si le TCB est occupé ou non. Les TCB sont utiles pour protéger une voie unique ou les voies le long des quais d'une gare voyageur.<br>
::* un itinéraire peut choisir de restaurer ou non ses aiguilles dans leur direction initiale après passage du train.<br>
::* un itinéraire peut optionnellement être membre d'un ensemble exclusif. Dans ce cas, l'enclenchement de l'itinéraire sera différé tant un autre itinéraire fera réfèrence au même ensemble exxclusif.<br>

: '''au niveau du poste de contrôle et régulation :'''

::* Il est possible d'afficher ou non le symbole disque jaune utilisé par N3V.
::* Il est possible de choisir un mode de possession staatique ou dynamique. Avec le mode statique tous les objets de l'itinéraire sont possédés par le poste de contrôle commande pour toute la session. En mode dynamique, seul le signal d'entrée est possédé pour toute la durée de la session ; les autres signaux et objets le long de l'itinéraire seront pris en possession uniquement pendant la durée où l'itinéraire est enclenché.<br>
::* compatibilité trc : il est possible de choisir au niveau du poste de contrôle régulation si l'on gère les passages à nuveau TRC au niveau de la règle TRC ou au niveau du poste.<br>
::* niveau de deboggage : Cette option à destination des développeurs permet de choisir entre l'absence de toute log et un logging plus complet.<br>
::* Les Postes de Contrôle Régulation permette via l'utilisation d'un composant additionnel adéquat eit pathtrigger d'ajuster à la baisse ou à la hausse la distance avant déclenchement d'un nouvel itinéraire.

=== Poste de Contrôle et de Régulation : Comment les utiliser ? ===

Pour utiliser un Poste de Contrôle et de Régulation, vous devez placer sur votre carte un objet Poste de Contrôle et Régulation comme le PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:76>. D'autres créateurs ont mise à disposition sur la DLS d'autres objets de type Poste de Contrôle Régulation ou Interlocking Tower. En fait tout objet de type "scenery" peut être transformé en un objet Poste de Contrôle Régulation par ajout de la configuation adéquate dans son fichier de configuration.

'''Liste au 18/02/2021 de tous les Postes de Contrôle Régulation disponible sur la DLS :'''

PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

Après avoir placé sur votre carte le poste de contrôle régulation que vous voulez utiliser, vous n'avez plus qu'à éditer les propriétés de l'objet en cliquant dessus pour ouvrir la fenêtre standard d'édition des propriétés du Poste de Contrôle Régulation. Pour cet objet, l'ensemble des options à configurer sera dans le paneau supérieur de la fenêtre des propriétés.

==== Edition d'un Poste de Contrôle Régulation : les options disponibles dans la fenêtre d'édition ====

[[File:Edit-pcr-img01.png | 768px | none ]]

Les options disponibles dans le paneau supérieur sont :

:* '''option affichage disque jaune :'''
::en cliquant sur le lien sur la partie droite, vous pouvez choisir d'afficher ou non les disques jaunes en mode conducteur

:* '''option de ré enclencheent des itinéraires :'''
::Cette option permet de préciser le comportement des trains AI quand ils sont bloqués. On peut au choix autoriser ou non une tentative de ré enclenchement des itinéraires sur situation de blocage. Si le ré enclenchement est autorisé, en cas de blocage, le poste de contrôle régulation va libérer tous les itinéraires actifs mais non encore utilisés (pas de train sur l'itinéraire) pour essayer de débloquer d'autres itinéraires en attente. Les itinéraires libérés sont remis dans la file d'attente des itinéraires à activer. Cette option peut parfois permettre de débloquer une situation de blocage, mais est sans garantie de résultat et ne correspond pas à la réalité des opérations ferroviaires. La valeur recommandée pour cette option est de ne pas autoriser ces ré enclenchements.

:* '''mode de détention des objets :'''
::Cette option préciser si le mode de détention des objets est de type statique ou dynamique. En mode statique le Poste de Contrôle Régulation prend le contrôle de tous les objets (signal d'entrée, signal de sortie, aitres signaux, aiguilles, passage à niveau) dés le début de la session conducteur et ne libère jamais ces objets qui restent sous son contrôle pendant toute la session. En mode dynamique, seul le signal d'entrée est placé sous contrôle du Poste de Contrôle Régulation en début de session et les autres objets sont placés sous le contrôle du poste uniquement tant que l'itinéraire enclenché reste actif. L'option dynamique permet donc à l'utilisateur d'intervenir sur les aiguilles quand aucun itinéraire comprenant cette aiguille n'est actif et permet aussi de partager les objets autres que les signaux d'entrée entre plusieurs postes de contrôle distincts.

:* '''mode de compatibilité trc :'''
::quand cette option est active, le poste de contrôle régulation ne gère pas les passages à niveau de type TRC mais laisse le système TRC gérer lui même ses passages à niveaux. Cette option doit être mis sur actif si vous utiliser des passages à niveau TRC sur votre carte. Elle doit être mis sur inactif si vous n'utiliser pas de passage à niveau TRC.

:* '''niveau de deboggage :'''
::Cette option est disponible pour aider les développeurs des scripts du Poste de Contrôle Régulation, en leur offrant différentes modalités d'entregistrement des informations utiles pour le deboggage dans le journal Trainz. L'utilisateur standard n'a pas besoin d'activer ces modalités (option pas de deboggage) sauf si le développeur le demande.

Vous trouverez en dessous des options un lien Restaurer les options par défaut pour rétablir si besoin l'ensemble des valeurs initiales des options du Poste de Contrôle Régulation.

==== Edition d'un itinéraire : les options disponibles dans la fenêtre de l'éditeur ====

[[File:Edit-pcr-img02.png | 768px | none ]]

The available options in the header at the path level are :

:* '''Path clear method to use :'''
::you can here select the path clear method to be used between '''Clear on cancel (when a path is either complete or cancelled)''' , '''Clear on drive (following train progress along the path)''' and '''Clear after last junction (when the train leaves the last junction along the path)'''. Clear on cancel is the standard IT clear method that can still be selected. Clear on cancel will release path objects locks when the owning train leaves the path object. With clear on drive, the path will still be cleared and cancelled only when the train will leaves the exit signal, but path objects are unlocked as soon as the train has left them and are made available for other conflicting paths to be activated earlier. Clear after last junction will clear and cancel the path as soon as the owning train has left the last junction along the path and will not wait for the train to reach and leave the exit signal. Clear on last junction may be an interesting option for path leading to an and of track with a buffer. You can use the buffer as the exit signal, and though the owning train will never leave the buffer exit signal, the path will be cleared as soon as the train will have left the last junction along the path.

:* '''Path track circuit blocks mode :'''
::this option can either be '''no tcb processing''' , '''process only tcb for exit signal''' or '''process all tcbs along path'''. With process only tcb for exit signal, before activation, the path will look if its exit signal is embedded in some track circuit block, and if it is the case will check that the track circuit block is not occupied and not locked. If it is not the case, path activation will be delayed until the previous conditions are met. When the exit tcb is unoccupied and unlocked, path will be activated but will also lock the tcb name while the path is active. Doing so enables to guarantee that a path is activated only when a tcb embedding the exit signal is not occupied and locking its name enables to prevent other paths to activate while the initial path is active even if there are no common paths objects between the paths. Exit signal tcb are very usefull for terminal station platforms, for through station platforms and for unique track between two several passing places. As several interlocking tower paths from distinct towers can have their exit signal embedded in the same tcb, this facility also enables to do some interlocking between paths form distinct towers. Using the process all tcbs option along path enables to do the same processing for all the tcbs embedding some path objects and not only for the exit signal tcb.

:* '''Path clear option for owned junctions :'''
::this option enable to either restore the junction initial direction (default used by standard it) or to do not restore junctions initial direction when a path is cleared. This option is available mainly for prototypical behavior as sometimes it is not very prototypical to have a junction having its initial direction restored because a path has been cleared followed by rechanging the direction due to another path being activated. With this option you avoid successive inadequate direction changes for junctions.

:* '''Exclusive sets membership :'''
::exclusive sets membership is an option that has been designed to help protect a crossing of tracks without the need to add some invisible junctions using these junctions as external object reference. When you add an exclusive set name in this field, the path will only be activated if no other paths in any tower with also the same exclusive set name is active. Paths sharing the same exclusive set name cannot be simultaneously active and this works inside the same tower as inside any tower on your route. To protect a crossing of track, you need only to give a unique name to this crossing of track and reference this name as an exclusive set name in all your paths using this crossing of tracks. It is much more easy to use than using invisible junctions with external references in paths.
::You can enter in this field either only one name or several names separated by a comma. Exclusive set name A will be displayed in the field as A. Exclusive set names A , B will be displayed as an exclusive set names list [A,B]. What is important is that you can enter either one name or several names separated by commas. When several names have been listed, the path belongs to all the exclusive set names and will check that no paths active are referencing any of these names before activating the path. This feature is very usefull to protect crossing tracks, and also slips and double-slips.

At the bottom of the header, you have also two links available : the '''restore default options''' link will restore all the default values for the enhanced options for the current path. The '''make current path options default options''' will change the default options in the current tower to be the current path options. Using these options link, it is quite easy to retrieve some path options and to propagate them to some other paths.

===== And now below a few tips on how to use some of the enhanced options =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]]

===== How to ajust the default distance for automatic path selection =====

By default, automatic path selection is called when an incoming train approaches an entry signal at about 0.5 mile. But since version 60 available from DLS in 02/2019, you can adjust (increase or decrease) this default distance by using specific path trigger object ( <kuid2:61392:8121:1> ). When you place a path trigger object, automatic path selection will be called when the incoming train reaches the last path trigger object before the entry signal (the train needs to have the track already set in the correct direction to go to the entry signal). If the path trigger is reached before the standard 0.5 mile distance, automatic path selection will be done with an increased distance from the entry signal. If when the train arrives at the standard distance, the system find there is a path trigger between the train and the entry signal, automatic path selection will be delayed until the train reaches the path trigger, and automatic path selection will be done at a reduced distance from the entry signal. Path trigger works only with EIT and not at all with standard ITs.

===== How to activate easily a path for a train using ITSetPath family driver commands =====

An easy method to activate a path for a train is to use one of the three driver commands ITSetPath (<kuid:61392:8111>) , ITSetPathAndWaitNotRed (<kuid:61392:8112>) or ITSetPathAndWaitActive ( <kuid:61392:8113>). These three driver commands enable the user to choose the interlocking tower and the path to request for the current driver when the driver command is executed. ITSetPath will only request the path activation and will immediately terminates, giving control to the next driver command in the train schedule. ITSetPathAndWaitNotRed will also request the path activation, but will wait until the path has been activated and the entry signal is not red before terminating and giving control to the next command. ITSetPathAndWaitActive will request the path activation and will wait for the path being active but will terminates giving control to the next command even if entry signal is still red. This last command may be usefull to set a path to drive and couple to another consist just after the entry signal.

==== Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file ====

Like for standard interlocking tower, any scenery asset can be transformed in an enhanced interlocking tower asset by making a few modifications to the config file.

You will find below as an example, taken from the config.txt file for the enhanced trc3 invisible interlocking tower, all the lines you need to have in your own asset config.txt so that your asset becomes an enhanced interlocking tower. Other lines like your asset kuid number, description, username, ... should remain unchanged.

'''List of lines needing to be present for a scenery asset to become an enhanced interlocking tower asset (in SP2 or later) :'''

<nowiki>
trainz-build 4.5
kind "interlocking-tower"
script "dummyinterlockingtower.gs"
class "DummyInterlockingTower"
category-class "IT"

extensions
{
generic-61392
{
assetid "enhancedinterlockingtower"

eitoptions
{
displayyellowdisc 0
pathrequeryonscheduledblocked 1
trcsupport 1
debuglevel 0
clearmethod 1
checktcb 1
resetjunctions 1
edityellowdisc 2
editpathrequery 2
edittrcsupport 2
editdebuglevel 2
editclearmethod 2
editchecktcb 2
editresetjunctions 2
editexclusivesets 2
}

colors-61392
{
cunselect "bbf5bb"
cselect "f5bbbb"
clink "ffffff"
cnrm "c0c0c0"
cwhite "ffffff"
calert "ff0000"
}
}
}

script-include-table
{
commondata <kuid:61392:4050>
esvlib <kuid:61392:4052>
eitlib <kuid:61392:8190>
trcitlib <kuid:61392:8191>
}

kuid-table
{
sessvar <kuid:-3:10197>
sessvars <kuid:-3:10197>
commondata <kuid2:61392:4050:51>
esvlib <kuid2:61392:4052:4>
eitlib <kuid2:61392:8190:47>
trcitlib <kuid:61392:8191>
0 <kuid:61392:4050>
1 <kuid:61392:8190>
2 <kuid:61392:4052>
}
</nowiki>

Just only a few comments on some of these mandatory lines in config.txt file :

The trainz-build tag needs to be at least 4.5 for any interlocking tower in SP2 or later. The kind tag should always be "interlocking-tower". The script and class should be "dummyinterlockingtower.gs" and "DummyinterlockingTower" and should respect the case for the class tag. And the category-class tag should be "IT". These tags are mandatory and should not be changed.

In the extensions part, default values for enhanced options are defined and may be changed if you wish to change the default values in your enhanced interlocking tower asset.

displayyellowdisctag is 0 for yellow disc disabled or 1 for yellow disc enabled.

pathrequeryonscheduleblocked should be 0 to disable requery and 1 to enable requery when an ai train has its schedule blocked.

trcsupport should be 1 to support trc system and 0 if not.

debug level should be 0 for no debugging, 1 for log only debugging message and 2 for log and print debugging messages

clear method should be 1 to clear on cancel, 2 for clear on drive, and 101 for clear after last junction. Other values may lead to unexpected results.

checktcb should be 0 for no tcb processing, 1 for process only exit tcb, 2 for process all tcbs along path.

reset junctions should be 0 to avoid reseting junctions direction when a path is cleared and 1 to reset junctions when a path is cleared.

and that's all for default values settings. The following tags will define if an enhanced option is not visible (0), displayed only (1), or displayed and editable (2).
the tags edityellowdisc, editpathrequery, edittrcsupport, editdebuglevel, editclearmethod, editchecktcb, editresetjunctions, editexclusivesets can be set to one of these values (0, 1, 2) to make the enhanced option not visible, displayed in read-only mode, or displayed and editable.
By configuring these extensions tags, an enhanced interlocking tower content creator can choose the default values for an option, and decide if it can be viewed or not, and if the end user can change the default values. For example, if trcsupport is set to 1 and edittrcsupport is set to 0, the tower will have the trc support option enabled, but not displayed and so not updatable by the end user. Using these tags the asset content creator can enforce any of the enhanced options value.

the other tags cunselect, cselect, clink, cnrm, cwhite, calert defines the colors to be used in the interface. You should not normally alter these values, but if you don't like the colors scheme used, you may alter these values to change the colors used in the interface. The string values defined for each tag are only the RGB hexadecimal values for the color to be used for this category of information.

and the last containers script-include-table and kuid-table should be left unchanged for the enhanced interlocking tower to work correctly.

Poste de Contrôle et de Régulation

2021-02-18T14:35:56Z

Pguy: /* Edition d'un Poste de Contrôle Régulation : les options disponibles dans la fenêtre d'édition */

===Postes de Contrôle et Régulation===
[[Enhanced Interlocking Tower|Version anglaise : Enhanced Interlocking Tower]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

Les '''Postes de Contrôle et Régulation''' sont des composants tiers scriptés, qui étendent la notion d'Interlocking Tower au standard N3V avec des fonctionnalités supplémentaires intéressantes. Ceci se fait en rajoutant des pré traitements avant d'appeler les scripts standards N3V et aussi des post traitements. Cette méthode permet de vous proposer des composants compatibles avec les "Interlocking Towers" et supportant des fonctionnalités supplémentaires avancées.

Parmi ces fonctionnalités ajoutées, on trouvera entre autres :

: '''au niveau itinéraire :'''

::* un itinéraire accepte que son signal de sortie soit aussi un signal d'entrée au sein d'un autre poste de contrôle régulation<br>
::* un itinéraire ne sera enclenché que si il n'y a aucun convoi actuellement présent sur le parcours de l'itinéraire. Si ce n'est pas cas, l'enclenchement sera différé tant qu'il restera un convoi sur le parcours de l'itinéraire.<br>
::* un itinéraire peut être annulé en utilisant une commande conducteur adéquate ou en utilisant la règle de gestion des Postes de Contrôle et Régulation. Pour éviter tout risque de déraillements en cas d'annulation les aiguilles en recouvrement sous un convoi ne seront pas restaurées dans leur direction originelle.<br>
::* un itinéraire peut utiliser différentes méthodes de libération d'un itinéraire. La libération sur fin d'itinéraire ou annulation est la méthode traditionelle utilisée avec les interlocking towers. La libération progressive au fur et à mesure de l'avancement du train permet de libérer les objets pour une autre utilisation avant la libération finale de l'itinéraire. La libération après la dernière aiguille permet de libérer l'itinéraire dés que le train a quité la dernière aiguille.<br>
::* un itinéraire peut optionnellement vérifier la présente d'un TCB (track circuit block) autour du signal de sortie et vérifier si le TCB est occupé ou non. Les TCB sont utiles pour protéger une voie unique ou les voies le long des quais d'une gare voyageur.<br>
::* un itinéraire peut choisir de restaurer ou non ses aiguilles dans leur direction initiale après passage du train.<br>
::* un itinéraire peut optionnellement être membre d'un ensemble exclusif. Dans ce cas, l'enclenchement de l'itinéraire sera différé tant un autre itinéraire fera réfèrence au même ensemble exxclusif.<br>

: '''au niveau du poste de contrôle et régulation :'''

::* Il est possible d'afficher ou non le symbole disque jaune utilisé par N3V.
::* Il est possible de choisir un mode de possession staatique ou dynamique. Avec le mode statique tous les objets de l'itinéraire sont possédés par le poste de contrôle commande pour toute la session. En mode dynamique, seul le signal d'entrée est possédé pour toute la durée de la session ; les autres signaux et objets le long de l'itinéraire seront pris en possession uniquement pendant la durée où l'itinéraire est enclenché.<br>
::* compatibilité trc : il est possible de choisir au niveau du poste de contrôle régulation si l'on gère les passages à nuveau TRC au niveau de la règle TRC ou au niveau du poste.<br>
::* niveau de deboggage : Cette option à destination des développeurs permet de choisir entre l'absence de toute log et un logging plus complet.<br>
::* Les Postes de Contrôle Régulation permette via l'utilisation d'un composant additionnel adéquat eit pathtrigger d'ajuster à la baisse ou à la hausse la distance avant déclenchement d'un nouvel itinéraire.

=== Poste de Contrôle et de Régulation : Comment les utiliser ? ===

Pour utiliser un Poste de Contrôle et de Régulation, vous devez placer sur votre carte un objet Poste de Contrôle et Régulation comme le PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:76>. D'autres créateurs ont mise à disposition sur la DLS d'autres objets de type Poste de Contrôle Régulation ou Interlocking Tower. En fait tout objet de type "scenery" peut être transformé en un objet Poste de Contrôle Régulation par ajout de la configuation adéquate dans son fichier de configuration.

'''Liste au 18/02/2021 de tous les Postes de Contrôle Régulation disponible sur la DLS :'''

PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

Après avoir placé sur votre carte le poste de contrôle régulation que vous voulez utiliser, vous n'avez plus qu'à éditer les propriétés de l'objet en cliquant dessus pour ouvrir la fenêtre standard d'édition des propriétés du Poste de Contrôle Régulation. Pour cet objet, l'ensemble des options à configurer sera dans le paneau supérieur de la fenêtre des propriétés.

==== Edition d'un Poste de Contrôle Régulation : les options disponibles dans la fenêtre d'édition ====

[[File:Edit-pcr-img01.png | 768px | none ]]

Les options disponibles dans le paneau supérieur sont :

:* '''option affichage disque jaune :'''
::en cliquant sur le lien sur la partie droite, vous pouvez choisir d'afficher ou non les disques jaunes en mode conducteur

:* '''option de ré enclencheent des itinéraires :'''
::Cette option permet de préciser le comportement des trains AI quand ils sont bloqués. On peut au choix autoriser ou non une tentative de ré enclenchement des itinéraires sur situation de blocage. Si le ré enclenchement est autorisé, en cas de blocage, le poste de contrôle régulation va libérer tous les itinéraires actifs mais non encore utilisés (pas de train sur l'itinéraire) pour essayer de débloquer d'autres itinéraires en attente. Les itinéraires libérés sont remis dans la file d'attente des itinéraires à activer. Cette option peut parfois permettre de débloquer une situation de blocage, mais est sans garantie de résultat et ne correspond pas à la réalité des opérations ferroviaires. La valeur recommandée pour cette option est de ne pas autoriser ces ré enclenchements.

:* '''mode de détention des objets :'''
::Cette option préciser si le mode de détention des objets est de type statique ou dynamique. En mode statique le Poste de Contrôle Régulation prend le contrôle de tous les objets (signal d'entrée, signal de sortie, aitres signaux, aiguilles, passage à niveau) dés le début de la session conducteur et ne libère jamais ces objets qui restent sous son contrôle pendant toute la session. En mode dynamique, seul le signal d'entrée est placé sous contrôle du Poste de Contrôle Régulation en début de session et les autres objets sont placés sous le contrôle du poste uniquement tant que l'itinéraire enclenché reste actif. L'option dynamique permet donc à l'utilisateur d'intervenir sur les aiguilles quand aucun itinéraire comprenant cette aiguille n'est actif et permet aussi de partager les objets autres que les signaux d'entrée entre plusieurs postes de contrôle distincts.

:* '''mode de compatibilité trc :'''
::quand cette option est active, le poste de contrôle régulation ne gère pas les passages à niveau de type TRC mais laisse le système TRC gérer lui même ses passages à niveaux. Cette option doit être mis sur actif si vous utiliser des passages à niveau TRC sur votre carte. Elle doit être mis sur inactif si vous n'utiliser pas de passage à niveau TRC.

:* '''niveau de deboggage :'''
::Cette option est disponible pour aider les développeurs des scripts du Poste de Contrôle Régulation, en leur offrant différentes modalités d'entregistrement des informations utiles pour le deboggage dans le journal Trainz. L'utilisateur standard n'a pas besoin d'activer ces modalités (option pas de deboggage) sauf si le développeur le demande.

Vous trouverez en dessous des options un lien Restaurer les options par défaut pour rétablir si besoin l'ensemble des valeurs initiales des options du Poste de Contrôle Régulation.

==== Editing enhanced Interlocking tower path : options available in the path editor window ====

[[File:Help-eit-assets-img03.png | 768px | none ]]

The available options in the header at the path level are :

:* '''Path clear method to use :'''
::you can here select the path clear method to be used between '''Clear on cancel (when a path is either complete or cancelled)''' , '''Clear on drive (following train progress along the path)''' and '''Clear after last junction (when the train leaves the last junction along the path)'''. Clear on cancel is the standard IT clear method that can still be selected. Clear on cancel will release path objects locks when the owning train leaves the path object. With clear on drive, the path will still be cleared and cancelled only when the train will leaves the exit signal, but path objects are unlocked as soon as the train has left them and are made available for other conflicting paths to be activated earlier. Clear after last junction will clear and cancel the path as soon as the owning train has left the last junction along the path and will not wait for the train to reach and leave the exit signal. Clear on last junction may be an interesting option for path leading to an and of track with a buffer. You can use the buffer as the exit signal, and though the owning train will never leave the buffer exit signal, the path will be cleared as soon as the train will have left the last junction along the path.

:* '''Path track circuit blocks mode :'''
::this option can either be '''no tcb processing''' , '''process only tcb for exit signal''' or '''process all tcbs along path'''. With process only tcb for exit signal, before activation, the path will look if its exit signal is embedded in some track circuit block, and if it is the case will check that the track circuit block is not occupied and not locked. If it is not the case, path activation will be delayed until the previous conditions are met. When the exit tcb is unoccupied and unlocked, path will be activated but will also lock the tcb name while the path is active. Doing so enables to guarantee that a path is activated only when a tcb embedding the exit signal is not occupied and locking its name enables to prevent other paths to activate while the initial path is active even if there are no common paths objects between the paths. Exit signal tcb are very usefull for terminal station platforms, for through station platforms and for unique track between two several passing places. As several interlocking tower paths from distinct towers can have their exit signal embedded in the same tcb, this facility also enables to do some interlocking between paths form distinct towers. Using the process all tcbs option along path enables to do the same processing for all the tcbs embedding some path objects and not only for the exit signal tcb.

:* '''Path clear option for owned junctions :'''
::this option enable to either restore the junction initial direction (default used by standard it) or to do not restore junctions initial direction when a path is cleared. This option is available mainly for prototypical behavior as sometimes it is not very prototypical to have a junction having its initial direction restored because a path has been cleared followed by rechanging the direction due to another path being activated. With this option you avoid successive inadequate direction changes for junctions.

:* '''Exclusive sets membership :'''
::exclusive sets membership is an option that has been designed to help protect a crossing of tracks without the need to add some invisible junctions using these junctions as external object reference. When you add an exclusive set name in this field, the path will only be activated if no other paths in any tower with also the same exclusive set name is active. Paths sharing the same exclusive set name cannot be simultaneously active and this works inside the same tower as inside any tower on your route. To protect a crossing of track, you need only to give a unique name to this crossing of track and reference this name as an exclusive set name in all your paths using this crossing of tracks. It is much more easy to use than using invisible junctions with external references in paths.
::You can enter in this field either only one name or several names separated by a comma. Exclusive set name A will be displayed in the field as A. Exclusive set names A , B will be displayed as an exclusive set names list [A,B]. What is important is that you can enter either one name or several names separated by commas. When several names have been listed, the path belongs to all the exclusive set names and will check that no paths active are referencing any of these names before activating the path. This feature is very usefull to protect crossing tracks, and also slips and double-slips.

At the bottom of the header, you have also two links available : the '''restore default options''' link will restore all the default values for the enhanced options for the current path. The '''make current path options default options''' will change the default options in the current tower to be the current path options. Using these options link, it is quite easy to retrieve some path options and to propagate them to some other paths.

===== And now below a few tips on how to use some of the enhanced options =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]]

===== How to ajust the default distance for automatic path selection =====

By default, automatic path selection is called when an incoming train approaches an entry signal at about 0.5 mile. But since version 60 available from DLS in 02/2019, you can adjust (increase or decrease) this default distance by using specific path trigger object ( <kuid2:61392:8121:1> ). When you place a path trigger object, automatic path selection will be called when the incoming train reaches the last path trigger object before the entry signal (the train needs to have the track already set in the correct direction to go to the entry signal). If the path trigger is reached before the standard 0.5 mile distance, automatic path selection will be done with an increased distance from the entry signal. If when the train arrives at the standard distance, the system find there is a path trigger between the train and the entry signal, automatic path selection will be delayed until the train reaches the path trigger, and automatic path selection will be done at a reduced distance from the entry signal. Path trigger works only with EIT and not at all with standard ITs.

===== How to activate easily a path for a train using ITSetPath family driver commands =====

An easy method to activate a path for a train is to use one of the three driver commands ITSetPath (<kuid:61392:8111>) , ITSetPathAndWaitNotRed (<kuid:61392:8112>) or ITSetPathAndWaitActive ( <kuid:61392:8113>). These three driver commands enable the user to choose the interlocking tower and the path to request for the current driver when the driver command is executed. ITSetPath will only request the path activation and will immediately terminates, giving control to the next driver command in the train schedule. ITSetPathAndWaitNotRed will also request the path activation, but will wait until the path has been activated and the entry signal is not red before terminating and giving control to the next command. ITSetPathAndWaitActive will request the path activation and will wait for the path being active but will terminates giving control to the next command even if entry signal is still red. This last command may be usefull to set a path to drive and couple to another consist just after the entry signal.

==== Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file ====

Like for standard interlocking tower, any scenery asset can be transformed in an enhanced interlocking tower asset by making a few modifications to the config file.

You will find below as an example, taken from the config.txt file for the enhanced trc3 invisible interlocking tower, all the lines you need to have in your own asset config.txt so that your asset becomes an enhanced interlocking tower. Other lines like your asset kuid number, description, username, ... should remain unchanged.

'''List of lines needing to be present for a scenery asset to become an enhanced interlocking tower asset (in SP2 or later) :'''

<nowiki>
trainz-build 4.5
kind "interlocking-tower"
script "dummyinterlockingtower.gs"
class "DummyInterlockingTower"
category-class "IT"

extensions
{
generic-61392
{
assetid "enhancedinterlockingtower"

eitoptions
{
displayyellowdisc 0
pathrequeryonscheduledblocked 1
trcsupport 1
debuglevel 0
clearmethod 1
checktcb 1
resetjunctions 1
edityellowdisc 2
editpathrequery 2
edittrcsupport 2
editdebuglevel 2
editclearmethod 2
editchecktcb 2
editresetjunctions 2
editexclusivesets 2
}

colors-61392
{
cunselect "bbf5bb"
cselect "f5bbbb"
clink "ffffff"
cnrm "c0c0c0"
cwhite "ffffff"
calert "ff0000"
}
}
}

script-include-table
{
commondata <kuid:61392:4050>
esvlib <kuid:61392:4052>
eitlib <kuid:61392:8190>
trcitlib <kuid:61392:8191>
}

kuid-table
{
sessvar <kuid:-3:10197>
sessvars <kuid:-3:10197>
commondata <kuid2:61392:4050:51>
esvlib <kuid2:61392:4052:4>
eitlib <kuid2:61392:8190:47>
trcitlib <kuid:61392:8191>
0 <kuid:61392:4050>
1 <kuid:61392:8190>
2 <kuid:61392:4052>
}
</nowiki>

Just only a few comments on some of these mandatory lines in config.txt file :

The trainz-build tag needs to be at least 4.5 for any interlocking tower in SP2 or later. The kind tag should always be "interlocking-tower". The script and class should be "dummyinterlockingtower.gs" and "DummyinterlockingTower" and should respect the case for the class tag. And the category-class tag should be "IT". These tags are mandatory and should not be changed.

In the extensions part, default values for enhanced options are defined and may be changed if you wish to change the default values in your enhanced interlocking tower asset.

displayyellowdisctag is 0 for yellow disc disabled or 1 for yellow disc enabled.

pathrequeryonscheduleblocked should be 0 to disable requery and 1 to enable requery when an ai train has its schedule blocked.

trcsupport should be 1 to support trc system and 0 if not.

debug level should be 0 for no debugging, 1 for log only debugging message and 2 for log and print debugging messages

clear method should be 1 to clear on cancel, 2 for clear on drive, and 101 for clear after last junction. Other values may lead to unexpected results.

checktcb should be 0 for no tcb processing, 1 for process only exit tcb, 2 for process all tcbs along path.

reset junctions should be 0 to avoid reseting junctions direction when a path is cleared and 1 to reset junctions when a path is cleared.

and that's all for default values settings. The following tags will define if an enhanced option is not visible (0), displayed only (1), or displayed and editable (2).
the tags edityellowdisc, editpathrequery, edittrcsupport, editdebuglevel, editclearmethod, editchecktcb, editresetjunctions, editexclusivesets can be set to one of these values (0, 1, 2) to make the enhanced option not visible, displayed in read-only mode, or displayed and editable.
By configuring these extensions tags, an enhanced interlocking tower content creator can choose the default values for an option, and decide if it can be viewed or not, and if the end user can change the default values. For example, if trcsupport is set to 1 and edittrcsupport is set to 0, the tower will have the trc support option enabled, but not displayed and so not updatable by the end user. Using these tags the asset content creator can enforce any of the enhanced options value.

the other tags cunselect, cselect, clink, cnrm, cwhite, calert defines the colors to be used in the interface. You should not normally alter these values, but if you don't like the colors scheme used, you may alter these values to change the colors used in the interface. The string values defined for each tag are only the RGB hexadecimal values for the color to be used for this category of information.

and the last containers script-include-table and kuid-table should be left unchanged for the enhanced interlocking tower to work correctly.

File:Edit-pcr-img01.png

2021-02-18T14:11:42Z

Pguy: edition poste controle regulation img01

edition poste controle regulation img01

Poste de Contrôle et de Régulation

2021-02-18T14:00:57Z

Pguy: /* Postes de Contrôle et Régulation */

===Postes de Contrôle et Régulation===
[[Enhanced Interlocking Tower|Version anglaise : Enhanced Interlocking Tower]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

Les '''Postes de Contrôle et Régulation''' sont des composants tiers scriptés, qui étendent la notion d'Interlocking Tower au standard N3V avec des fonctionnalités supplémentaires intéressantes. Ceci se fait en rajoutant des pré traitements avant d'appeler les scripts standards N3V et aussi des post traitements. Cette méthode permet de vous proposer des composants compatibles avec les "Interlocking Towers" et supportant des fonctionnalités supplémentaires avancées.

Parmi ces fonctionnalités ajoutées, on trouvera entre autres :

: '''au niveau itinéraire :'''

::* un itinéraire accepte que son signal de sortie soit aussi un signal d'entrée au sein d'un autre poste de contrôle régulation<br>
::* un itinéraire ne sera enclenché que si il n'y a aucun convoi actuellement présent sur le parcours de l'itinéraire. Si ce n'est pas cas, l'enclenchement sera différé tant qu'il restera un convoi sur le parcours de l'itinéraire.<br>
::* un itinéraire peut être annulé en utilisant une commande conducteur adéquate ou en utilisant la règle de gestion des Postes de Contrôle et Régulation. Pour éviter tout risque de déraillements en cas d'annulation les aiguilles en recouvrement sous un convoi ne seront pas restaurées dans leur direction originelle.<br>
::* un itinéraire peut utiliser différentes méthodes de libération d'un itinéraire. La libération sur fin d'itinéraire ou annulation est la méthode traditionelle utilisée avec les interlocking towers. La libération progressive au fur et à mesure de l'avancement du train permet de libérer les objets pour une autre utilisation avant la libération finale de l'itinéraire. La libération après la dernière aiguille permet de libérer l'itinéraire dés que le train a quité la dernière aiguille.<br>
::* un itinéraire peut optionnellement vérifier la présente d'un TCB (track circuit block) autour du signal de sortie et vérifier si le TCB est occupé ou non. Les TCB sont utiles pour protéger une voie unique ou les voies le long des quais d'une gare voyageur.<br>
::* un itinéraire peut choisir de restaurer ou non ses aiguilles dans leur direction initiale après passage du train.<br>
::* un itinéraire peut optionnellement être membre d'un ensemble exclusif. Dans ce cas, l'enclenchement de l'itinéraire sera différé tant un autre itinéraire fera réfèrence au même ensemble exxclusif.<br>

: '''au niveau du poste de contrôle et régulation :'''

::* Il est possible d'afficher ou non le symbole disque jaune utilisé par N3V.
::* Il est possible de choisir un mode de possession staatique ou dynamique. Avec le mode statique tous les objets de l'itinéraire sont possédés par le poste de contrôle commande pour toute la session. En mode dynamique, seul le signal d'entrée est possédé pour toute la durée de la session ; les autres signaux et objets le long de l'itinéraire seront pris en possession uniquement pendant la durée où l'itinéraire est enclenché.<br>
::* compatibilité trc : il est possible de choisir au niveau du poste de contrôle régulation si l'on gère les passages à nuveau TRC au niveau de la règle TRC ou au niveau du poste.<br>
::* niveau de deboggage : Cette option à destination des développeurs permet de choisir entre l'absence de toute log et un logging plus complet.<br>
::* Les Postes de Contrôle Régulation permette via l'utilisation d'un composant additionnel adéquat eit pathtrigger d'ajuster à la baisse ou à la hausse la distance avant déclenchement d'un nouvel itinéraire.

=== Poste de Contrôle et de Régulation : Comment les utiliser ? ===

Pour utiliser un Poste de Contrôle et de Régulation, vous devez placer sur votre carte un objet Poste de Contrôle et Régulation comme le PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:76>. D'autres créateurs ont mise à disposition sur la DLS d'autres objets de type Poste de Contrôle Régulation ou Interlocking Tower. En fait tout objet de type "scenery" peut être transformé en un objet Poste de Contrôle Régulation par ajout de la configuation adéquate dans son fichier de configuration.

'''Liste au 18/02/2021 de tous les Postes de Contrôle Régulation disponible sur la DLS :'''

PCR - Poste de Contrôle Régulation TRC3 invisible <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

Après avoir placé sur votre carte le poste de contrôle régulation que vous voulez utiliser, vous n'avez plus qu'à éditer les propriétés de l'objet en cliquant dessus pour ouvrir la fenêtre standard d'édition des propriétés du Poste de Contrôle Régulation. Pour cet objet, l'ensemble des options à configurer sera dans le paneau supérieur de la fenêtre des propriétés.

==== Edition d'un Poste de Contrôle Régulation : les options disponibles dans la fenêtre d'édition ====

[[File:Help-edit-pcr.png | 768px | none ]]

Les options disponibles dans le paneau supérieur sont :

:* '''tower display yellow disc option :'''
::by clicking on the link on the right, you can either choose display yellow disc enabled or disabled

:* '''tower path requery option :'''
::this option is on how to process AI trains with schedule blocked. It can either be '''try requery path on schedule blocked''' or '''do not requery path on schedule blocked'''. With requery path option active, when an AI train has its schedule blocked, the enhanced IT will try to release unused paths (paths owned but not entered) to enable some other paths to be activated. The unused paths released are requeued for later activation. This standard processing done in standard IT may help to find a solution to some AI schedule blocked, but may have some side effects as some activated path may be cancelled before being later reactivated. If you do not want this behavior, just change the option to do not requery path on schedule blocked and no processing will be done when an AI train has its schedule blocked.

:* '''tower dynamic ownership option (available since release 47 march 2018) :'''
::this option is on how the tower will take ownership of all its paths objects (entry signal, exit signal, other signals, junctions, crossings, ...). Entry signals are always owned by the tower for all the session duration whatever the option choosen. With static ownership, it is the same for all paths objects for which ownership will also be taken for all the session duration. With dynamic ownership, path object ownership is taken only on path activation and will be released when the path returns to path not set state. With dynamic ownership, a path object belonging to one or several paths currently not activated is no longer owned by the tower and can be used by other components for manual operation. This may be usefull for sidings where you can have the junctions unlocked available for manual operations when no paths using this junction are active.

:* '''tower trc compatible mode :'''
::when this option is active, crossings conformant to trc system specification will not be managed by interlocking tower. Trc crossing objects will be skipped with no tower ownership and will remain managed by the trc system. if the option is inactive, interlocking tower will manage all the crossings along its path.

:* '''tower debug level :'''
::tower debug level option is an option available that help session developper to understand interlocking tower problems. Interlocking tower have an integrated debugging facility by default disabled. By selecting only log debug information or log and print debugging information, you will activate the debugging facility which may help to understand some conflicting or deadlock problems using interlocking tower.

at the bottom of the header area, you will find a link '''Restore default options''' that enables to reset all the current enhanced options to the default values defined by the enhanced tower asset content creator.

==== Editing enhanced Interlocking tower path : options available in the path editor window ====

[[File:Help-eit-assets-img03.png | 768px | none ]]

The available options in the header at the path level are :

:* '''Path clear method to use :'''
::you can here select the path clear method to be used between '''Clear on cancel (when a path is either complete or cancelled)''' , '''Clear on drive (following train progress along the path)''' and '''Clear after last junction (when the train leaves the last junction along the path)'''. Clear on cancel is the standard IT clear method that can still be selected. Clear on cancel will release path objects locks when the owning train leaves the path object. With clear on drive, the path will still be cleared and cancelled only when the train will leaves the exit signal, but path objects are unlocked as soon as the train has left them and are made available for other conflicting paths to be activated earlier. Clear after last junction will clear and cancel the path as soon as the owning train has left the last junction along the path and will not wait for the train to reach and leave the exit signal. Clear on last junction may be an interesting option for path leading to an and of track with a buffer. You can use the buffer as the exit signal, and though the owning train will never leave the buffer exit signal, the path will be cleared as soon as the train will have left the last junction along the path.

:* '''Path track circuit blocks mode :'''
::this option can either be '''no tcb processing''' , '''process only tcb for exit signal''' or '''process all tcbs along path'''. With process only tcb for exit signal, before activation, the path will look if its exit signal is embedded in some track circuit block, and if it is the case will check that the track circuit block is not occupied and not locked. If it is not the case, path activation will be delayed until the previous conditions are met. When the exit tcb is unoccupied and unlocked, path will be activated but will also lock the tcb name while the path is active. Doing so enables to guarantee that a path is activated only when a tcb embedding the exit signal is not occupied and locking its name enables to prevent other paths to activate while the initial path is active even if there are no common paths objects between the paths. Exit signal tcb are very usefull for terminal station platforms, for through station platforms and for unique track between two several passing places. As several interlocking tower paths from distinct towers can have their exit signal embedded in the same tcb, this facility also enables to do some interlocking between paths form distinct towers. Using the process all tcbs option along path enables to do the same processing for all the tcbs embedding some path objects and not only for the exit signal tcb.

:* '''Path clear option for owned junctions :'''
::this option enable to either restore the junction initial direction (default used by standard it) or to do not restore junctions initial direction when a path is cleared. This option is available mainly for prototypical behavior as sometimes it is not very prototypical to have a junction having its initial direction restored because a path has been cleared followed by rechanging the direction due to another path being activated. With this option you avoid successive inadequate direction changes for junctions.

:* '''Exclusive sets membership :'''
::exclusive sets membership is an option that has been designed to help protect a crossing of tracks without the need to add some invisible junctions using these junctions as external object reference. When you add an exclusive set name in this field, the path will only be activated if no other paths in any tower with also the same exclusive set name is active. Paths sharing the same exclusive set name cannot be simultaneously active and this works inside the same tower as inside any tower on your route. To protect a crossing of track, you need only to give a unique name to this crossing of track and reference this name as an exclusive set name in all your paths using this crossing of tracks. It is much more easy to use than using invisible junctions with external references in paths.
::You can enter in this field either only one name or several names separated by a comma. Exclusive set name A will be displayed in the field as A. Exclusive set names A , B will be displayed as an exclusive set names list [A,B]. What is important is that you can enter either one name or several names separated by commas. When several names have been listed, the path belongs to all the exclusive set names and will check that no paths active are referencing any of these names before activating the path. This feature is very usefull to protect crossing tracks, and also slips and double-slips.

At the bottom of the header, you have also two links available : the '''restore default options''' link will restore all the default values for the enhanced options for the current path. The '''make current path options default options''' will change the default options in the current tower to be the current path options. Using these options link, it is quite easy to retrieve some path options and to propagate them to some other paths.

===== And now below a few tips on how to use some of the enhanced options =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]]

===== How to ajust the default distance for automatic path selection =====

By default, automatic path selection is called when an incoming train approaches an entry signal at about 0.5 mile. But since version 60 available from DLS in 02/2019, you can adjust (increase or decrease) this default distance by using specific path trigger object ( <kuid2:61392:8121:1> ). When you place a path trigger object, automatic path selection will be called when the incoming train reaches the last path trigger object before the entry signal (the train needs to have the track already set in the correct direction to go to the entry signal). If the path trigger is reached before the standard 0.5 mile distance, automatic path selection will be done with an increased distance from the entry signal. If when the train arrives at the standard distance, the system find there is a path trigger between the train and the entry signal, automatic path selection will be delayed until the train reaches the path trigger, and automatic path selection will be done at a reduced distance from the entry signal. Path trigger works only with EIT and not at all with standard ITs.

===== How to activate easily a path for a train using ITSetPath family driver commands =====

An easy method to activate a path for a train is to use one of the three driver commands ITSetPath (<kuid:61392:8111>) , ITSetPathAndWaitNotRed (<kuid:61392:8112>) or ITSetPathAndWaitActive ( <kuid:61392:8113>). These three driver commands enable the user to choose the interlocking tower and the path to request for the current driver when the driver command is executed. ITSetPath will only request the path activation and will immediately terminates, giving control to the next driver command in the train schedule. ITSetPathAndWaitNotRed will also request the path activation, but will wait until the path has been activated and the entry signal is not red before terminating and giving control to the next command. ITSetPathAndWaitActive will request the path activation and will wait for the path being active but will terminates giving control to the next command even if entry signal is still red. This last command may be usefull to set a path to drive and couple to another consist just after the entry signal.

==== Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file ====

Like for standard interlocking tower, any scenery asset can be transformed in an enhanced interlocking tower asset by making a few modifications to the config file.

You will find below as an example, taken from the config.txt file for the enhanced trc3 invisible interlocking tower, all the lines you need to have in your own asset config.txt so that your asset becomes an enhanced interlocking tower. Other lines like your asset kuid number, description, username, ... should remain unchanged.

'''List of lines needing to be present for a scenery asset to become an enhanced interlocking tower asset (in SP2 or later) :'''

<nowiki>
trainz-build 4.5
kind "interlocking-tower"
script "dummyinterlockingtower.gs"
class "DummyInterlockingTower"
category-class "IT"

extensions
{
generic-61392
{
assetid "enhancedinterlockingtower"

eitoptions
{
displayyellowdisc 0
pathrequeryonscheduledblocked 1
trcsupport 1
debuglevel 0
clearmethod 1
checktcb 1
resetjunctions 1
edityellowdisc 2
editpathrequery 2
edittrcsupport 2
editdebuglevel 2
editclearmethod 2
editchecktcb 2
editresetjunctions 2
editexclusivesets 2
}

colors-61392
{
cunselect "bbf5bb"
cselect "f5bbbb"
clink "ffffff"
cnrm "c0c0c0"
cwhite "ffffff"
calert "ff0000"
}
}
}

script-include-table
{
commondata <kuid:61392:4050>
esvlib <kuid:61392:4052>
eitlib <kuid:61392:8190>
trcitlib <kuid:61392:8191>
}

kuid-table
{
sessvar <kuid:-3:10197>
sessvars <kuid:-3:10197>
commondata <kuid2:61392:4050:51>
esvlib <kuid2:61392:4052:4>
eitlib <kuid2:61392:8190:47>
trcitlib <kuid:61392:8191>
0 <kuid:61392:4050>
1 <kuid:61392:8190>
2 <kuid:61392:4052>
}
</nowiki>

Just only a few comments on some of these mandatory lines in config.txt file :

The trainz-build tag needs to be at least 4.5 for any interlocking tower in SP2 or later. The kind tag should always be "interlocking-tower". The script and class should be "dummyinterlockingtower.gs" and "DummyinterlockingTower" and should respect the case for the class tag. And the category-class tag should be "IT". These tags are mandatory and should not be changed.

In the extensions part, default values for enhanced options are defined and may be changed if you wish to change the default values in your enhanced interlocking tower asset.

displayyellowdisctag is 0 for yellow disc disabled or 1 for yellow disc enabled.

pathrequeryonscheduleblocked should be 0 to disable requery and 1 to enable requery when an ai train has its schedule blocked.

trcsupport should be 1 to support trc system and 0 if not.

debug level should be 0 for no debugging, 1 for log only debugging message and 2 for log and print debugging messages

clear method should be 1 to clear on cancel, 2 for clear on drive, and 101 for clear after last junction. Other values may lead to unexpected results.

checktcb should be 0 for no tcb processing, 1 for process only exit tcb, 2 for process all tcbs along path.

reset junctions should be 0 to avoid reseting junctions direction when a path is cleared and 1 to reset junctions when a path is cleared.

and that's all for default values settings. The following tags will define if an enhanced option is not visible (0), displayed only (1), or displayed and editable (2).
the tags edityellowdisc, editpathrequery, edittrcsupport, editdebuglevel, editclearmethod, editchecktcb, editresetjunctions, editexclusivesets can be set to one of these values (0, 1, 2) to make the enhanced option not visible, displayed in read-only mode, or displayed and editable.
By configuring these extensions tags, an enhanced interlocking tower content creator can choose the default values for an option, and decide if it can be viewed or not, and if the end user can change the default values. For example, if trcsupport is set to 1 and edittrcsupport is set to 0, the tower will have the trc support option enabled, but not displayed and so not updatable by the end user. Using these tags the asset content creator can enforce any of the enhanced options value.

the other tags cunselect, cselect, clink, cnrm, cwhite, calert defines the colors to be used in the interface. You should not normally alter these values, but if you don't like the colors scheme used, you may alter these values to change the colors used in the interface. The string values defined for each tag are only the RGB hexadecimal values for the color to be used for this category of information.

and the last containers script-include-table and kuid-table should be left unchanged for the enhanced interlocking tower to work correctly.

Poste de Contrôle et de Régulation

2021-02-18T13:08:37Z

Pguy: Created page with "===Postes de Contrôle et Régulation=== Version anglaise : Enhanced Interlocking Towers thumb ..."

===Postes de Contrôle et Régulation===
[[Enhanced Interlocking Towers|Version anglaise : Enhanced Interlocking Towers]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

Les '''Postes de Contrôle et Régulation''' sont des composants tiers scriptés, qui étendent la notion d'Interlocking Tower au standard N3V avec des fonctionnalités supplémentaires intéressantes. Ceci se fait en rajoutant des pré traitements avant d'appeler les scripts standards N3V et aussi des post traitements. Cette méthode permet de vous proposer des composants compatibles avec les "Interlocking Towers" et supportant des fonctionnalités supplémentaires avancées.

Parmi ces fonctionnalités ajoutées, on trouvera entre autres :

: '''au niveau itinéraire :'''

::* un itinéraire accepte que son signal de sortie soit aussi un signal d'entrée au sein d'un autre poste de contrôle régulation<br>
::* un itinéraire ne sera enclenché que si il n'y a aucun convoi actuellement présent sur le parcours de l'itinéraire. Si ce n'est pas cas, l'enclenchement sera différé tant qu'il restera un convoi sur le parcours de l'itinéraire.<br>
::* un itinéraire peut être annulé en utilisant une commande conducteur adéquate ou en utilisant la règle de gestion des Postes de Contrôle et Régulation. Pour éviter tout risque de déraillements en cas d'annulation les aiguilles en recouvrement sous un convoi ne seront pas restaurées dans leur direction originelle.<br>
::* un itinéraire peut utiliser différentes méthodes de libération d'un itinéraire. La libération sur fin d'itinéraire ou annulation est la méthode traditionelle utilisée avec les interlocking towers. La libération progressive au fur et à mesure de l'avancement du train permet de libérer les objets pour une autre utilisation avant la libération finale de l'itinéraire. La libération après la dernière aiguille permet de libérer l'itinéraire dés que le train a quité la dernière aiguille.<br>
::* un itinéraire peut optionnellement vérifier la présente d'un TCB (track circuit block) autour du signal de sortie et vérifier si le TCB est occupé ou non. Les TCB sont utiles pour protéger une voie unique ou les voies le long des quais d'une gare voyageur.<br>
::* un itinéraire peut choisir de restaurer ou non ses aiguilles dans leur direction initiale après passage du train.<br>
::* un itinéraire peut optionnellement être membre d'un ensemble exclusif. Dans ce cas, l'enclenchement de l'itinéraire sera différé tant un autre itinéraire fera réfèrence au même ensemble exxclusif.<br>

: '''au niveau du poste de contrôle et régulation :'''

::* Il est possible d'afficher ou non le symbole disque jaune utilisé par N3V.
::* Il est possible de choisir un mode de possession staatique ou dynamique. Avec le mode statique tous les objets de l'itinéraire sont possédés par le poste de contrôle commande pour toute la session. En mode dynamique, seul le signal d'entrée est possédé pour toute la durée de la session ; les autres signaux et objets le long de l'itinéraire seront pris en possession uniquement pendant la durée où l'itinéraire est enclenché.<br>
::* compatibilité trc : il est possible de choisir au niveau du poste de contrôle régulation si l'on gère les passages à nuveau TRC au niveau de la règle TRC ou au niveau du poste.<br>
::* niveau de deboggage : Cette option à destination des développeurs permet de choisir entre l'absence de toute log et un logging plus complet.<br>
::* Les Postes de Contrôle Régulation permette via l'utilisation d'un composant additionnel adéquat eit pathtrigger d'ajuster à la baisse ou à la hausse la distance avant déclenchement d'un nouvel itinéraire.

Enhanced Interlocking Tower

2021-02-18T12:29:07Z

Pguy: /* Enhanced Interlocking Tower assets */

{{FUN-top}}

===Enhanced Interlocking Tower assets===
[[Poste de Contrôle et de Régulation|Version française : Postes de Contrôle et Régulation]]
[[File:Help-eit-assets-img01.png | left | thumb ]]

'''Enhanced Interlocking Tower''' assets are 3rd party scripted assets which extend the Interlocking Tower with some extra features. By doing some pre-processing before calling standard interlocking tower processing and doing some post-processing on return, these new assets enable the user to take the best from interlocking towers and to offer some enhanced functionalities by default or on option.

Among these added functionalities you will find :

: '''at the path level :'''

::* path supports that an exit signal is also an entry signal from another tower<br>
::* path will be activated only if there are no extra consist currently occupying the path. If it is not the case, path activation will be delayed until there is no longer any extra consist on path.<br>
::* path can be cancelled using a specific driver command or using the enhanced interlocking manager rule run time monitor. Cancelling a path can occur at any time for an owning train which is stopped, and for an owning train moving only if there are at least two signals between the train position and the path entry signal. To avoid any derailment risk, paths junctions currently overlapped by a consist will not restore their initial direction.<br>
::* path can use several clear method : clear on cancel is the traditional clear method used with standard IT ; clear_on_drive enables to release junctions and signals when your train has left the junction or signal so that these objects are made available for any waiting other path before the initial path is cleared ; clear_on_last_junction will clear the path when the last junction along the path has been left : this method may be used at terminal station with path having the buffer at the end of the track being the exit signal - though the exit signal will never be reached, the path will be cleared when the last junction will be left.<br>
::* path can optionally check if a track circuit block embedding the exit signal is occupied or not, and will lock the track circuit block name until the path is cleared. It is also possible to request that all track circuit blocks embedding any path objects (except the path entry signal) will be processed in a similar manner. Using exit signal TCB can help a lot to protect terminal or through station platforms.<br>
::* path can optionally choose either to restore path junctions initial direction when a path is cleared or to do not restore path junctions initial direction and keep the current target direction when the path was active.<br>
::* path can optionally be member of an exclusive set name, and will have their activation delayed as long as any other path referencing the same exclusive set name is active. This feature enables to protect easily track crossing without using some invisible junctions or signals.<br>

: '''at the tower level :'''

::* it is possible to choose if the yellow disc used to reselect a target path is displayed or not.<br>
::* processing on train schedule blocked can be choosen : you may either use the standard IT implementation that will try to cancel and reactivate later unused paths (paths owned but not already entered) which may help activating a path for a train with schedule blocked at an entry signal.You may also avoid this standard processing by disabling the option.<br>
::* since release 47 available in 03/2018 on DLS, you can choose between static and dynamic ownership for path objects ownership. Path entry signals are in both cases always owned by the interlocking tower for all the session duration. With static ownership, all paths objects are also owned by the tower for the session duration. With dynamic ownership, ownership for path objects not being an entry signal is taken only on path activation and is released when the path is released. With this dynamic option, path objects ownership last only for the duration of the path being active (for all objects except path entry signals which are always owned for the session duration).<br>
::* trc compatibility : it is possible to choose at the tower level if crossing conformant to TRC system will be managed by the interlocking tower or by the trc system.<br>
::* tower debug level : this option is mainly for session developers. It enables to have either no logging (for production), or only logging to the system log, or to have both logging and messages on screen.<br>
::* since release 60 available in 02/2019 on DLS, EIT supports PathTrigger object placed on track, that makes possible to adjust (increase or decrease) the distance to the entry signal at which automatic path selection is done for the incoming train.

=== Enhanced Interlocking Tower : How to use them ?===

To use enhanced interlocking tower, you need to drop on your route an enhanced interlocking tower like the enhanced trc3 interlocking tower <kuid2:61392:8101:4> available on dls. Some other content creators will shortly also release some other enhanced interlocking tower asset. In fact any scenery asset can be defined as an enhanced interlocking tower by using the adequate configuration file.

'''List of available enhanced interlocking tower on DLS (at current date 03/03/2018) :'''

Enhanced trc3 invisible interlocking tower <kuid2:61392:8101:47> by pguy

ITE SB Nameable 1 <kuid:182010:100397> by peterwhite

ITE SB Nameable 2 <kuid:182010:100403> by peterwhite

ITE SB Nameable 3 <kuid:182010:100410> by peterwhite

ITE SB Nameable 5 <kuid:182010:100401> by peterwhite

ITE SB Nameable 6 <kuid:182010:100407> by peterwhite

ITE SB Nameable 7 <kuid:182010:100402> by peterwhite

ITE SB Nameable 8 <kuid:182010:100398> by peterwhite

ITE SB Nameable 9 <kuid:182010:100408> by peterwhite

ITE SB Nameable 10 <kuid:182010:100411> by peterwhite

When you have installed on your route the enhanced interlocking tower you want to use, you only need to edit the object property by clicking on it to open the standard editor window. For enhanced interlocking tower, the editor window includes options that can be selected in the header at the top of the tower object properties window.

==== Editing enhanced Interlocking tower : options available in the tower editor window ====

[[File:Help-eit-assets-img02.png | 768px | none ]]

The available options in the header at the tower level are :

:* '''tower display yellow disc option :'''
::by clicking on the link on the right, you can either choose display yellow disc enabled or disabled

:* '''tower path requery option :'''
::this option is on how to process AI trains with schedule blocked. It can either be '''try requery path on schedule blocked''' or '''do not requery path on schedule blocked'''. With requery path option active, when an AI train has its schedule blocked, the enhanced IT will try to release unused paths (paths owned but not entered) to enable some other paths to be activated. The unused paths released are requeued for later activation. This standard processing done in standard IT may help to find a solution to some AI schedule blocked, but may have some side effects as some activated path may be cancelled before being later reactivated. If you do not want this behavior, just change the option to do not requery path on schedule blocked and no processing will be done when an AI train has its schedule blocked.

:* '''tower dynamic ownership option (available since release 47 march 2018) :'''
::this option is on how the tower will take ownership of all its paths objects (entry signal, exit signal, other signals, junctions, crossings, ...). Entry signals are always owned by the tower for all the session duration whatever the option choosen. With static ownership, it is the same for all paths objects for which ownership will also be taken for all the session duration. With dynamic ownership, path object ownership is taken only on path activation and will be released when the path returns to path not set state. With dynamic ownership, a path object belonging to one or several paths currently not activated is no longer owned by the tower and can be used by other components for manual operation. This may be usefull for sidings where you can have the junctions unlocked available for manual operations when no paths using this junction are active.

:* '''tower trc compatible mode :'''
::when this option is active, crossings conformant to trc system specification will not be managed by interlocking tower. Trc crossing objects will be skipped with no tower ownership and will remain managed by the trc system. if the option is inactive, interlocking tower will manage all the crossings along its path.

:* '''tower debug level :'''
::tower debug level option is an option available that help session developper to understand interlocking tower problems. Interlocking tower have an integrated debugging facility by default disabled. By selecting only log debug information or log and print debugging information, you will activate the debugging facility which may help to understand some conflicting or deadlock problems using interlocking tower.

at the bottom of the header area, you will find a link '''Restore default options''' that enables to reset all the current enhanced options to the default values defined by the enhanced tower asset content creator.

==== Editing enhanced Interlocking tower path : options available in the path editor window ====

[[File:Help-eit-assets-img03.png | 768px | none ]]

The available options in the header at the path level are :

:* '''Path clear method to use :'''
::you can here select the path clear method to be used between '''Clear on cancel (when a path is either complete or cancelled)''' , '''Clear on drive (following train progress along the path)''' and '''Clear after last junction (when the train leaves the last junction along the path)'''. Clear on cancel is the standard IT clear method that can still be selected. Clear on cancel will release path objects locks when the owning train leaves the path object. With clear on drive, the path will still be cleared and cancelled only when the train will leaves the exit signal, but path objects are unlocked as soon as the train has left them and are made available for other conflicting paths to be activated earlier. Clear after last junction will clear and cancel the path as soon as the owning train has left the last junction along the path and will not wait for the train to reach and leave the exit signal. Clear on last junction may be an interesting option for path leading to an and of track with a buffer. You can use the buffer as the exit signal, and though the owning train will never leave the buffer exit signal, the path will be cleared as soon as the train will have left the last junction along the path.

:* '''Path track circuit blocks mode :'''
::this option can either be '''no tcb processing''' , '''process only tcb for exit signal''' or '''process all tcbs along path'''. With process only tcb for exit signal, before activation, the path will look if its exit signal is embedded in some track circuit block, and if it is the case will check that the track circuit block is not occupied and not locked. If it is not the case, path activation will be delayed until the previous conditions are met. When the exit tcb is unoccupied and unlocked, path will be activated but will also lock the tcb name while the path is active. Doing so enables to guarantee that a path is activated only when a tcb embedding the exit signal is not occupied and locking its name enables to prevent other paths to activate while the initial path is active even if there are no common paths objects between the paths. Exit signal tcb are very usefull for terminal station platforms, for through station platforms and for unique track between two several passing places. As several interlocking tower paths from distinct towers can have their exit signal embedded in the same tcb, this facility also enables to do some interlocking between paths form distinct towers. Using the process all tcbs option along path enables to do the same processing for all the tcbs embedding some path objects and not only for the exit signal tcb.

:* '''Path clear option for owned junctions :'''
::this option enable to either restore the junction initial direction (default used by standard it) or to do not restore junctions initial direction when a path is cleared. This option is available mainly for prototypical behavior as sometimes it is not very prototypical to have a junction having its initial direction restored because a path has been cleared followed by rechanging the direction due to another path being activated. With this option you avoid successive inadequate direction changes for junctions.

:* '''Exclusive sets membership :'''
::exclusive sets membership is an option that has been designed to help protect a crossing of tracks without the need to add some invisible junctions using these junctions as external object reference. When you add an exclusive set name in this field, the path will only be activated if no other paths in any tower with also the same exclusive set name is active. Paths sharing the same exclusive set name cannot be simultaneously active and this works inside the same tower as inside any tower on your route. To protect a crossing of track, you need only to give a unique name to this crossing of track and reference this name as an exclusive set name in all your paths using this crossing of tracks. It is much more easy to use than using invisible junctions with external references in paths.
::You can enter in this field either only one name or several names separated by a comma. Exclusive set name A will be displayed in the field as A. Exclusive set names A , B will be displayed as an exclusive set names list [A,B]. What is important is that you can enter either one name or several names separated by commas. When several names have been listed, the path belongs to all the exclusive set names and will check that no paths active are referencing any of these names before activating the path. This feature is very usefull to protect crossing tracks, and also slips and double-slips.

At the bottom of the header, you have also two links available : the '''restore default options''' link will restore all the default values for the enhanced options for the current path. The '''make current path options default options''' will change the default options in the current tower to be the current path options. Using these options link, it is quite easy to retrieve some path options and to propagate them to some other paths.

===== And now below a few tips on how to use some of the enhanced options =====

::TIP001 - [[Enhanced Interlocking Tower Tip 001 | How to protect paths using crossing, slips, double slips ]]

===== How to ajust the default distance for automatic path selection =====

By default, automatic path selection is called when an incoming train approaches an entry signal at about 0.5 mile. But since version 60 available from DLS in 02/2019, you can adjust (increase or decrease) this default distance by using specific path trigger object ( <kuid2:61392:8121:1> ). When you place a path trigger object, automatic path selection will be called when the incoming train reaches the last path trigger object before the entry signal (the train needs to have the track already set in the correct direction to go to the entry signal). If the path trigger is reached before the standard 0.5 mile distance, automatic path selection will be done with an increased distance from the entry signal. If when the train arrives at the standard distance, the system find there is a path trigger between the train and the entry signal, automatic path selection will be delayed until the train reaches the path trigger, and automatic path selection will be done at a reduced distance from the entry signal. Path trigger works only with EIT and not at all with standard ITs.

===== How to activate easily a path for a train using ITSetPath family driver commands =====

An easy method to activate a path for a train is to use one of the three driver commands ITSetPath (<kuid:61392:8111>) , ITSetPathAndWaitNotRed (<kuid:61392:8112>) or ITSetPathAndWaitActive ( <kuid:61392:8113>). These three driver commands enable the user to choose the interlocking tower and the path to request for the current driver when the driver command is executed. ITSetPath will only request the path activation and will immediately terminates, giving control to the next driver command in the train schedule. ITSetPathAndWaitNotRed will also request the path activation, but will wait until the path has been activated and the entry signal is not red before terminating and giving control to the next command. ITSetPathAndWaitActive will request the path activation and will wait for the path being active but will terminates giving control to the next command even if entry signal is still red. This last command may be usefull to set a path to drive and couple to another consist just after the entry signal.

==== Creating your own enhanced Interlocking tower asset : What are the modifications needed in your asset config.txt file ====

Like for standard interlocking tower, any scenery asset can be transformed in an enhanced interlocking tower asset by making a few modifications to the config file.

You will find below as an example, taken from the config.txt file for the enhanced trc3 invisible interlocking tower, all the lines you need to have in your own asset config.txt so that your asset becomes an enhanced interlocking tower. Other lines like your asset kuid number, description, username, ... should remain unchanged.

'''List of lines needing to be present for a scenery asset to become an enhanced interlocking tower asset (in SP2 or later) :'''

<nowiki>
trainz-build 4.5
kind "interlocking-tower"
script "dummyinterlockingtower.gs"
class "DummyInterlockingTower"
category-class "IT"

extensions
{
generic-61392
{
assetid "enhancedinterlockingtower"

eitoptions
{
displayyellowdisc 0
pathrequeryonscheduledblocked 1
trcsupport 1
debuglevel 0
clearmethod 1
checktcb 1
resetjunctions 1
edityellowdisc 2
editpathrequery 2
edittrcsupport 2
editdebuglevel 2
editclearmethod 2
editchecktcb 2
editresetjunctions 2
editexclusivesets 2
}

colors-61392
{
cunselect "bbf5bb"
cselect "f5bbbb"
clink "ffffff"
cnrm "c0c0c0"
cwhite "ffffff"
calert "ff0000"
}
}
}

script-include-table
{
commondata <kuid:61392:4050>
esvlib <kuid:61392:4052>
eitlib <kuid:61392:8190>
trcitlib <kuid:61392:8191>
}

kuid-table
{
sessvar <kuid:-3:10197>
sessvars <kuid:-3:10197>
commondata <kuid2:61392:4050:51>
esvlib <kuid2:61392:4052:4>
eitlib <kuid2:61392:8190:47>
trcitlib <kuid:61392:8191>
0 <kuid:61392:4050>
1 <kuid:61392:8190>
2 <kuid:61392:4052>
}
</nowiki>

Just only a few comments on some of these mandatory lines in config.txt file :

The trainz-build tag needs to be at least 4.5 for any interlocking tower in SP2 or later. The kind tag should always be "interlocking-tower". The script and class should be "dummyinterlockingtower.gs" and "DummyinterlockingTower" and should respect the case for the class tag. And the category-class tag should be "IT". These tags are mandatory and should not be changed.

In the extensions part, default values for enhanced options are defined and may be changed if you wish to change the default values in your enhanced interlocking tower asset.

displayyellowdisctag is 0 for yellow disc disabled or 1 for yellow disc enabled.

pathrequeryonscheduleblocked should be 0 to disable requery and 1 to enable requery when an ai train has its schedule blocked.

trcsupport should be 1 to support trc system and 0 if not.

debug level should be 0 for no debugging, 1 for log only debugging message and 2 for log and print debugging messages

clear method should be 1 to clear on cancel, 2 for clear on drive, and 101 for clear after last junction. Other values may lead to unexpected results.

checktcb should be 0 for no tcb processing, 1 for process only exit tcb, 2 for process all tcbs along path.

reset junctions should be 0 to avoid reseting junctions direction when a path is cleared and 1 to reset junctions when a path is cleared.

and that's all for default values settings. The following tags will define if an enhanced option is not visible (0), displayed only (1), or displayed and editable (2).
the tags edityellowdisc, editpathrequery, edittrcsupport, editdebuglevel, editclearmethod, editchecktcb, editresetjunctions, editexclusivesets can be set to one of these values (0, 1, 2) to make the enhanced option not visible, displayed in read-only mode, or displayed and editable.
By configuring these extensions tags, an enhanced interlocking tower content creator can choose the default values for an option, and decide if it can be viewed or not, and if the end user can change the default values. For example, if trcsupport is set to 1 and edittrcsupport is set to 0, the tower will have the trc support option enabled, but not displayed and so not updatable by the end user. Using these tags the asset content creator can enforce any of the enhanced options value.

the other tags cunselect, cselect, clink, cnrm, cwhite, calert defines the colors to be used in the interface. You should not normally alter these values, but if you don't like the colors scheme used, you may alter these values to change the colors used in the interface. The string values defined for each tag are only the RGB hexadecimal values for the color to be used for this category of information.

and the last containers script-include-table and kuid-table should be left unchanged for the enhanced interlocking tower to work correctly.

=== Enhanced Interlocking Tower Manager Rule : How to monitor at run time your towers, paths and trains ===

Enhanced Interlocking Tower Manager Rule is a session rule that is released with the Enhanced Interlocking Tower package. Under Surveyor it enables editing of your towers and paths from a centralized interface, and under Driver it provides a run time monitor to display current available information on your towers, paths and trains using or waiting for any path.

The rule is available on DLS under the KUID <kuid2:61392:8130:47>. The rule works with both standard interlocking towers and enhanced interlocking towers.

To get more details on what this rule can display, just click on the following link to the [[Enhanced Interlocking Tower Manager Rule]] dedicated page.:

That is currently all for Enhanced Interlocking Tower assets wiki documentation.
I hope you will enjoy these new assets to help you using more versatile and powerfull interlocking tower.
And if you need more details or have unanswered questions, do not hesitate to post in the forums or to send me a private message.
Regards. Pierre GUY (61392)

==See Also==
*[[HowTo/Configure_An_Interlocking_Tower]]
*[[Enhanced_Interlocking_Tower_Manager_Rule]]
*[[Enhanced_Interlocking_Tower_Tip_001]]

[[Category:Help|Enhanced Interlocking Tower]]

{{FUN-bot}}

Named Objects Library

2020-10-23T17:06:30Z

Pguy: /* Named Objects Library : How to register the objects type you want to be cached by the library */

{{FUN-top}}

===Named Objects Library (SP2 and later)===

[[File:NamedObjectsLib.jpg | left | thumb ]]

The '''Named Objects Library''' is a library that may be used to manage information about available named objects in the current session. The library can manage cached data for several common objects type, which can be individually asynchronously refreshed in the background using internal threads inside the library, and can return at any time synchronously the content of any of the managed caches.

Usually, an asset using the Named Objects Library will first load and initialize the library in its init routine, will then register the objects type to be cached in the library (which will immediately start the asynchronous process of collecting the cached data for this object type), and will later use the cached data by calling the library to retrieve the current cached data.
The library uses all the new object search API available since Tane SP2 and will automaticly refresh in the background any expired cache data in both surveyor and driver mode.

Named Objects Library has been designed and developped to support the new search request Tane SP2 API for all the assets by pguy. It is not a general purpose API interface but an adapted interface to make Tane SP2 migration easy for pguy's assets. The API is now published and public, as it may be interesting for some other scripters that have not already done this migration to use this library for their own migration to the new interfaces.

The present article is for scripters who wants to use the Named Objects Library and give details below on how to configure an asset to use the Named Objects Library, on how to initialise in an asset the library and on how to register the objects type you want to cache, and finaly on how later to retrieve the current content of a cache for a specific object type.

=== Named Objects Library : How to use it ?===

To use the Named Object Library in any of your assets, you need first to modify its config.txt file to add the Named Objects Library in its kuid table section and in its script include table so that your asset can reference the Named Objects Library to import the Named Object Library API as a static class nochelper contained in nochelper.gs inside the Named Objects Library Asset.

The current Named Objects Library available on DLS is <kuid2:61392:4053:22> [for date 23/10/2020].
There will be in the future new versions to add new cache types and fix any remaining bugs.

Your asset config.txt file should include the following sections to be able to load the Named Objects Library API as nochelper static class :

script-include-table
{
. . .
noclib <kuid:61392:4053>
. . .
}

and

kuid-table
{
. . .
noclib <kuid2:61392:4053:22>
. . .
}

with these two modifications in your asset config.txt file, you should now be able to import the noclib API by adding :

include "nochelper.gs"

to the header in your assets script files needing to call the noclib API

=== Named Objects Library : How to initialise it ?===

Now that we have imported the file "nochelper.gs" in your scripts, all other needed steps will be done by calling some API functions defined in the nochelper static class.

First, you need to initialise the library by calling

public void Init(Asset p_asset) ;

this call is mandatory with p_asset being the current asset that will use the library. You can check that the initialisation has been successfull by calling

public bool IsLibraryAvailable(void) ;

that will return true if the library has been initialised and false if it is not the case. These calls are generally made inside your asset init function but can be located else where as long as they are done before any other call to the library.

For example, your asset init function may look like :

public void Init(Asset p_asset)
{
. . .
''my asset initialisation code''
. . .
nochelper.Init(p_asset) ;
if (!nochelper.IsLibraryAvailable())
{
. . .
''my asset error code for noclib not available''
. . .
}
. . .
}

=== Named Objects Library : How to register the objects type you want to be cached by the library===

The Named Objects Library currently supports 13 objects type that are defined in nochelper static class as integer values :

public define int NOC_TRACKMARK = 1 ; // for trackmarks names
public define int NOC_TRACKMARK_LIST = 2 ; // for trackmark list names
public define int NOC_TRIGGER = 4 ; // for triggers
public define int NOC_SIGNAL = 8 ; // for signals
public define int NOC_JUNCTION = 16 ; // for junctions
public define int NOC_CROSSING = 32 ; // for crossings
public define int NOC_TCB = 64 ; // for track circuit block detector
public define int NOC_ITS = 128 ; // for interlocking towers
public define int NOC_CONSIST = 512 ; // for trains or consists
public define int NOC_VEHICLE = 1024 ; // for vehicles
public define int NOC_INDUSTRY = 4096 ; // for industries
public define int NOC_STATION = 8192 ; // for passenger stations
public define int NOC_PORTAL = 16384 ; // for portals
public define int NOC_SCENERY = 32768 ; // for any scenery object
public define int NOC_TRC = 32769 ; // for #TRC objects

A cache in the library is defined by its objects type integer value and by a searchFilter string. After being refreshed, a cache will contain an array of NamedObjectInfo objects containing all available objects matching the cache objects type and whose name begin by the search filter. If the search filter is empty (blank string) all the objects matching the cache objects type are returned.

To add an object type and searchFilter to be cached by the library, you only need to call one of these functions :

public int AddNamedObjectsTypeToCache(int cacheType, string searchFilter, bool autoupdate, float period, GameObject notifyGameObject) ;
public int AddNamedObjectsTypeToCache(int cacheType, string searchFilter, bool autoupdate, float period) ;
public int AddNamedObjectsTypeToCache(int cacheType,GameObject notifyGameObject) ;
public int AddNamedObjectsTypeToCache(int cacheType) ;

where cacheType defines the type of objects to be cached
searchfilter is an optional string to limit the search to all objects whose name are prefixed by searchfilter
autoupdate is now an obsolete bool parameter that will be ignored. autoupdate is always done in both surveyor and driver mode when needed.
notifyGameObject is an optional GameObject reference that will receive a message "Noclib","CacheRefreshComplete" when the cached data will be available (Cf RefreshNamedObjectsCache below)

When a AddNamedObjectsTypeToCache call is made to the library, the library checks if there has been already a similar call made earlier by another asset. If it is the case, the library will reuse the already existing cached data array ; if it is not the case it will create the new cached data array. In all cases it will start an implicit refresh cache operation to collect or refresh the available information on the existing objects matching both the cache objects type and the searchfilter prefix.
The integer value returned is a sequential number for the implicit refresh operation that can be later used to check if the asynchronous cache refresh operation is complete.
The cache refresh operations are optimized by the library. If several cache refresh operations for the same cache type and search filter are pending when the asynchronous refresh thread starts its operation, all the pending cache refresh operations are merged in only one refresh operation notifying all the requesters.

Depending on the number of objects to scan and retrieve in your route, the duration of a cache refresh operation may last from a few miliseconds to several seconds.
If you want to be sure that the implicit cache refresh operation is complete, you will need to wait for the "Noclib","CacheRefreshComplete" message to be received by the notifyGameObject and check that the parameter soup included in the message has the expected cache type (cachetype tag), search filter (searchfilter tag) and refresh serial value (refreshserialvalue tag) for the cache refresh operation just being completed.
It is also possible to call IsNamedObjectsCacheRefreshComplete described later in this documentation with the cache type, search filter and refresh sequential number to check cache refresh is complete.

Cached data supports the search results expiry notification option included in Tane SP2 and will redo an automatic cache refresh operation if the current cached data expires. This means that adding a new object or renaming or deletion of an existing object will be detected and cached data will be refreshed. There is only a little latency of a few seconds for the cache update before the new cache content is available.

AddNamedObjectsTypeToCache are generally located in the Init function of your asset and you need to make one call for each of the objects type to be cached.

for example, if you want to cache both interlocking towers and consists, you will have in your asset init function :

public void Init(Asset p_asset)
{
. . .
''my asset initialisation code''
. . .
nochelper.Init(p_asset) ;
if (!nochelper.IsLibraryAvailable())
{
. . .
''my asset error code for noclib not available''
. . .
}
nochelper.AddNamedObjectsTypeToCache(nochelper.NOC_ITS) ;
nochelper.AddNamedObjectsTypeToCache(nochelper.NOC_CONSIST) ;
}

=== Named Objects Library : How to retrieve the cached objects ===

Now that we have added the objects we want to be managed in the cache, the last step is to call the library to retrieve the data currently in the cache

To retrieve the data currently in cache, you will call this function :

public NamedObjectInfo[] GetNamedObjects(int cacheType,string searchFilter) ; // returns named objects cache with filter
public NamedObjectInfo[] GetNamedObjects(int cacheType) ; // returns named objects cache

where cacheType defines the type of objects to be retrieved
searchfilter is an optional string to limit the search to only objects whose name are prefixed by searchfilter

These calls returns an array of NamedObjectInfo containing all the current data for the target cacheType and searchFilter.

For readers who do not already know NamedObjectInfo class data, NamedObjectInfo class object is a class defined in World.gs that is used to return available data on exisisting objects in a route and session.
You will find below its class definition extracted from World.gs :

//=============================================================================
// Name: NamedObjectInfo
// Desc: The result type used by AsyncObjectSearchResult, see below for more.
//=============================================================================
final class NamedObjectInfo
{
public GameObject objectRef; // A reference to the object, if it's loaded
public GameObjectID objectId; // The unique ID of the object
public string localisedUsername; // The display name for the object, in the current language
public string categoryString; // The category code string for the object
};

For each object returned, NamedObjectInfo gives you its reference if loaded, its unique GameObjectID, its display name and its category list string for future search.

Take care that reference to the object may be no longer valid if the object has been unloaded since the information was cached, and you should check if the reference is still valid by calling

bool isStillValid = Router.DoesGameObjectStillExist(GameObject obj);

before using the object reference. If the reference is null or is no longer valid, you can retrieve a reference on the object by calling some functions in world.gs using the unique object gameobjectid :

public native GameObject GetGameObjectByIDIfLoaded(GameObjectID objectID); will return a GameObject reference if the object is currently loaded and null if it is no longer loaded
public GameObject SynchronouslyLoadGameObjectByID(GameObjectID objectID) ; will load the gameobject and return the new gameobject reference. This primitive can only be called under a thread

for example, if you want to loop on all existing interlocking towers, you will use the following code :

. . .
NamedObjectInfo[] itInfos = nochelper.GetNamedObjects(nochelper.NOC_ITS) ;
if (itInfos.size())
for (I=0;i<itInfos.size();I++)
{
. . .
''processing to be done on each itInfos''
. . .
}

=== Named Objects Library : How to refresh the cached objects ===

In order to refresh a named objects cache you will call one of these functions :

public int RefreshNamedObjectsCache(int cacheType, string searchFilter, GameObject postGameObject) ; // refresh cached type with post option
public int RefreshNamedObjectsCache(int cacheType, GameObject postGameObject) ; // refresh cached type with post option
public int RefreshNamedObjectsCache(int cacheType) ; // refresh cached type

where cacheType defines the type of objects to be refreshed
searchfilter is an optional string to limit the search to only objects whose name are prefixed by searchfilter
postGameObject is an optional GameObject that will be notified that the cache refresh operation is complete by receiving a message "Noclib","CacheRefreshComplete" from the library

The integer value returned is a unique refresh sequential serial number that can be used later to check if the cache refresh operation is complete. If you want to be sure that the cache refresh operation is complete, you will need to wait for the "Noclib","CacheRefreshComplete" message to be received by the postGameObject and check that the parameter soup included in the message has the expected cache type (cachetype tag), search filter (searchfilter tag) and refresh serial value (refreshserialvalue tag) for the cache refresh operation just being completed.
It is also possible to call IsNamedObjectsCacheRefreshComplete described later in this documentation with the cache type, search filter and refresh sequential number to check the cache refresh completion.

It is not needed to call RefreshNamedObjectsCache(. . .) just after a AddNamedObjectsToCache(. . .) as the AddNamedObjectsToCache processing includes already an implicit RefreshNamedObjectsCache call to initialise the cached data.

It is also possible to check if a cache refresh is complete by calling one of these functions :

public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter, int refreshSerialValue, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType) ;

where cacheType and searchFilter defines the cache objects type to be checked
refreshSerialValue is an integer value identifying the cache refresh operation to check, which has been retuned by a previous RefreshNamedObjectsCache or AddNamedObjectsToCache request.
postGameObject is an optional GameObject that will be notified that the cache refresh operation is now complete by receiving a message "Noclib","CacheRefreshComplete" from the library
if the cache refresh operation is still in progress.

=== Named Objects Library : alternative RetrieveNamedObjects API ===

The above API is fine for regular recurrent request to retrieve available named objects, and using cache techniques enables to optimize scripts by sharing data between multiple assets and offers synchronous answers to requests that have been pre fetched asynchronously.

But sometimes scripts needs to make a non recurrent request for some specific objects for which caching is not usefull.

The alternative RetrieveNamedObjects API has been added to the Named Objects Library recently (in version 10) for this purpose. You can call it this way, if you are executing under a thread :

public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string searchFilter,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string searchFilter) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType) ;

where cacheType is the type of objects you want to retrieve
searchFilter is the prefix for the objects to be searched
searchInCache is a bool option to try to retrieve first the objects in the cached data
keepInCache is a bool option to update the cached data if a new search request has been done

As you may have guess, these functions can be called even if no objects of cacheType have been added to the named objects cache library. RetrieveNamedObjects needs to be called under a thread. If searchInCache is true, it will first try to find a cache in the library matching cacheType and searchFilter. If it finds one, it will return the current cache data. If it does not find one or if searchInCache is false, it will start a new asynchronous search request for these objects and will wait for the end of this search request. If keepInCache is set to true, it will copy the results to any matching existing cache in the library or will create a new cached data in the library to keep the data in cache for future use. And it will finaly return the results to the caller.

This function may be more easy to use for callers under a thread and for specific request done only once and not recurrent between assets.

public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string[] searchFilters,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string[] searchFilters) ;

These functions enables to return in a unique NamedObjectInfo array objects of the same cacheType matching several searchFilters with some results coming from already existing data cached and other results being only new search results not cached.

=== Named Objects Library : other miscellaneous functions ===

The nochelper class includes also a few other specific functions :

public NamedObjectInfo[] GetTrackMarksInList(string sList) ; can be called to retrieve trackmarks belonging to a specific trackmark list. Needs NOC_TRACKMARK_LIST to be currently cached.
This primitive is needed for DriveToTrackMarkList driver command.
public int GetPlatformsCountForStation(string stationName) ; can be called to retrieve the number of platforms for a virtual passenger station name. Needs NOC_STATION to be currently cached.
This primitive is needed for DriveToStation driver command.
public GameObjectID GetPlatformsStationID(string sVirtualPlatformName); can be called to retrieve the real station GameObjectID for a virtual platform name. Needs NOC_STATION to be currently cached.
This primitive is needed for DriveToStation driver command.
public string GetPlatformsTrack(string sVirtualPlatformName) ; can be called to retrieve the real track name for a virtual platform name. Needs NOC_STATION to be currently loaded
This primitive is needed for DriveToStation driver command.

=== Named Objects Library : example application ===

To download on the DLS : 'Named Objects Library test' <kuid:458053:102778>.
A simple object to put anywhere on a route ; its only purpose is to count the triggers on the 'world', as an illustration of the possibilities of the tool 'Named Objects Library'.
You can edit its script and discover how some of the codes exposed above may be implemented.

Please note : the script displays a list of triggers (if any on the route) ; this list may be consulted at the bottom left of the screen, in Driver Mode only.

[[Category:Help|Named Objects Library]]

{{FUN-bot}}

Named Objects Library

2020-10-23T16:49:09Z

Pguy: /* Named Objects Library : How to use it ? */

{{FUN-top}}

===Named Objects Library (SP2 and later)===

[[File:NamedObjectsLib.jpg | left | thumb ]]

The '''Named Objects Library''' is a library that may be used to manage information about available named objects in the current session. The library can manage cached data for several common objects type, which can be individually asynchronously refreshed in the background using internal threads inside the library, and can return at any time synchronously the content of any of the managed caches.

Usually, an asset using the Named Objects Library will first load and initialize the library in its init routine, will then register the objects type to be cached in the library (which will immediately start the asynchronous process of collecting the cached data for this object type), and will later use the cached data by calling the library to retrieve the current cached data.
The library uses all the new object search API available since Tane SP2 and will automaticly refresh in the background any expired cache data in both surveyor and driver mode.

Named Objects Library has been designed and developped to support the new search request Tane SP2 API for all the assets by pguy. It is not a general purpose API interface but an adapted interface to make Tane SP2 migration easy for pguy's assets. The API is now published and public, as it may be interesting for some other scripters that have not already done this migration to use this library for their own migration to the new interfaces.

The present article is for scripters who wants to use the Named Objects Library and give details below on how to configure an asset to use the Named Objects Library, on how to initialise in an asset the library and on how to register the objects type you want to cache, and finaly on how later to retrieve the current content of a cache for a specific object type.

=== Named Objects Library : How to use it ?===

To use the Named Object Library in any of your assets, you need first to modify its config.txt file to add the Named Objects Library in its kuid table section and in its script include table so that your asset can reference the Named Objects Library to import the Named Object Library API as a static class nochelper contained in nochelper.gs inside the Named Objects Library Asset.

The current Named Objects Library available on DLS is <kuid2:61392:4053:22> [for date 23/10/2020].
There will be in the future new versions to add new cache types and fix any remaining bugs.

Your asset config.txt file should include the following sections to be able to load the Named Objects Library API as nochelper static class :

script-include-table
{
. . .
noclib <kuid:61392:4053>
. . .
}

and

kuid-table
{
. . .
noclib <kuid2:61392:4053:22>
. . .
}

with these two modifications in your asset config.txt file, you should now be able to import the noclib API by adding :

include "nochelper.gs"

to the header in your assets script files needing to call the noclib API

=== Named Objects Library : How to initialise it ?===

Now that we have imported the file "nochelper.gs" in your scripts, all other needed steps will be done by calling some API functions defined in the nochelper static class.

First, you need to initialise the library by calling

public void Init(Asset p_asset) ;

this call is mandatory with p_asset being the current asset that will use the library. You can check that the initialisation has been successfull by calling

public bool IsLibraryAvailable(void) ;

that will return true if the library has been initialised and false if it is not the case. These calls are generally made inside your asset init function but can be located else where as long as they are done before any other call to the library.

For example, your asset init function may look like :

public void Init(Asset p_asset)
{
. . .
''my asset initialisation code''
. . .
nochelper.Init(p_asset) ;
if (!nochelper.IsLibraryAvailable())
{
. . .
''my asset error code for noclib not available''
. . .
}
. . .
}

=== Named Objects Library : How to register the objects type you want to be cached by the library===

The Named Objects Library currently supports 13 objects type that are defined in nochelper static class as integer values :

public define int NOC_TRACKMARK = 1 ; // for trackmarks names
public define int NOC_TRACKMARK_LIST = 2 ; // for trackmark list names
public define int NOC_TRIGGER = 4 ; // for triggers
public define int NOC_SIGNAL = 8 ; // for signals
public define int NOC_JUNCTION = 16 ; // for junctions
public define int NOC_CROSSING = 32 ; // for crossings
public define int NOC_TCB = 64 ; // for track circuit block detector
public define int NOC_ITS = 128 ; // for interlocking towers
public define int NOC_CONSIST = 512 ; // for trains or consists
public define int NOC_VEHICLE = 1024 ; // for vehicles
public define int NOC_INDUSTRY = 4096 ; // for industries
public define int NOC_STATION = 8192 ; // for passenger stations
public define int NOC_PORTAL = 16384 ; // for portals
public define int NOC_SCENERY = 32768 ; // for any scenery object
public define int NOC_TRC = 32769 ; // for #TRC objects

A cache in the library is defined by its objects type integer value and by a searchFilter string. After being refreshed, a cache will contain an array of NamedObjectInfo objects containing all available objects matching the cache objects type and whose name begin by the search filter. If the search filter is empty (blank string) all the objects matching the cache objects type are returned.

To add an object type and searchFilter to be cached by the library, you only need to call one of these functions :

public int AddNamedObjectsTypeToCache(int cacheType, string searchFilter, bool autoupdate, float period, GameObject notifyGameObject) ;
public int AddNamedObjectsTypeToCache(int cacheType, string searchFilter, bool autoupdate, float period) ;
public int AddNamedObjectsTypeToCache(int cacheType,GameObject notifyGameObject) ;
public int AddNamedObjectsTypeToCache(int cacheType) ;

where cacheType defines the type of objects to be cached
searchfilter is an optional string to limit the search to all objects whose name are prefixed by searchfilter
autoupdate is now an obsolete bool parameter that will be ignored. autoupdate is always done in surveyor mode every 5 seconds and only for consists in driver mode every 5 seconds.
notifyGameObject is an optional GameObject reference that will receive a message "Noclib","CacheRefreshComplete" when the cached data will be available (Cf RefreshNamedObjectsCache below)

When a AddNamedObjectsTypeToCache call is made to the library, the library checks if there has been already a similar call made earlier by another asset. If it is the case, the library will reuse the already existing cached data array ; if it is not the case it will create the new cached data array. In all cases it will start an implicit refresh cache operation to collect or refresh the available information on the existing objects matching both the cache objects type and the searchfilter prefix.
The integer value returned is a sequential number for the implicit refresh operation that can be later used to check if the asynchronous cache refresh operation is complete.
The cache refresh operations are optimized by the library. If several cache refresh operations for the same cache type and search filter are pending when the asynchronous refresh thread starts its operation, all the pending cache refresh operations are merged in only one refresh operation notifying all the requesters.

Depending on the number of objects to scan and retrieve in your route, the duration of a cache refresh operation may last from a few miliseconds to several seconds.
If you want to be sure that the implicit cache refresh operation is complete, you will need to wait for the "Noclib","CacheRefreshComplete" message to be received by the notifyGameObject and check that the parameter soup included in the message has the expected cache type (cachetype tag), search filter (searchfilter tag) and refresh serial value (refreshserialvalue tag) for the cache refresh operation just being completed.
It is also possible to call IsNamedObjectsCacheRefreshComplete described later in this documentation with the cache type, search filter and refresh sequential number to check.

Cached data supports the search results expiry notification option included in Tane SP2 and will redo an automatic cache refresh operation if the current cached data expires. This means that rename or deletion of objects should be detected and cached data will be then refreshed. New objects added are not so easily detected : that is why all cached data is refreshed every 5 seconds in surveyor mode and only consist cached data is refreshed every 5 seconds in driver mode, so that cached data contains the most recent data with a latency of 5 seconds for performance reason.

AddNamedObjectsTypeToCache are generally located in the Init function of your asset and you need to make one call for each of the objects type to be cached.

for example, if you want to cache both interlocking towers and consists, you will have in your asset init function :

public void Init(Asset p_asset)
{
. . .
''my asset initialisation code''
. . .
nochelper.Init(p_asset) ;
if (!nochelper.IsLibraryAvailable())
{
. . .
''my asset error code for noclib not available''
. . .
}
nochelper.AddNamedObjectsTypeToCache(nochelper.NOC_ITS) ;
nochelper.AddNamedObjectsTypeToCache(nochelper.NOC_CONSIST) ;
}

=== Named Objects Library : How to retrieve the cached objects ===

Now that we have added the objects we want to be managed in the cache, the last step is to call the library to retrieve the data currently in the cache

To retrieve the data currently in cache, you will call this function :

public NamedObjectInfo[] GetNamedObjects(int cacheType,string searchFilter) ; // returns named objects cache with filter
public NamedObjectInfo[] GetNamedObjects(int cacheType) ; // returns named objects cache

where cacheType defines the type of objects to be retrieved
searchfilter is an optional string to limit the search to only objects whose name are prefixed by searchfilter

These calls returns an array of NamedObjectInfo containing all the current data for the target cacheType and searchFilter.

For readers who do not already know NamedObjectInfo class data, NamedObjectInfo class object is a class defined in World.gs that is used to return available data on exisisting objects in a route and session.
You will find below its class definition extracted from World.gs :

//=============================================================================
// Name: NamedObjectInfo
// Desc: The result type used by AsyncObjectSearchResult, see below for more.
//=============================================================================
final class NamedObjectInfo
{
public GameObject objectRef; // A reference to the object, if it's loaded
public GameObjectID objectId; // The unique ID of the object
public string localisedUsername; // The display name for the object, in the current language
public string categoryString; // The category code string for the object
};

For each object returned, NamedObjectInfo gives you its reference if loaded, its unique GameObjectID, its display name and its category list string for future search.

Take care that reference to the object may be no longer valid if the object has been unloaded since the information was cached, and you should check if the reference is still valid by calling

bool isStillValid = Router.DoesGameObjectStillExist(GameObject obj);

before using the object reference. If the reference is null or is no longer valid, you can retrieve a reference on the object by calling some functions in world.gs using the unique object gameobjectid :

public native GameObject GetGameObjectByIDIfLoaded(GameObjectID objectID); will return a GameObject reference if the object is currently loaded and null if it is no longer loaded
public GameObject SynchronouslyLoadGameObjectByID(GameObjectID objectID) ; will load the gameobject and return the new gameobject reference. This primitive can only be called under a thread

for example, if you want to loop on all existing interlocking towers, you will use the following code :

. . .
NamedObjectInfo[] itInfos = nochelper.GetNamedObjects(nochelper.NOC_ITS) ;
if (itInfos.size())
for (I=0;i<itInfos.size();I++)
{
. . .
''processing to be done on each itInfos''
. . .
}

=== Named Objects Library : How to refresh the cached objects ===

In order to refresh a named objects cache you will call one of these functions :

public int RefreshNamedObjectsCache(int cacheType, string searchFilter, GameObject postGameObject) ; // refresh cached type with post option
public int RefreshNamedObjectsCache(int cacheType, GameObject postGameObject) ; // refresh cached type with post option
public int RefreshNamedObjectsCache(int cacheType) ; // refresh cached type

where cacheType defines the type of objects to be refreshed
searchfilter is an optional string to limit the search to only objects whose name are prefixed by searchfilter
postGameObject is an optional GameObject that will be notified that the cache refresh operation is complete by receiving a message "Noclib","CacheRefreshComplete" from the library

The integer value returned is a unique refresh sequential serial number that can be used later to check if the cache refresh operation is complete. If you want to be sure that the cache refresh operation is complete, you will need to wait for the "Noclib","CacheRefreshComplete" message to be received by the postGameObject and check that the parameter soup included in the message has the expected cache type (cachetype tag), search filter (searchfilter tag) and refresh serial value (refreshserialvalue tag) for the cache refresh operation just being completed.
It is also possible to call IsNamedObjectsCacheRefreshComplete described later in this documentation with the cache type, search filter and refresh sequential number to check the cache refresh completion.

It is not needed to call RefreshNamedObjectsCache(. . .) just after a AddNamedObjectsToCache(. . .) as the AddNamedObjectsToCache processing includes already an implicit RefreshNamedObjectsCache call to initialise the cached data.

It is also possible to check if a cache refresh is complete by calling one of these functions :

public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter, int refreshSerialValue, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType) ;

where cacheType and searchFilter defines the cache objects type to be checked
refreshSerialValue is an integer value identifying the cache refresh operation to check, which has been retuned by a previous RefreshNamedObjectsCache or AddNamedObjectsToCache request.
postGameObject is an optional GameObject that will be notified that the cache refresh operation is now complete by receiving a message "Noclib","CacheRefreshComplete" from the library
if the cache refresh operation is still in progress.

=== Named Objects Library : alternative RetrieveNamedObjects API ===

The above API is fine for regular recurrent request to retrieve available named objects, and using cache techniques enables to optimize scripts by sharing data between multiple assets and offers synchronous answers to requests that have been pre fetched asynchronously.

But sometimes scripts needs to make a non recurrent request for some specific objects for which caching is not usefull.

The alternative RetrieveNamedObjects API has been added to the Named Objects Library recently (in version 10) for this purpose. You can call it this way, if you are executing under a thread :

public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string searchFilter,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string searchFilter) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType) ;

where cacheType is the type of objects you want to retrieve
searchFilter is the prefix for the objects to be searched
searchInCache is a bool option to try to retrieve first the objects in the cached data
keepInCache is a bool option to update the cached data if a new search request has been done

As you may have guess, these functions can be called even if no objects of cacheType have been added to the named objects cache library. RetrieveNamedObjects needs to be called under a thread. If searchInCache is true, it will first try to find a cache in the library matching cacheType and searchFilter. If it finds one, it will return the current cache data. If it does not find one or if searchInCache is false, it will start a new asynchronous search request for these objects and will wait for the end of this search request. If keepInCache is set to true, it will copy the results to any matching existing cache in the library or will create a new cached data in the library to keep the data in cache for future use. And it will finaly return the results to the caller.

This function may be more easy to use for callers under a thread and for specific request done only once and not recurrent between assets.

public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string[] searchFilters,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string[] searchFilters) ;

These functions enables to return in a unique NamedObjectInfo array objects of the same cacheType matching several searchFilters with some results coming from already existing data cached and other results being only new search results not cached.

=== Named Objects Library : other miscellaneous functions ===

The nochelper class includes also a few other specific functions :

public NamedObjectInfo[] GetTrackMarksInList(string sList) ; can be called to retrieve trackmarks belonging to a specific trackmark list. Needs NOC_TRACKMARK_LIST to be currently cached.
This primitive is needed for DriveToTrackMarkList driver command.
public int GetPlatformsCountForStation(string stationName) ; can be called to retrieve the number of platforms for a virtual passenger station name. Needs NOC_STATION to be currently cached.
This primitive is needed for DriveToStation driver command.
public GameObjectID GetPlatformsStationID(string sVirtualPlatformName); can be called to retrieve the real station GameObjectID for a virtual platform name. Needs NOC_STATION to be currently cached.
This primitive is needed for DriveToStation driver command.
public string GetPlatformsTrack(string sVirtualPlatformName) ; can be called to retrieve the real track name for a virtual platform name. Needs NOC_STATION to be currently loaded
This primitive is needed for DriveToStation driver command.

=== Named Objects Library : example application ===

To download on the DLS : 'Named Objects Library test' <kuid:458053:102778>.
A simple object to put anywhere on a route ; its only purpose is to count the triggers on the 'world', as an illustration of the possibilities of the tool 'Named Objects Library'.
You can edit its script and discover how some of the codes exposed above may be implemented.

Please note : the script displays a list of triggers (if any on the route) ; this list may be consulted at the bottom left of the screen, in Driver Mode only.

[[Category:Help|Named Objects Library]]

{{FUN-bot}}

Named Objects Library

2020-10-23T16:43:55Z

Pguy: /* Named Objects Library (SP2 and later) */

{{FUN-top}}

===Named Objects Library (SP2 and later)===

[[File:NamedObjectsLib.jpg | left | thumb ]]

The '''Named Objects Library''' is a library that may be used to manage information about available named objects in the current session. The library can manage cached data for several common objects type, which can be individually asynchronously refreshed in the background using internal threads inside the library, and can return at any time synchronously the content of any of the managed caches.

Usually, an asset using the Named Objects Library will first load and initialize the library in its init routine, will then register the objects type to be cached in the library (which will immediately start the asynchronous process of collecting the cached data for this object type), and will later use the cached data by calling the library to retrieve the current cached data.
The library uses all the new object search API available since Tane SP2 and will automaticly refresh in the background any expired cache data in both surveyor and driver mode.

Named Objects Library has been designed and developped to support the new search request Tane SP2 API for all the assets by pguy. It is not a general purpose API interface but an adapted interface to make Tane SP2 migration easy for pguy's assets. The API is now published and public, as it may be interesting for some other scripters that have not already done this migration to use this library for their own migration to the new interfaces.

The present article is for scripters who wants to use the Named Objects Library and give details below on how to configure an asset to use the Named Objects Library, on how to initialise in an asset the library and on how to register the objects type you want to cache, and finaly on how later to retrieve the current content of a cache for a specific object type.

=== Named Objects Library : How to use it ?===

To use the Named Object Library in any of your assets, you need first to modify its config.txt file to add the Named Objects Library in its kuid table section and in its script include table so that your asset can reference the Named Objects Library to import the Named Object Library API as a static class nochelper contained in nochelper.gs inside the Named Objects Library Asset.

The current Named Objects Library available on DLS is <kuid2:61392:4053:10> but there will be soon a new release 11 <kuid2:61392:4053:11> that will bring supports for track circuit blocks objects.

Your asset config.txt file should include the following sections to be able to load the Named Objects Library API as nochelper static class :

script-include-table
{
. . .
noclib <kuid:61392:4053>
. . .
}

and

kuid-table
{
. . .
noclib <kuid2:61392:4053:10>
. . .
}

with these two modifications in your asset config.txt file, you should now be able to import the noclib API by adding :

include "nochelper.gs"

to the header in your assets script files needing to call the noclib API

=== Named Objects Library : How to initialise it ?===

Now that we have imported the file "nochelper.gs" in your scripts, all other needed steps will be done by calling some API functions defined in the nochelper static class.

First, you need to initialise the library by calling

public void Init(Asset p_asset) ;

this call is mandatory with p_asset being the current asset that will use the library. You can check that the initialisation has been successfull by calling

public bool IsLibraryAvailable(void) ;

that will return true if the library has been initialised and false if it is not the case. These calls are generally made inside your asset init function but can be located else where as long as they are done before any other call to the library.

For example, your asset init function may look like :

public void Init(Asset p_asset)
{
. . .
''my asset initialisation code''
. . .
nochelper.Init(p_asset) ;
if (!nochelper.IsLibraryAvailable())
{
. . .
''my asset error code for noclib not available''
. . .
}
. . .
}

=== Named Objects Library : How to register the objects type you want to be cached by the library===

The Named Objects Library currently supports 13 objects type that are defined in nochelper static class as integer values :

public define int NOC_TRACKMARK = 1 ; // for trackmarks names
public define int NOC_TRACKMARK_LIST = 2 ; // for trackmark list names
public define int NOC_TRIGGER = 4 ; // for triggers
public define int NOC_SIGNAL = 8 ; // for signals
public define int NOC_JUNCTION = 16 ; // for junctions
public define int NOC_CROSSING = 32 ; // for crossings
public define int NOC_TCB = 64 ; // for track circuit block detector
public define int NOC_ITS = 128 ; // for interlocking towers
public define int NOC_CONSIST = 512 ; // for trains or consists
public define int NOC_VEHICLE = 1024 ; // for vehicles
public define int NOC_INDUSTRY = 4096 ; // for industries
public define int NOC_STATION = 8192 ; // for passenger stations
public define int NOC_PORTAL = 16384 ; // for portals
public define int NOC_SCENERY = 32768 ; // for any scenery object
public define int NOC_TRC = 32769 ; // for #TRC objects

A cache in the library is defined by its objects type integer value and by a searchFilter string. After being refreshed, a cache will contain an array of NamedObjectInfo objects containing all available objects matching the cache objects type and whose name begin by the search filter. If the search filter is empty (blank string) all the objects matching the cache objects type are returned.

To add an object type and searchFilter to be cached by the library, you only need to call one of these functions :

public int AddNamedObjectsTypeToCache(int cacheType, string searchFilter, bool autoupdate, float period, GameObject notifyGameObject) ;
public int AddNamedObjectsTypeToCache(int cacheType, string searchFilter, bool autoupdate, float period) ;
public int AddNamedObjectsTypeToCache(int cacheType,GameObject notifyGameObject) ;
public int AddNamedObjectsTypeToCache(int cacheType) ;

where cacheType defines the type of objects to be cached
searchfilter is an optional string to limit the search to all objects whose name are prefixed by searchfilter
autoupdate is now an obsolete bool parameter that will be ignored. autoupdate is always done in surveyor mode every 5 seconds and only for consists in driver mode every 5 seconds.
notifyGameObject is an optional GameObject reference that will receive a message "Noclib","CacheRefreshComplete" when the cached data will be available (Cf RefreshNamedObjectsCache below)

When a AddNamedObjectsTypeToCache call is made to the library, the library checks if there has been already a similar call made earlier by another asset. If it is the case, the library will reuse the already existing cached data array ; if it is not the case it will create the new cached data array. In all cases it will start an implicit refresh cache operation to collect or refresh the available information on the existing objects matching both the cache objects type and the searchfilter prefix.
The integer value returned is a sequential number for the implicit refresh operation that can be later used to check if the asynchronous cache refresh operation is complete.
The cache refresh operations are optimized by the library. If several cache refresh operations for the same cache type and search filter are pending when the asynchronous refresh thread starts its operation, all the pending cache refresh operations are merged in only one refresh operation notifying all the requesters.

Depending on the number of objects to scan and retrieve in your route, the duration of a cache refresh operation may last from a few miliseconds to several seconds.
If you want to be sure that the implicit cache refresh operation is complete, you will need to wait for the "Noclib","CacheRefreshComplete" message to be received by the notifyGameObject and check that the parameter soup included in the message has the expected cache type (cachetype tag), search filter (searchfilter tag) and refresh serial value (refreshserialvalue tag) for the cache refresh operation just being completed.
It is also possible to call IsNamedObjectsCacheRefreshComplete described later in this documentation with the cache type, search filter and refresh sequential number to check.

Cached data supports the search results expiry notification option included in Tane SP2 and will redo an automatic cache refresh operation if the current cached data expires. This means that rename or deletion of objects should be detected and cached data will be then refreshed. New objects added are not so easily detected : that is why all cached data is refreshed every 5 seconds in surveyor mode and only consist cached data is refreshed every 5 seconds in driver mode, so that cached data contains the most recent data with a latency of 5 seconds for performance reason.

AddNamedObjectsTypeToCache are generally located in the Init function of your asset and you need to make one call for each of the objects type to be cached.

for example, if you want to cache both interlocking towers and consists, you will have in your asset init function :

public void Init(Asset p_asset)
{
. . .
''my asset initialisation code''
. . .
nochelper.Init(p_asset) ;
if (!nochelper.IsLibraryAvailable())
{
. . .
''my asset error code for noclib not available''
. . .
}
nochelper.AddNamedObjectsTypeToCache(nochelper.NOC_ITS) ;
nochelper.AddNamedObjectsTypeToCache(nochelper.NOC_CONSIST) ;
}

=== Named Objects Library : How to retrieve the cached objects ===

Now that we have added the objects we want to be managed in the cache, the last step is to call the library to retrieve the data currently in the cache

To retrieve the data currently in cache, you will call this function :

public NamedObjectInfo[] GetNamedObjects(int cacheType,string searchFilter) ; // returns named objects cache with filter
public NamedObjectInfo[] GetNamedObjects(int cacheType) ; // returns named objects cache

where cacheType defines the type of objects to be retrieved
searchfilter is an optional string to limit the search to only objects whose name are prefixed by searchfilter

These calls returns an array of NamedObjectInfo containing all the current data for the target cacheType and searchFilter.

For readers who do not already know NamedObjectInfo class data, NamedObjectInfo class object is a class defined in World.gs that is used to return available data on exisisting objects in a route and session.
You will find below its class definition extracted from World.gs :

//=============================================================================
// Name: NamedObjectInfo
// Desc: The result type used by AsyncObjectSearchResult, see below for more.
//=============================================================================
final class NamedObjectInfo
{
public GameObject objectRef; // A reference to the object, if it's loaded
public GameObjectID objectId; // The unique ID of the object
public string localisedUsername; // The display name for the object, in the current language
public string categoryString; // The category code string for the object
};

For each object returned, NamedObjectInfo gives you its reference if loaded, its unique GameObjectID, its display name and its category list string for future search.

Take care that reference to the object may be no longer valid if the object has been unloaded since the information was cached, and you should check if the reference is still valid by calling

bool isStillValid = Router.DoesGameObjectStillExist(GameObject obj);

before using the object reference. If the reference is null or is no longer valid, you can retrieve a reference on the object by calling some functions in world.gs using the unique object gameobjectid :

public native GameObject GetGameObjectByIDIfLoaded(GameObjectID objectID); will return a GameObject reference if the object is currently loaded and null if it is no longer loaded
public GameObject SynchronouslyLoadGameObjectByID(GameObjectID objectID) ; will load the gameobject and return the new gameobject reference. This primitive can only be called under a thread

for example, if you want to loop on all existing interlocking towers, you will use the following code :

. . .
NamedObjectInfo[] itInfos = nochelper.GetNamedObjects(nochelper.NOC_ITS) ;
if (itInfos.size())
for (I=0;i<itInfos.size();I++)
{
. . .
''processing to be done on each itInfos''
. . .
}

=== Named Objects Library : How to refresh the cached objects ===

In order to refresh a named objects cache you will call one of these functions :

public int RefreshNamedObjectsCache(int cacheType, string searchFilter, GameObject postGameObject) ; // refresh cached type with post option
public int RefreshNamedObjectsCache(int cacheType, GameObject postGameObject) ; // refresh cached type with post option
public int RefreshNamedObjectsCache(int cacheType) ; // refresh cached type

where cacheType defines the type of objects to be refreshed
searchfilter is an optional string to limit the search to only objects whose name are prefixed by searchfilter
postGameObject is an optional GameObject that will be notified that the cache refresh operation is complete by receiving a message "Noclib","CacheRefreshComplete" from the library

The integer value returned is a unique refresh sequential serial number that can be used later to check if the cache refresh operation is complete. If you want to be sure that the cache refresh operation is complete, you will need to wait for the "Noclib","CacheRefreshComplete" message to be received by the postGameObject and check that the parameter soup included in the message has the expected cache type (cachetype tag), search filter (searchfilter tag) and refresh serial value (refreshserialvalue tag) for the cache refresh operation just being completed.
It is also possible to call IsNamedObjectsCacheRefreshComplete described later in this documentation with the cache type, search filter and refresh sequential number to check the cache refresh completion.

It is not needed to call RefreshNamedObjectsCache(. . .) just after a AddNamedObjectsToCache(. . .) as the AddNamedObjectsToCache processing includes already an implicit RefreshNamedObjectsCache call to initialise the cached data.

It is also possible to check if a cache refresh is complete by calling one of these functions :

public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter, int refreshSerialValue, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, GameObject postGameObject) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType, string searchFilter) ;
public bool IsNamedObjectsCacheRefreshComplete(int cacheType) ;

where cacheType and searchFilter defines the cache objects type to be checked
refreshSerialValue is an integer value identifying the cache refresh operation to check, which has been retuned by a previous RefreshNamedObjectsCache or AddNamedObjectsToCache request.
postGameObject is an optional GameObject that will be notified that the cache refresh operation is now complete by receiving a message "Noclib","CacheRefreshComplete" from the library
if the cache refresh operation is still in progress.

=== Named Objects Library : alternative RetrieveNamedObjects API ===

The above API is fine for regular recurrent request to retrieve available named objects, and using cache techniques enables to optimize scripts by sharing data between multiple assets and offers synchronous answers to requests that have been pre fetched asynchronously.

But sometimes scripts needs to make a non recurrent request for some specific objects for which caching is not usefull.

The alternative RetrieveNamedObjects API has been added to the Named Objects Library recently (in version 10) for this purpose. You can call it this way, if you are executing under a thread :

public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string searchFilter,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string searchFilter) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType) ;

where cacheType is the type of objects you want to retrieve
searchFilter is the prefix for the objects to be searched
searchInCache is a bool option to try to retrieve first the objects in the cached data
keepInCache is a bool option to update the cached data if a new search request has been done

As you may have guess, these functions can be called even if no objects of cacheType have been added to the named objects cache library. RetrieveNamedObjects needs to be called under a thread. If searchInCache is true, it will first try to find a cache in the library matching cacheType and searchFilter. If it finds one, it will return the current cache data. If it does not find one or if searchInCache is false, it will start a new asynchronous search request for these objects and will wait for the end of this search request. If keepInCache is set to true, it will copy the results to any matching existing cache in the library or will create a new cached data in the library to keep the data in cache for future use. And it will finaly return the results to the caller.

This function may be more easy to use for callers under a thread and for specific request done only once and not recurrent between assets.

public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string[] searchFilters,bool searchInCache,bool keepInCache) ;
public NamedObjectInfo[] RetrieveNamedObjects(int cacheType,string[] searchFilters) ;

These functions enables to return in a unique NamedObjectInfo array objects of the same cacheType matching several searchFilters with some results coming from already existing data cached and other results being only new search results not cached.

=== Named Objects Library : other miscellaneous functions ===

The nochelper class includes also a few other specific functions :

public NamedObjectInfo[] GetTrackMarksInList(string sList) ; can be called to retrieve trackmarks belonging to a specific trackmark list. Needs NOC_TRACKMARK_LIST to be currently cached.
This primitive is needed for DriveToTrackMarkList driver command.
public int GetPlatformsCountForStation(string stationName) ; can be called to retrieve the number of platforms for a virtual passenger station name. Needs NOC_STATION to be currently cached.
This primitive is needed for DriveToStation driver command.
public GameObjectID GetPlatformsStationID(string sVirtualPlatformName); can be called to retrieve the real station GameObjectID for a virtual platform name. Needs NOC_STATION to be currently cached.
This primitive is needed for DriveToStation driver command.
public string GetPlatformsTrack(string sVirtualPlatformName) ; can be called to retrieve the real track name for a virtual platform name. Needs NOC_STATION to be currently loaded
This primitive is needed for DriveToStation driver command.

=== Named Objects Library : example application ===

To download on the DLS : 'Named Objects Library test' <kuid:458053:102778>.
A simple object to put anywhere on a route ; its only purpose is to count the triggers on the 'world', as an illustration of the possibilities of the tool 'Named Objects Library'.
You can edit its script and discover how some of the codes exposed above may be implemented.

Please note : the script displays a list of triggers (if any on the route) ; this list may be consulted at the bottom left of the screen, in Driver Mode only.

[[Category:Help|Named Objects Library]]

{{FUN-bot}}

MissionCodes Manager

2019-02-17T10:28:11Z

Pguy: /* Train Mission Codes auto path assignment : and what are path triggers ? */

{{FUN-top}}

===Mission Code Manager rule===
[[File:Help-missioncodemanager-rule-img01.png]]

'''MissionCode Manager''' is a rule ( <kuid:61392:8200> ) which enables to add, edit and manage Mission Code strings, which can be assigned to trains and can be used to auto select paths in interlocking towers to route the trains to their destination.

''This page has been updated to support new features brought with version 60 of Mission code Manager and associated stuff.

=== Train Mission Codes : what is it and for which purpose ?===

A train mission code is any string choosen in a list of arbitrary mission code strings that needs first to be defined by editing the MissionCode Manager Rule (<kuid2:61392:8200>) under surveyor.
After defining all the train mission codes you will use in your session, you can assign one or several train mission codes to any available train using either the trains tab while editing MissionCode Manager rule, or using the driver command SetMissionCode ( <kuid:61392:8201> ) to assign the first mission code to your current train and AddMissionCode ( <kuid:61392:8203> ) to add another mission code to the current train.
All trains, by default have no mission code assigned but may be assigned one or several train mission codes. The mission codes will stay linked to the train until new mission codes are assigned to the train or the mission codes are cleared using also the SetMissionCode driver command. Mission codes linked to a train are kept when a session is saved and later restored. Several trains may be assigned simultaneously the same mission codes.

After defining and setting train mission codes for a train, you can then select while editing the Mission code Manager rule any existing interlocking tower and path and assign to the path any mission code and options. Later in driver mode, when a train with mission codes, will reach the entry signal, the Mission Code Manager Rule will be called as a listener for the interlocking tower, and will activate a path at this entry signal matching one of the the mission codes currently assigned to the train.

You may look at mission codes as a set of keys assigned to a train. When searching for a path at an entry signal, MissionCode Manager will only look to paths matching one of the keys assigned to the train. Only paths with matching mission code will be used for a train when searching for a path at an entry signal.

=== Train Mission Codes : in practice how to define them ===

To use train mission code features in a session, you need first to add to your session rules the Mission Code Manager rule, then edit the rule and define your list of available train mission code strings for this session.
When editing the MissionCode Manager rule, the first page displayed will show the list of all available mission code strings already defined and will offer to add some new mission code, to rename or clone or delete existing ones.

[[File:Help-missioncodemanager-rule-img02.png]]

In the example above, four mission codes strings (CentralToSouth,NorthToSouth,SouthToCentral,SouthToNorth) have been defined for the current session.

This page enables also to set the default global values for Mission Code Manager options like default follow path depth, default follow path option, follow path search distance, exit signal track check mode, unique path select mode option, process all trains option and debugging mode which will be detailed later below in their respective section. The page includes also links to copy MCM data to the common clipboard and to paste MCM data from the common clipboard in order to enable copying MCM data between sessions. It has also a link repair mission codes from internal data that enables to try to recreate missing mission codes from internal MCM data if you have by mistake deleted some still needed mission codes.

=== Train Mission Codes : how to assign a code to a train ===

Now that we have defined the mission codes to be used, the next step is to assign mission codes to trains.

There are now two methods to assign mission codes to train. you can either use the trains tab while editing Mission Code Manager Rule or you can use one between several driver commands to assign mission code at run time.

==== Using the trains tab in Mission Code Manager rule ====

[[File:Help-missioncodemanager-rule-img06A.png]]

As you can see in the above example, the trains tab in Mission Code Manager Rule will list all the trains available in your session ( it is in fact a copy of the list of all trains defined in the driver setup rule ) and the mission codes assigned to it. Using the add mcode and remove mcode links, you can add or suppress a mission code in the set of mission codes assigned to this train.

When the session will start, the MissionCode Manager rule will assign all the mission codes that were defined to each of the available train.

This method is the easiest way to assign mission codes to a train as it does not need to use any driver command in schedules.

==== Using driver commands ====

The other method is to use driver commands to assign mission codes to a train.

SetMissionCode driver command ( <kuid:61392:8201> ) will first clear any existing mission codes set assigned to the current train and will then assign the mission code selected in the menu to the current train.
AddMissionCode driver command ( <kuid:61392:8203> ) will add the mission code selected in the menu to the current train mission codes set.
RemoveMissionCode driver command ( <kuid:61392:8204> ) will do the reverse and will suppress the mission code selected in the menu from the current train mission codes set if the mission code had been previously added to the set.

In order to use these commands, the first step is to enable SetMissionCode, AddMissionCode and RemoveMissionCode driver commands for the current session. To do so, you just need to edit the DriverCommands rule under surveyor and tick the SetMissionCode, AddMissionCode and RemoveMissionCode driver commands.

[[File:Help-missioncodemanager-rule-img06.png]]

[[File:Help-missioncodemanager-rule-img07.png]]

Then you can now select in any driver order bar the SetMissionCode driver command (or AddMissionCode or RemoveMissionCode ) and choose the mission code to assign to the current driver train. You can also do the same in the DriverSetup rule to insert SetMissionCode driver command in a scheduled driver order bar.

[[File:Help-missioncodemanager-rule-img08.png]]

=== Train Mission Codes : how to assign a code to an interlocking tower and path ===

The last step is now to assign mission codes to Interlocking Tower Paths.

In order to do so, just select the interlocking tower page by clicking on the interlocking towers tab. Mission Code Manager will now display the list of all available interlocking towers in the current session :

[[File:Help-missioncodemanager-rule-img03.png]]

Then to select an Interlocking Tower Path in an Interlocking Tower, just click on the interlocking tower view paths link you want to display. It will then display the Interlocking Paths page with all the defined paths in the selected Interlocking Tower.

''Since release 28, this page has also now a link to globally enable or disable the path auto assignment standard routine which is automatically called when a train is on approach of a signal at 0.5 mile. With the option disabled no path auto assignment is done for train with mission codes and explicit path assignment must be done using ITSetPathXXX, ITMCAssignNextPath, path trigger or follow path options
''

[[File:Help-missioncodemanager-rule-img04.png]]

And finally, to display, add or suppress mission codes assigned to a path, just click on the view details link for the path you want to look at.

[[File:Help-missioncodemanager-rule-img05.png]]

On this path details page, you have some links to add new mission code to the current selected path or to remove some already assigned mission codes.

It is also possible to define a priority between 1, 2 and 3 for a path mission code assignment. This priority will be used when the Mission Code Manager has to activate a path for a train at an entry signal. If several paths are available at the entry signal and the mission code is valid for several of these paths, the mission code manager will try first to activate an eligible path (available path with mission code assigned to this path) with mission code priority 1, then 2 and last 3. If several paths are eligible for a mission code at the same priority level, the mission code manager will try to activate a randomly chosen path between paths with same priority.
This feature may be usefull for passengers train at a station or goods train at a yard : mission code manager will first try to activate one of the eligible paths with priority 1. If none are activable, it will then search for paths with priority 2 and then priority 3. Using adequate priorities, you can send a passenger train on a path to a preferred platform, with the opportunity to send the train to another platform using another path if the first one is already occupied.

It is also possible on this page to edit the auto assign AI flag and auto assign flag for the current path.

The option follow path is an option by default set to none, that can be set to either "on path activation" or to "on train entering path". When the option is set to "on path activation", when the current path will become active, Mission code manager will search forward for the next entry signal after the current path exit signal, and will try to activate a new path (follow path) for the current train at this new entry signal using the same assignment process than above. With the on train entering path, it is only when the current train enters the current path (leaves the current path entry signal) that the follow path at the next entry signal is searched. Using these options you can in fact chain paths activation following either the activation or the progression of the train in the previous paths.<br>

You can set a global default value for the follow path option, which can be overridden by a default value at the path level, which can also be overridden at the mission code level.

Chaining path activation by using follow path option is limited by the current follow path depth. The follow path depth defines the maximum number of paths activated but not entered that a train can have. If a follow path activation is requested but the follow path depth is exceeded, the follow path activation will be delayed until the current number of paths activated but not entered will decrease under the follow path depth. The follow path request is not lost but is only delayed.

There is a global default follow path depth which is set on the initial mission code page. This value can be overridden at the mission code level by entering another value for any mission code on the initial mission code page.

There is another way to add/remove mission code eligibility for a path. This can be done using the "view paths" link for a specific mission code on the initial mission code page. This link will display all the available paths in all towers :

[[File:Help-missioncodemanager-rule-imgallpaths.png]]

The paths displayed in low green are path that are unique (only path available) at their entry signal and are by default considered as eligible for any mission codes without the need to configure anything. Paths displayed in high green are paths that have been explicitly made eligible for the selected mission code by validating the selected mission code for the path. Paths displayed in low grey are paths not eligible for the currently selected mission code.

On each path line, depending on its current status, you will find either a "add selected mcode to path config" or "suppress selected mcode from path config" to add or suppress mission code eligibility for the path. By listing for a selected mission code all paths eligibility, it is easy to have a global value of all the paths already enabled for a mission code and to update the configuration if needed. The view details link remains available also on this page to switch to a path view of all eligible mission codes for entering other specific parameters like priority and follow path option.

The page includes at its beginning an option to display all paths or only eligible paths and a tower name filter to enable to tailor this page to your need. To add new mission code eligibility to a path currently not eligible, of course you need to have the display option set to all paths and not limited to eligible paths.

=== Train Mission Codes auto path assignment : how it works ? ===

And now that you have defined your mission codes, assigned them to trains and to specific interlocking tower paths, how all these will work together for path assignment.

Quite simple: when a train approach an entry signal, then interlocking tower will call the mission code manager rule as a listener to assign a path for the current train.

The mission code manager will look at the incoming train and retrieve all the mission codes assigned to the train. If the train has no mission code, it will return to the interlocking tower that it does not support the train and the normal interlocking tower processing will be done for this train with no mission codes. But for a train with some mission codes, the mission code manager will return to the interlocking tower that it takes care of the current train path and that no further processing is needed.

Then the mission code manager will look at all the available paths at the current entry signal and will extract only the list of all available paths at this entry signal eligible for one of the current train mission codes set. A path is eligible for a train only if there is a matching mission code in the list of the path supported mission codes.

To choose the target path, Mission Code Manager will then look in this list of eligible paths for paths with matching mission code at priority 1 then 2 then 3 and will try to assign a path not occupied in the priority order. It is smart enough that if there is only one path available at an entry signal, it will assign this unique path even if no mission code has been assigned to it. If there are several paths available and no paths are eligible the train will remain stuck at the entry signal.

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

So when you have configured all your mission codes, trains and paths assignment, you only need to run your session and the paths will be auto assigned based on one of the current train mission codes and following your paths mission codes assignment configuration defined in Mission Code Manager.

''Since release 60, there is a new global parameter available on the initial mission code page : process all trains option. By default, it is set to "do not process trains without mission code" but you can change it to "process trains without mission code using implicit value". With this option activated, there is no longer any train without any mission code. First trains with no current mission code are considered as having an implicit mission code #NONE and all trains receive also another implicit mission code #TRP1 or #TPR2 or #TPR3 based on their current trainz priority. By making path eligible or not to these implicit mission codes #NONE, #TPR1, #TPR2,#TPR3 you can use the MCM routing facility to auto select paths for trains without any explicit mission code.''

=== Train Mission Codes auto path assignment : and what are path triggers ? ===

PathTriggers are standard trackmarks or triggers that help to assign path following the method above when the standard assignment routine called when the train approaches the entry signal is not convenient. PathTrigger enables to do the same assignment process, but earlier or later than with the standard routine called when the train approaches then entry signal (about 1 mile before reaching it). It enables also to assign manual paths (paths with the AI auto assign and Player auto assign flags not set).

To assign paths earlier, you need only to position a trackmark or trigger on the track to the entry signal before the 1 mile standard distance for path assignment. You then need to register in the pathtrigger tab of the mission code manager rule the path trigger you are using. And that's all. When a train will reach a registered path trigger, MissionCode Manager will be called, will look forward for the entry signal along a distance of maximum 10 km and when the next entry signal is found it will immediately launch the auto path assignment process as if the train had already reached the 1 mile distance to the signal.
This way you can fire some early auto path assignment before the standard signal reached routine is called.

Path assignment when fired by a PathTrigger is a little different from standard path assignment. As with standard assignment, it will first search for paths with AI auto assign flag or Player auto assign flag set for AI trains or Player train, but if it does not find any available paths, it will then do a second search where it will also look to manual paths (paths with no AI auto assign or Player auto assign flags set). This dual step search is mainly done to enable late path assignment. To do some late path assignment (later than the standard method called at 1 mile from the entry signal) , you need to only use manual paths at the entry signal. When the standard routine will be called at 1 mile from the entry signal, it will find no available paths and so will not assign any path for the train. When later, the train will reach a path trigger, the process will restart, will still find no available paths with AI auto assign or Player auto assign flags set, but it will then look to manual paths and will then assign a path between the eligible manual paths at the entry signal. Using this feature, you can also do some late auto path assignment but only if at the entry signal there are no paths with the AI or Player flag set.

[[File:Help-missioncodemanager-rule-img09.png]]

PathTriggers are optional and need to be used only when the standard path auto assignment routine fired when a train approaches an entry signal is not convenient for your session. Most of my sessions using Mission Code Manager do not have any path trigger, but sometimes in some specific cases path trigger may be very usefull for some specific train behavior.

There is also in the package a driver command ITMCAssignNextPath ( <kuid:61392:8202> ) that will do the same processing as a path trigger on the current train when the command is executed. This driver command may be usefull for train stopped at a platform or a yard to start some auto path assignment process chain with follow on options.

''Since release 60, pathtriggers are also supported by enhanced interlocking towers. This has needed a few adaptations to already existing MCM pathtriggers. Now a pathtrigger can either be defined at the EIT level or at the MCM level. Pathtriggers defined at the EIT level are called EIT pathtriggers and works both for EIT and for MCM. Pathtriggers defined only in MCM are called MCM pathtriggers and works only in MCM. You need to use the IT manager to manage EIT pathtriggers and you need to use MCM to manage MCM only pathtriggers. MCM path trigger page will now list both types of path triggers so that you can see all the path triggers used in your session and at which level.''

=== Train Mission codes : some other miscellaneous features ===

Another usefull feature is on the interlocking paths list display. The interlocking paths are displayed in high green when the current selected mission code has been added to the interlocking path. It is displayed in low green, when there is only one path available at the entry signal, and in this case Mission code Manager is smart enough to assign the unique path at run time under driver for any mission codes. And the path name is displayed in grey, when several paths are available at the entry signal but the current selected mission code has not been assigned to this path. On the example above, SouthV4 and SouthV5 have selected mission code MONGAR in their mission codes assignments. SouthV2 is not eligible for mission code MONGAR. And V1South, v2South, v3South, v4South, V5South have all a unique path defined at their entry signal that will be selected for any mission code train. This path list page screen supports filtering on both interlocking tower and mission code. You can also select "no filtering" for the interlocking tower, and all the available interlocking towers and paths will be displayed with the high green, low green or grey color and it can be usefull to check for a mission code what are the paths eligible and not.

I think that it is all what is needed to use Train Mission code.
I hope you will enjoy this new rule to help you for interlocking tower path assignment.
And do not hesitate to post in the forum if you need some help or only to make some some comments.

Regards.
Pierre GUY (61392)

[[Category:Help|MissionCode Manager]]
[[Category:Rules]]
{{FUN-bot}}

MissionCodes Manager

2019-02-17T10:27:00Z

Pguy: /* Train Mission Codes auto path assignment : and what are path triggers ? */

{{FUN-top}}

===Mission Code Manager rule===
[[File:Help-missioncodemanager-rule-img01.png]]

'''MissionCode Manager''' is a rule ( <kuid:61392:8200> ) which enables to add, edit and manage Mission Code strings, which can be assigned to trains and can be used to auto select paths in interlocking towers to route the trains to their destination.

''This page has been updated to support new features brought with version 60 of Mission code Manager and associated stuff.

=== Train Mission Codes : what is it and for which purpose ?===

A train mission code is any string choosen in a list of arbitrary mission code strings that needs first to be defined by editing the MissionCode Manager Rule (<kuid2:61392:8200>) under surveyor.
After defining all the train mission codes you will use in your session, you can assign one or several train mission codes to any available train using either the trains tab while editing MissionCode Manager rule, or using the driver command SetMissionCode ( <kuid:61392:8201> ) to assign the first mission code to your current train and AddMissionCode ( <kuid:61392:8203> ) to add another mission code to the current train.
All trains, by default have no mission code assigned but may be assigned one or several train mission codes. The mission codes will stay linked to the train until new mission codes are assigned to the train or the mission codes are cleared using also the SetMissionCode driver command. Mission codes linked to a train are kept when a session is saved and later restored. Several trains may be assigned simultaneously the same mission codes.

After defining and setting train mission codes for a train, you can then select while editing the Mission code Manager rule any existing interlocking tower and path and assign to the path any mission code and options. Later in driver mode, when a train with mission codes, will reach the entry signal, the Mission Code Manager Rule will be called as a listener for the interlocking tower, and will activate a path at this entry signal matching one of the the mission codes currently assigned to the train.

You may look at mission codes as a set of keys assigned to a train. When searching for a path at an entry signal, MissionCode Manager will only look to paths matching one of the keys assigned to the train. Only paths with matching mission code will be used for a train when searching for a path at an entry signal.

=== Train Mission Codes : in practice how to define them ===

To use train mission code features in a session, you need first to add to your session rules the Mission Code Manager rule, then edit the rule and define your list of available train mission code strings for this session.
When editing the MissionCode Manager rule, the first page displayed will show the list of all available mission code strings already defined and will offer to add some new mission code, to rename or clone or delete existing ones.

[[File:Help-missioncodemanager-rule-img02.png]]

In the example above, four mission codes strings (CentralToSouth,NorthToSouth,SouthToCentral,SouthToNorth) have been defined for the current session.

This page enables also to set the default global values for Mission Code Manager options like default follow path depth, default follow path option, follow path search distance, exit signal track check mode, unique path select mode option, process all trains option and debugging mode which will be detailed later below in their respective section. The page includes also links to copy MCM data to the common clipboard and to paste MCM data from the common clipboard in order to enable copying MCM data between sessions. It has also a link repair mission codes from internal data that enables to try to recreate missing mission codes from internal MCM data if you have by mistake deleted some still needed mission codes.

=== Train Mission Codes : how to assign a code to a train ===

Now that we have defined the mission codes to be used, the next step is to assign mission codes to trains.

There are now two methods to assign mission codes to train. you can either use the trains tab while editing Mission Code Manager Rule or you can use one between several driver commands to assign mission code at run time.

==== Using the trains tab in Mission Code Manager rule ====

[[File:Help-missioncodemanager-rule-img06A.png]]

As you can see in the above example, the trains tab in Mission Code Manager Rule will list all the trains available in your session ( it is in fact a copy of the list of all trains defined in the driver setup rule ) and the mission codes assigned to it. Using the add mcode and remove mcode links, you can add or suppress a mission code in the set of mission codes assigned to this train.

When the session will start, the MissionCode Manager rule will assign all the mission codes that were defined to each of the available train.

This method is the easiest way to assign mission codes to a train as it does not need to use any driver command in schedules.

==== Using driver commands ====

The other method is to use driver commands to assign mission codes to a train.

SetMissionCode driver command ( <kuid:61392:8201> ) will first clear any existing mission codes set assigned to the current train and will then assign the mission code selected in the menu to the current train.
AddMissionCode driver command ( <kuid:61392:8203> ) will add the mission code selected in the menu to the current train mission codes set.
RemoveMissionCode driver command ( <kuid:61392:8204> ) will do the reverse and will suppress the mission code selected in the menu from the current train mission codes set if the mission code had been previously added to the set.

In order to use these commands, the first step is to enable SetMissionCode, AddMissionCode and RemoveMissionCode driver commands for the current session. To do so, you just need to edit the DriverCommands rule under surveyor and tick the SetMissionCode, AddMissionCode and RemoveMissionCode driver commands.

[[File:Help-missioncodemanager-rule-img06.png]]

[[File:Help-missioncodemanager-rule-img07.png]]

Then you can now select in any driver order bar the SetMissionCode driver command (or AddMissionCode or RemoveMissionCode ) and choose the mission code to assign to the current driver train. You can also do the same in the DriverSetup rule to insert SetMissionCode driver command in a scheduled driver order bar.

[[File:Help-missioncodemanager-rule-img08.png]]

=== Train Mission Codes : how to assign a code to an interlocking tower and path ===

The last step is now to assign mission codes to Interlocking Tower Paths.

In order to do so, just select the interlocking tower page by clicking on the interlocking towers tab. Mission Code Manager will now display the list of all available interlocking towers in the current session :

[[File:Help-missioncodemanager-rule-img03.png]]

Then to select an Interlocking Tower Path in an Interlocking Tower, just click on the interlocking tower view paths link you want to display. It will then display the Interlocking Paths page with all the defined paths in the selected Interlocking Tower.

''Since release 28, this page has also now a link to globally enable or disable the path auto assignment standard routine which is automatically called when a train is on approach of a signal at 0.5 mile. With the option disabled no path auto assignment is done for train with mission codes and explicit path assignment must be done using ITSetPathXXX, ITMCAssignNextPath, path trigger or follow path options
''

[[File:Help-missioncodemanager-rule-img04.png]]

And finally, to display, add or suppress mission codes assigned to a path, just click on the view details link for the path you want to look at.

[[File:Help-missioncodemanager-rule-img05.png]]

On this path details page, you have some links to add new mission code to the current selected path or to remove some already assigned mission codes.

It is also possible to define a priority between 1, 2 and 3 for a path mission code assignment. This priority will be used when the Mission Code Manager has to activate a path for a train at an entry signal. If several paths are available at the entry signal and the mission code is valid for several of these paths, the mission code manager will try first to activate an eligible path (available path with mission code assigned to this path) with mission code priority 1, then 2 and last 3. If several paths are eligible for a mission code at the same priority level, the mission code manager will try to activate a randomly chosen path between paths with same priority.
This feature may be usefull for passengers train at a station or goods train at a yard : mission code manager will first try to activate one of the eligible paths with priority 1. If none are activable, it will then search for paths with priority 2 and then priority 3. Using adequate priorities, you can send a passenger train on a path to a preferred platform, with the opportunity to send the train to another platform using another path if the first one is already occupied.

It is also possible on this page to edit the auto assign AI flag and auto assign flag for the current path.

The option follow path is an option by default set to none, that can be set to either "on path activation" or to "on train entering path". When the option is set to "on path activation", when the current path will become active, Mission code manager will search forward for the next entry signal after the current path exit signal, and will try to activate a new path (follow path) for the current train at this new entry signal using the same assignment process than above. With the on train entering path, it is only when the current train enters the current path (leaves the current path entry signal) that the follow path at the next entry signal is searched. Using these options you can in fact chain paths activation following either the activation or the progression of the train in the previous paths.<br>

You can set a global default value for the follow path option, which can be overridden by a default value at the path level, which can also be overridden at the mission code level.

Chaining path activation by using follow path option is limited by the current follow path depth. The follow path depth defines the maximum number of paths activated but not entered that a train can have. If a follow path activation is requested but the follow path depth is exceeded, the follow path activation will be delayed until the current number of paths activated but not entered will decrease under the follow path depth. The follow path request is not lost but is only delayed.

There is a global default follow path depth which is set on the initial mission code page. This value can be overridden at the mission code level by entering another value for any mission code on the initial mission code page.

There is another way to add/remove mission code eligibility for a path. This can be done using the "view paths" link for a specific mission code on the initial mission code page. This link will display all the available paths in all towers :

[[File:Help-missioncodemanager-rule-imgallpaths.png]]

The paths displayed in low green are path that are unique (only path available) at their entry signal and are by default considered as eligible for any mission codes without the need to configure anything. Paths displayed in high green are paths that have been explicitly made eligible for the selected mission code by validating the selected mission code for the path. Paths displayed in low grey are paths not eligible for the currently selected mission code.

On each path line, depending on its current status, you will find either a "add selected mcode to path config" or "suppress selected mcode from path config" to add or suppress mission code eligibility for the path. By listing for a selected mission code all paths eligibility, it is easy to have a global value of all the paths already enabled for a mission code and to update the configuration if needed. The view details link remains available also on this page to switch to a path view of all eligible mission codes for entering other specific parameters like priority and follow path option.

The page includes at its beginning an option to display all paths or only eligible paths and a tower name filter to enable to tailor this page to your need. To add new mission code eligibility to a path currently not eligible, of course you need to have the display option set to all paths and not limited to eligible paths.

=== Train Mission Codes auto path assignment : how it works ? ===

And now that you have defined your mission codes, assigned them to trains and to specific interlocking tower paths, how all these will work together for path assignment.

Quite simple: when a train approach an entry signal, then interlocking tower will call the mission code manager rule as a listener to assign a path for the current train.

The mission code manager will look at the incoming train and retrieve all the mission codes assigned to the train. If the train has no mission code, it will return to the interlocking tower that it does not support the train and the normal interlocking tower processing will be done for this train with no mission codes. But for a train with some mission codes, the mission code manager will return to the interlocking tower that it takes care of the current train path and that no further processing is needed.

Then the mission code manager will look at all the available paths at the current entry signal and will extract only the list of all available paths at this entry signal eligible for one of the current train mission codes set. A path is eligible for a train only if there is a matching mission code in the list of the path supported mission codes.

To choose the target path, Mission Code Manager will then look in this list of eligible paths for paths with matching mission code at priority 1 then 2 then 3 and will try to assign a path not occupied in the priority order. It is smart enough that if there is only one path available at an entry signal, it will assign this unique path even if no mission code has been assigned to it. If there are several paths available and no paths are eligible the train will remain stuck at the entry signal.

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

So when you have configured all your mission codes, trains and paths assignment, you only need to run your session and the paths will be auto assigned based on one of the current train mission codes and following your paths mission codes assignment configuration defined in Mission Code Manager.

''Since release 60, there is a new global parameter available on the initial mission code page : process all trains option. By default, it is set to "do not process trains without mission code" but you can change it to "process trains without mission code using implicit value". With this option activated, there is no longer any train without any mission code. First trains with no current mission code are considered as having an implicit mission code #NONE and all trains receive also another implicit mission code #TRP1 or #TPR2 or #TPR3 based on their current trainz priority. By making path eligible or not to these implicit mission codes #NONE, #TPR1, #TPR2,#TPR3 you can use the MCM routing facility to auto select paths for trains without any explicit mission code.''

=== Train Mission Codes auto path assignment : and what are path triggers ? ===

PathTriggers are standard trackmarks or triggers that help to assign path following the method above when the standard assignment routine called when the train approaches the entry signal is not convenient. PathTrigger enables to do the same assignment process, but earlier or later than with the standard routine called when the train approaches then entry signal (about 1 mile before reaching it). It enables also to assign manual paths (paths with the AI auto assign and Player auto assign flags not set).

To assign paths earlier, you need only to position a trackmark or trigger on the track to the entry signal before the 1 mile standard distance for path assignment. You then need to register in the pathtrigger tab of the mission code manager rule the path trigger you are using. And that's all. When a train will reach a registered path trigger, MissionCode Manager will be called, will look forward for the entry signal along a distance of maximum 10 km and when the next entry signal is found it will immediately launch the auto path assignment process as if the train had already reached the 1 mile distance to the signal.
This way you can fire some early auto path assignment before the standard signal reached routine is called.

Path assignment when fired by a PathTrigger is a little different from standard path assignment. As with standard assignment, it will first search for paths with AI auto assign flag or Player auto assign flag set for AI trains or Player train, but if it does not find any available paths, it will then do a second search where it will also look to manual paths (paths with no AI auto assign or Player auto assign flags set). This dual step search is mainly done to enable late path assignment. To do some late path assignment (later than the standard method called at 1 mile from the entry signal) , you need to only use manual paths at the entry signal. When the standard routine will be called at 1 mile from the entry signal, it will find no available paths and so will not assign any path for the train. When later, the train will reach a path trigger, the process will restart, will still find no available paths with AI auto assign or Player auto assign flags set, but it will then look to manual paths and will then assign a path between the eligible manual paths at the entry signal. Using this feature, you can also do some late auto path assignment but only if at the entry signal there are no paths with the AI or Player flag set.

[[File:Help-missioncodemanager-rule-img09.png]]

PathTriggers are optional and need to be used only when the standard path auto assignment routine fired when a train approaches an entry signal is not convenient for your session. Most of my sessions using Mission Code Manager do not have any path trigger, but sometimes in some specific cases path trigger may be very usefull for some specific train behavior.

There is also in the package a driver command ITMCAssignNextPath ( <kuid:61392:8202> ) that will do the same processing as a path trigger on the current train when the command is executed. This driver command may be usefull for train stopped at a platform or a yard to start some auto path assignment process chain with follow on options.

''Since release 60, pathtriggers are also supported by enhanced interlocking towers. This has needed a few adaptations to already existing MCM pathtriggers. Now a pathtrigger can either be defined at the EIT level or at the MCM level. Pathtriggers defined at the EIT level are called EIT pathtriggers and works both for EIT and for MCM. Pathtriggers defined only in MCM are called MCM pathtriggers and works only in MCM. You need to use the IT manager to manage EIT pathtriggers and you need to use MCM to manage MCM only pathtriggers. MCM path trigger page will now list both types of path triggers so that you can see all the path triggers used in your session and at which level.""

=== Train Mission codes : some other miscellaneous features ===

Another usefull feature is on the interlocking paths list display. The interlocking paths are displayed in high green when the current selected mission code has been added to the interlocking path. It is displayed in low green, when there is only one path available at the entry signal, and in this case Mission code Manager is smart enough to assign the unique path at run time under driver for any mission codes. And the path name is displayed in grey, when several paths are available at the entry signal but the current selected mission code has not been assigned to this path. On the example above, SouthV4 and SouthV5 have selected mission code MONGAR in their mission codes assignments. SouthV2 is not eligible for mission code MONGAR. And V1South, v2South, v3South, v4South, V5South have all a unique path defined at their entry signal that will be selected for any mission code train. This path list page screen supports filtering on both interlocking tower and mission code. You can also select "no filtering" for the interlocking tower, and all the available interlocking towers and paths will be displayed with the high green, low green or grey color and it can be usefull to check for a mission code what are the paths eligible and not.

I think that it is all what is needed to use Train Mission code.
I hope you will enjoy this new rule to help you for interlocking tower path assignment.
And do not hesitate to post in the forum if you need some help or only to make some some comments.

Regards.
Pierre GUY (61392)

[[Category:Help|MissionCode Manager]]
[[Category:Rules]]
{{FUN-bot}}

MissionCodes Manager

2019-02-17T10:19:00Z

Pguy: /* Train Mission Codes auto path assignment : how it works ? */

{{FUN-top}}

===Mission Code Manager rule===
[[File:Help-missioncodemanager-rule-img01.png]]

'''MissionCode Manager''' is a rule ( <kuid:61392:8200> ) which enables to add, edit and manage Mission Code strings, which can be assigned to trains and can be used to auto select paths in interlocking towers to route the trains to their destination.

''This page has been updated to support new features brought with version 60 of Mission code Manager and associated stuff.

=== Train Mission Codes : what is it and for which purpose ?===

A train mission code is any string choosen in a list of arbitrary mission code strings that needs first to be defined by editing the MissionCode Manager Rule (<kuid2:61392:8200>) under surveyor.
After defining all the train mission codes you will use in your session, you can assign one or several train mission codes to any available train using either the trains tab while editing MissionCode Manager rule, or using the driver command SetMissionCode ( <kuid:61392:8201> ) to assign the first mission code to your current train and AddMissionCode ( <kuid:61392:8203> ) to add another mission code to the current train.
All trains, by default have no mission code assigned but may be assigned one or several train mission codes. The mission codes will stay linked to the train until new mission codes are assigned to the train or the mission codes are cleared using also the SetMissionCode driver command. Mission codes linked to a train are kept when a session is saved and later restored. Several trains may be assigned simultaneously the same mission codes.

After defining and setting train mission codes for a train, you can then select while editing the Mission code Manager rule any existing interlocking tower and path and assign to the path any mission code and options. Later in driver mode, when a train with mission codes, will reach the entry signal, the Mission Code Manager Rule will be called as a listener for the interlocking tower, and will activate a path at this entry signal matching one of the the mission codes currently assigned to the train.

You may look at mission codes as a set of keys assigned to a train. When searching for a path at an entry signal, MissionCode Manager will only look to paths matching one of the keys assigned to the train. Only paths with matching mission code will be used for a train when searching for a path at an entry signal.

=== Train Mission Codes : in practice how to define them ===

To use train mission code features in a session, you need first to add to your session rules the Mission Code Manager rule, then edit the rule and define your list of available train mission code strings for this session.
When editing the MissionCode Manager rule, the first page displayed will show the list of all available mission code strings already defined and will offer to add some new mission code, to rename or clone or delete existing ones.

[[File:Help-missioncodemanager-rule-img02.png]]

In the example above, four mission codes strings (CentralToSouth,NorthToSouth,SouthToCentral,SouthToNorth) have been defined for the current session.

This page enables also to set the default global values for Mission Code Manager options like default follow path depth, default follow path option, follow path search distance, exit signal track check mode, unique path select mode option, process all trains option and debugging mode which will be detailed later below in their respective section. The page includes also links to copy MCM data to the common clipboard and to paste MCM data from the common clipboard in order to enable copying MCM data between sessions. It has also a link repair mission codes from internal data that enables to try to recreate missing mission codes from internal MCM data if you have by mistake deleted some still needed mission codes.

=== Train Mission Codes : how to assign a code to a train ===

Now that we have defined the mission codes to be used, the next step is to assign mission codes to trains.

There are now two methods to assign mission codes to train. you can either use the trains tab while editing Mission Code Manager Rule or you can use one between several driver commands to assign mission code at run time.

==== Using the trains tab in Mission Code Manager rule ====

[[File:Help-missioncodemanager-rule-img06A.png]]

As you can see in the above example, the trains tab in Mission Code Manager Rule will list all the trains available in your session ( it is in fact a copy of the list of all trains defined in the driver setup rule ) and the mission codes assigned to it. Using the add mcode and remove mcode links, you can add or suppress a mission code in the set of mission codes assigned to this train.

When the session will start, the MissionCode Manager rule will assign all the mission codes that were defined to each of the available train.

This method is the easiest way to assign mission codes to a train as it does not need to use any driver command in schedules.

==== Using driver commands ====

The other method is to use driver commands to assign mission codes to a train.

SetMissionCode driver command ( <kuid:61392:8201> ) will first clear any existing mission codes set assigned to the current train and will then assign the mission code selected in the menu to the current train.
AddMissionCode driver command ( <kuid:61392:8203> ) will add the mission code selected in the menu to the current train mission codes set.
RemoveMissionCode driver command ( <kuid:61392:8204> ) will do the reverse and will suppress the mission code selected in the menu from the current train mission codes set if the mission code had been previously added to the set.

In order to use these commands, the first step is to enable SetMissionCode, AddMissionCode and RemoveMissionCode driver commands for the current session. To do so, you just need to edit the DriverCommands rule under surveyor and tick the SetMissionCode, AddMissionCode and RemoveMissionCode driver commands.

[[File:Help-missioncodemanager-rule-img06.png]]

[[File:Help-missioncodemanager-rule-img07.png]]

Then you can now select in any driver order bar the SetMissionCode driver command (or AddMissionCode or RemoveMissionCode ) and choose the mission code to assign to the current driver train. You can also do the same in the DriverSetup rule to insert SetMissionCode driver command in a scheduled driver order bar.

[[File:Help-missioncodemanager-rule-img08.png]]

=== Train Mission Codes : how to assign a code to an interlocking tower and path ===

The last step is now to assign mission codes to Interlocking Tower Paths.

In order to do so, just select the interlocking tower page by clicking on the interlocking towers tab. Mission Code Manager will now display the list of all available interlocking towers in the current session :

[[File:Help-missioncodemanager-rule-img03.png]]

Then to select an Interlocking Tower Path in an Interlocking Tower, just click on the interlocking tower view paths link you want to display. It will then display the Interlocking Paths page with all the defined paths in the selected Interlocking Tower.

''Since release 28, this page has also now a link to globally enable or disable the path auto assignment standard routine which is automatically called when a train is on approach of a signal at 0.5 mile. With the option disabled no path auto assignment is done for train with mission codes and explicit path assignment must be done using ITSetPathXXX, ITMCAssignNextPath, path trigger or follow path options
''

[[File:Help-missioncodemanager-rule-img04.png]]

And finally, to display, add or suppress mission codes assigned to a path, just click on the view details link for the path you want to look at.

[[File:Help-missioncodemanager-rule-img05.png]]

On this path details page, you have some links to add new mission code to the current selected path or to remove some already assigned mission codes.

It is also possible to define a priority between 1, 2 and 3 for a path mission code assignment. This priority will be used when the Mission Code Manager has to activate a path for a train at an entry signal. If several paths are available at the entry signal and the mission code is valid for several of these paths, the mission code manager will try first to activate an eligible path (available path with mission code assigned to this path) with mission code priority 1, then 2 and last 3. If several paths are eligible for a mission code at the same priority level, the mission code manager will try to activate a randomly chosen path between paths with same priority.
This feature may be usefull for passengers train at a station or goods train at a yard : mission code manager will first try to activate one of the eligible paths with priority 1. If none are activable, it will then search for paths with priority 2 and then priority 3. Using adequate priorities, you can send a passenger train on a path to a preferred platform, with the opportunity to send the train to another platform using another path if the first one is already occupied.

It is also possible on this page to edit the auto assign AI flag and auto assign flag for the current path.

The option follow path is an option by default set to none, that can be set to either "on path activation" or to "on train entering path". When the option is set to "on path activation", when the current path will become active, Mission code manager will search forward for the next entry signal after the current path exit signal, and will try to activate a new path (follow path) for the current train at this new entry signal using the same assignment process than above. With the on train entering path, it is only when the current train enters the current path (leaves the current path entry signal) that the follow path at the next entry signal is searched. Using these options you can in fact chain paths activation following either the activation or the progression of the train in the previous paths.<br>

You can set a global default value for the follow path option, which can be overridden by a default value at the path level, which can also be overridden at the mission code level.

Chaining path activation by using follow path option is limited by the current follow path depth. The follow path depth defines the maximum number of paths activated but not entered that a train can have. If a follow path activation is requested but the follow path depth is exceeded, the follow path activation will be delayed until the current number of paths activated but not entered will decrease under the follow path depth. The follow path request is not lost but is only delayed.

There is a global default follow path depth which is set on the initial mission code page. This value can be overridden at the mission code level by entering another value for any mission code on the initial mission code page.

There is another way to add/remove mission code eligibility for a path. This can be done using the "view paths" link for a specific mission code on the initial mission code page. This link will display all the available paths in all towers :

[[File:Help-missioncodemanager-rule-imgallpaths.png]]

The paths displayed in low green are path that are unique (only path available) at their entry signal and are by default considered as eligible for any mission codes without the need to configure anything. Paths displayed in high green are paths that have been explicitly made eligible for the selected mission code by validating the selected mission code for the path. Paths displayed in low grey are paths not eligible for the currently selected mission code.

On each path line, depending on its current status, you will find either a "add selected mcode to path config" or "suppress selected mcode from path config" to add or suppress mission code eligibility for the path. By listing for a selected mission code all paths eligibility, it is easy to have a global value of all the paths already enabled for a mission code and to update the configuration if needed. The view details link remains available also on this page to switch to a path view of all eligible mission codes for entering other specific parameters like priority and follow path option.

The page includes at its beginning an option to display all paths or only eligible paths and a tower name filter to enable to tailor this page to your need. To add new mission code eligibility to a path currently not eligible, of course you need to have the display option set to all paths and not limited to eligible paths.

=== Train Mission Codes auto path assignment : how it works ? ===

And now that you have defined your mission codes, assigned them to trains and to specific interlocking tower paths, how all these will work together for path assignment.

Quite simple: when a train approach an entry signal, then interlocking tower will call the mission code manager rule as a listener to assign a path for the current train.

The mission code manager will look at the incoming train and retrieve all the mission codes assigned to the train. If the train has no mission code, it will return to the interlocking tower that it does not support the train and the normal interlocking tower processing will be done for this train with no mission codes. But for a train with some mission codes, the mission code manager will return to the interlocking tower that it takes care of the current train path and that no further processing is needed.

Then the mission code manager will look at all the available paths at the current entry signal and will extract only the list of all available paths at this entry signal eligible for one of the current train mission codes set. A path is eligible for a train only if there is a matching mission code in the list of the path supported mission codes.

To choose the target path, Mission Code Manager will then look in this list of eligible paths for paths with matching mission code at priority 1 then 2 then 3 and will try to assign a path not occupied in the priority order. It is smart enough that if there is only one path available at an entry signal, it will assign this unique path even if no mission code has been assigned to it. If there are several paths available and no paths are eligible the train will remain stuck at the entry signal.

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

So when you have configured all your mission codes, trains and paths assignment, you only need to run your session and the paths will be auto assigned based on one of the current train mission codes and following your paths mission codes assignment configuration defined in Mission Code Manager.

''Since release 60, there is a new global parameter available on the initial mission code page : process all trains option. By default, it is set to "do not process trains without mission code" but you can change it to "process trains without mission code using implicit value". With this option activated, there is no longer any train without any mission code. First trains with no current mission code are considered as having an implicit mission code #NONE and all trains receive also another implicit mission code #TRP1 or #TPR2 or #TPR3 based on their current trainz priority. By making path eligible or not to these implicit mission codes #NONE, #TPR1, #TPR2,#TPR3 you can use the MCM routing facility to auto select paths for trains without any explicit mission code.''

=== Train Mission Codes auto path assignment : and what are path triggers ? ===

PathTriggers are standard trackmarks or triggers that help to assign path following the method above when the standard assignment routine called when the train approaches the entry signal is not convenient. PathTrigger enables to do the same assignment process, but earlier or later than with the standard routine called when the train approaches then entry signal (about 1 mile before reaching it). It enables also to assign manual paths (paths with the AI auto assign and Player auto assign flags not set).

To assign paths earlier, you need only to position a trackmark or trigger on the track to the entry signal before the 1 mile standard distance for path assignment. You then need to register in the pathtrigger tab of the mission code manager rule the path trigger you are using. And that's all. When a train will reach a registered path trigger, MissionCode Manager will be called, will look forward for the entry signal along a distance of maximum 10 km and when the next entry signal is found it will immediately launch the auto path assignment process as if the train had already reached the 1 mile distance to the signal.
This way you can fire some early auto path assignment before the standard signal reached routine is called.

Path assignment when fired by a PathTrigger is a little different from standard path assignment. As with standard assignment, it will first search for paths with AI auto assign flag or Player auto assign flag set for AI trains or Player train, but if it does not find any available paths, it will then do a second search where it will also look to manual paths (paths with no AI auto assign or Player auto assign flags set). This dual step search is mainly done to enable late path assignment. To do some late path assignment (later than the standard method called at 1 mile from the entry signal) , you need to only use manual paths at the entry signal. When the standard routine will be called at 1 mile from the entry signal, it will find no available paths and so will not assign any path for the train. When later, the train will reach a path trigger, the process will restart, will still find no available paths with AI auto assign or Player auto assign flags set, but it will then look to manual paths and will then assign a path between the eligible manual paths at the entry signal. Using this feature, you can also do some late auto path assignment but only if at the entry signal there are no paths with the AI or Player flag set.

[[File:Help-missioncodemanager-rule-img09.png]]

PathTriggers are optional and need to be used only when the standard path auto assignment routine fired when a train approaches an entry signal is not convenient for your session. Most of my sessions using Mission Code Manager do not have any path trigger, but sometimes in some specific cases path trigger may be very usefull for some specific train behavior.

There is also in the package a driver command ITMCAssignNextPath ( <kuid:61392:8202> ) that will do the same processing as a path trigger on the current train when the command is executed. This driver command may be usefull for train stopped at a platform or a yard to start some auto path assignment process chain with follow on options.

=== Train Mission codes : some other miscellaneous features ===

Another usefull feature is on the interlocking paths list display. The interlocking paths are displayed in high green when the current selected mission code has been added to the interlocking path. It is displayed in low green, when there is only one path available at the entry signal, and in this case Mission code Manager is smart enough to assign the unique path at run time under driver for any mission codes. And the path name is displayed in grey, when several paths are available at the entry signal but the current selected mission code has not been assigned to this path. On the example above, SouthV4 and SouthV5 have selected mission code MONGAR in their mission codes assignments. SouthV2 is not eligible for mission code MONGAR. And V1South, v2South, v3South, v4South, V5South have all a unique path defined at their entry signal that will be selected for any mission code train. This path list page screen supports filtering on both interlocking tower and mission code. You can also select "no filtering" for the interlocking tower, and all the available interlocking towers and paths will be displayed with the high green, low green or grey color and it can be usefull to check for a mission code what are the paths eligible and not.

I think that it is all what is needed to use Train Mission code.
I hope you will enjoy this new rule to help you for interlocking tower path assignment.
And do not hesitate to post in the forum if you need some help or only to make some some comments.

Regards.
Pierre GUY (61392)

[[Category:Help|MissionCode Manager]]
[[Category:Rules]]
{{FUN-bot}}

MissionCodes Manager

2019-02-17T10:16:52Z

Pguy: /* Train Mission Codes auto path assignment : how it works ? */

{{FUN-top}}

===Mission Code Manager rule===
[[File:Help-missioncodemanager-rule-img01.png]]

'''MissionCode Manager''' is a rule ( <kuid:61392:8200> ) which enables to add, edit and manage Mission Code strings, which can be assigned to trains and can be used to auto select paths in interlocking towers to route the trains to their destination.

''This page has been updated to support new features brought with version 60 of Mission code Manager and associated stuff.

=== Train Mission Codes : what is it and for which purpose ?===

A train mission code is any string choosen in a list of arbitrary mission code strings that needs first to be defined by editing the MissionCode Manager Rule (<kuid2:61392:8200>) under surveyor.
After defining all the train mission codes you will use in your session, you can assign one or several train mission codes to any available train using either the trains tab while editing MissionCode Manager rule, or using the driver command SetMissionCode ( <kuid:61392:8201> ) to assign the first mission code to your current train and AddMissionCode ( <kuid:61392:8203> ) to add another mission code to the current train.
All trains, by default have no mission code assigned but may be assigned one or several train mission codes. The mission codes will stay linked to the train until new mission codes are assigned to the train or the mission codes are cleared using also the SetMissionCode driver command. Mission codes linked to a train are kept when a session is saved and later restored. Several trains may be assigned simultaneously the same mission codes.

After defining and setting train mission codes for a train, you can then select while editing the Mission code Manager rule any existing interlocking tower and path and assign to the path any mission code and options. Later in driver mode, when a train with mission codes, will reach the entry signal, the Mission Code Manager Rule will be called as a listener for the interlocking tower, and will activate a path at this entry signal matching one of the the mission codes currently assigned to the train.

You may look at mission codes as a set of keys assigned to a train. When searching for a path at an entry signal, MissionCode Manager will only look to paths matching one of the keys assigned to the train. Only paths with matching mission code will be used for a train when searching for a path at an entry signal.

=== Train Mission Codes : in practice how to define them ===

To use train mission code features in a session, you need first to add to your session rules the Mission Code Manager rule, then edit the rule and define your list of available train mission code strings for this session.
When editing the MissionCode Manager rule, the first page displayed will show the list of all available mission code strings already defined and will offer to add some new mission code, to rename or clone or delete existing ones.

[[File:Help-missioncodemanager-rule-img02.png]]

In the example above, four mission codes strings (CentralToSouth,NorthToSouth,SouthToCentral,SouthToNorth) have been defined for the current session.

This page enables also to set the default global values for Mission Code Manager options like default follow path depth, default follow path option, follow path search distance, exit signal track check mode, unique path select mode option, process all trains option and debugging mode which will be detailed later below in their respective section. The page includes also links to copy MCM data to the common clipboard and to paste MCM data from the common clipboard in order to enable copying MCM data between sessions. It has also a link repair mission codes from internal data that enables to try to recreate missing mission codes from internal MCM data if you have by mistake deleted some still needed mission codes.

=== Train Mission Codes : how to assign a code to a train ===

Now that we have defined the mission codes to be used, the next step is to assign mission codes to trains.

There are now two methods to assign mission codes to train. you can either use the trains tab while editing Mission Code Manager Rule or you can use one between several driver commands to assign mission code at run time.

==== Using the trains tab in Mission Code Manager rule ====

[[File:Help-missioncodemanager-rule-img06A.png]]

As you can see in the above example, the trains tab in Mission Code Manager Rule will list all the trains available in your session ( it is in fact a copy of the list of all trains defined in the driver setup rule ) and the mission codes assigned to it. Using the add mcode and remove mcode links, you can add or suppress a mission code in the set of mission codes assigned to this train.

When the session will start, the MissionCode Manager rule will assign all the mission codes that were defined to each of the available train.

This method is the easiest way to assign mission codes to a train as it does not need to use any driver command in schedules.

==== Using driver commands ====

The other method is to use driver commands to assign mission codes to a train.

SetMissionCode driver command ( <kuid:61392:8201> ) will first clear any existing mission codes set assigned to the current train and will then assign the mission code selected in the menu to the current train.
AddMissionCode driver command ( <kuid:61392:8203> ) will add the mission code selected in the menu to the current train mission codes set.
RemoveMissionCode driver command ( <kuid:61392:8204> ) will do the reverse and will suppress the mission code selected in the menu from the current train mission codes set if the mission code had been previously added to the set.

In order to use these commands, the first step is to enable SetMissionCode, AddMissionCode and RemoveMissionCode driver commands for the current session. To do so, you just need to edit the DriverCommands rule under surveyor and tick the SetMissionCode, AddMissionCode and RemoveMissionCode driver commands.

[[File:Help-missioncodemanager-rule-img06.png]]

[[File:Help-missioncodemanager-rule-img07.png]]

Then you can now select in any driver order bar the SetMissionCode driver command (or AddMissionCode or RemoveMissionCode ) and choose the mission code to assign to the current driver train. You can also do the same in the DriverSetup rule to insert SetMissionCode driver command in a scheduled driver order bar.

[[File:Help-missioncodemanager-rule-img08.png]]

=== Train Mission Codes : how to assign a code to an interlocking tower and path ===

The last step is now to assign mission codes to Interlocking Tower Paths.

In order to do so, just select the interlocking tower page by clicking on the interlocking towers tab. Mission Code Manager will now display the list of all available interlocking towers in the current session :

[[File:Help-missioncodemanager-rule-img03.png]]

Then to select an Interlocking Tower Path in an Interlocking Tower, just click on the interlocking tower view paths link you want to display. It will then display the Interlocking Paths page with all the defined paths in the selected Interlocking Tower.

''Since release 28, this page has also now a link to globally enable or disable the path auto assignment standard routine which is automatically called when a train is on approach of a signal at 0.5 mile. With the option disabled no path auto assignment is done for train with mission codes and explicit path assignment must be done using ITSetPathXXX, ITMCAssignNextPath, path trigger or follow path options
''

[[File:Help-missioncodemanager-rule-img04.png]]

And finally, to display, add or suppress mission codes assigned to a path, just click on the view details link for the path you want to look at.

[[File:Help-missioncodemanager-rule-img05.png]]

On this path details page, you have some links to add new mission code to the current selected path or to remove some already assigned mission codes.

It is also possible to define a priority between 1, 2 and 3 for a path mission code assignment. This priority will be used when the Mission Code Manager has to activate a path for a train at an entry signal. If several paths are available at the entry signal and the mission code is valid for several of these paths, the mission code manager will try first to activate an eligible path (available path with mission code assigned to this path) with mission code priority 1, then 2 and last 3. If several paths are eligible for a mission code at the same priority level, the mission code manager will try to activate a randomly chosen path between paths with same priority.
This feature may be usefull for passengers train at a station or goods train at a yard : mission code manager will first try to activate one of the eligible paths with priority 1. If none are activable, it will then search for paths with priority 2 and then priority 3. Using adequate priorities, you can send a passenger train on a path to a preferred platform, with the opportunity to send the train to another platform using another path if the first one is already occupied.

It is also possible on this page to edit the auto assign AI flag and auto assign flag for the current path.

The option follow path is an option by default set to none, that can be set to either "on path activation" or to "on train entering path". When the option is set to "on path activation", when the current path will become active, Mission code manager will search forward for the next entry signal after the current path exit signal, and will try to activate a new path (follow path) for the current train at this new entry signal using the same assignment process than above. With the on train entering path, it is only when the current train enters the current path (leaves the current path entry signal) that the follow path at the next entry signal is searched. Using these options you can in fact chain paths activation following either the activation or the progression of the train in the previous paths.<br>

You can set a global default value for the follow path option, which can be overridden by a default value at the path level, which can also be overridden at the mission code level.

Chaining path activation by using follow path option is limited by the current follow path depth. The follow path depth defines the maximum number of paths activated but not entered that a train can have. If a follow path activation is requested but the follow path depth is exceeded, the follow path activation will be delayed until the current number of paths activated but not entered will decrease under the follow path depth. The follow path request is not lost but is only delayed.

There is a global default follow path depth which is set on the initial mission code page. This value can be overridden at the mission code level by entering another value for any mission code on the initial mission code page.

There is another way to add/remove mission code eligibility for a path. This can be done using the "view paths" link for a specific mission code on the initial mission code page. This link will display all the available paths in all towers :

[[File:Help-missioncodemanager-rule-imgallpaths.png]]

The paths displayed in low green are path that are unique (only path available) at their entry signal and are by default considered as eligible for any mission codes without the need to configure anything. Paths displayed in high green are paths that have been explicitly made eligible for the selected mission code by validating the selected mission code for the path. Paths displayed in low grey are paths not eligible for the currently selected mission code.

On each path line, depending on its current status, you will find either a "add selected mcode to path config" or "suppress selected mcode from path config" to add or suppress mission code eligibility for the path. By listing for a selected mission code all paths eligibility, it is easy to have a global value of all the paths already enabled for a mission code and to update the configuration if needed. The view details link remains available also on this page to switch to a path view of all eligible mission codes for entering other specific parameters like priority and follow path option.

The page includes at its beginning an option to display all paths or only eligible paths and a tower name filter to enable to tailor this page to your need. To add new mission code eligibility to a path currently not eligible, of course you need to have the display option set to all paths and not limited to eligible paths.

=== Train Mission Codes auto path assignment : how it works ? ===

And now that you have defined your mission codes, assigned them to trains and to specific interlocking tower paths, how all these will work together for path assignment.

Quite simple: when a train approach an entry signal, then interlocking tower will call the mission code manager rule as a listener to assign a path for the current train.

The mission code manager will look at the incoming train and retrieve all the mission codes assigned to the train. If the train has no mission code, it will return to the interlocking tower that it does not support the train and the normal interlocking tower processing will be done for this train with no mission codes. But for a train with some mission codes, the mission code manager will return to the interlocking tower that it takes care of the current train path and that no further processing is needed.

Then the mission code manager will look at all the available paths at the current entry signal and will extract only the list of all available paths at this entry signal eligible for one of the current train mission codes set. A path is eligible for a train only if there is a matching mission code in the list of the path supported mission codes.

To choose the target path, Mission Code Manager will then look in this list of eligible paths for paths with matching mission code at priority 1 then 2 then 3 and will try to assign a path not occupied in the priority order. It is smart enough that if there is only one path available at an entry signal, it will assign this unique path even if no mission code has been assigned to it. If there are several paths available and no paths are eligible the train will remain stuck at the entry signal.

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

So when you have configured all your mission codes, trains and paths assignment, you only need to run your session and the paths will be auto assigned based on one of the current train mission codes and following your paths mission codes assignment configuration defined in Mission Code Manager.

""Since release 60, there is a new global parameter available on the initial mission code page : process all trains option. By default, it is set to "do not process trains without mission code" but you can change it to "process trains without mission code using implicit value". With this option activated, there is no longer any train without any mission code. First trains with no current mission code are considered as having an implicit mission code #NONE and all trains receive also another implicit mission code #TRP1 or #TPR2 or #TPR3 based on their current trainz priority. By making path eligible or not to these implicit mission codes #NONE, #TPR1, #TPR2,#TPR3 you can use the MCM routing facility to auto select paths for trains without any explicit mission code.

=== Train Mission Codes auto path assignment : and what are path triggers ? ===

PathTriggers are standard trackmarks or triggers that help to assign path following the method above when the standard assignment routine called when the train approaches the entry signal is not convenient. PathTrigger enables to do the same assignment process, but earlier or later than with the standard routine called when the train approaches then entry signal (about 1 mile before reaching it). It enables also to assign manual paths (paths with the AI auto assign and Player auto assign flags not set).

To assign paths earlier, you need only to position a trackmark or trigger on the track to the entry signal before the 1 mile standard distance for path assignment. You then need to register in the pathtrigger tab of the mission code manager rule the path trigger you are using. And that's all. When a train will reach a registered path trigger, MissionCode Manager will be called, will look forward for the entry signal along a distance of maximum 10 km and when the next entry signal is found it will immediately launch the auto path assignment process as if the train had already reached the 1 mile distance to the signal.
This way you can fire some early auto path assignment before the standard signal reached routine is called.

Path assignment when fired by a PathTrigger is a little different from standard path assignment. As with standard assignment, it will first search for paths with AI auto assign flag or Player auto assign flag set for AI trains or Player train, but if it does not find any available paths, it will then do a second search where it will also look to manual paths (paths with no AI auto assign or Player auto assign flags set). This dual step search is mainly done to enable late path assignment. To do some late path assignment (later than the standard method called at 1 mile from the entry signal) , you need to only use manual paths at the entry signal. When the standard routine will be called at 1 mile from the entry signal, it will find no available paths and so will not assign any path for the train. When later, the train will reach a path trigger, the process will restart, will still find no available paths with AI auto assign or Player auto assign flags set, but it will then look to manual paths and will then assign a path between the eligible manual paths at the entry signal. Using this feature, you can also do some late auto path assignment but only if at the entry signal there are no paths with the AI or Player flag set.

[[File:Help-missioncodemanager-rule-img09.png]]

PathTriggers are optional and need to be used only when the standard path auto assignment routine fired when a train approaches an entry signal is not convenient for your session. Most of my sessions using Mission Code Manager do not have any path trigger, but sometimes in some specific cases path trigger may be very usefull for some specific train behavior.

There is also in the package a driver command ITMCAssignNextPath ( <kuid:61392:8202> ) that will do the same processing as a path trigger on the current train when the command is executed. This driver command may be usefull for train stopped at a platform or a yard to start some auto path assignment process chain with follow on options.

=== Train Mission codes : some other miscellaneous features ===

Another usefull feature is on the interlocking paths list display. The interlocking paths are displayed in high green when the current selected mission code has been added to the interlocking path. It is displayed in low green, when there is only one path available at the entry signal, and in this case Mission code Manager is smart enough to assign the unique path at run time under driver for any mission codes. And the path name is displayed in grey, when several paths are available at the entry signal but the current selected mission code has not been assigned to this path. On the example above, SouthV4 and SouthV5 have selected mission code MONGAR in their mission codes assignments. SouthV2 is not eligible for mission code MONGAR. And V1South, v2South, v3South, v4South, V5South have all a unique path defined at their entry signal that will be selected for any mission code train. This path list page screen supports filtering on both interlocking tower and mission code. You can also select "no filtering" for the interlocking tower, and all the available interlocking towers and paths will be displayed with the high green, low green or grey color and it can be usefull to check for a mission code what are the paths eligible and not.

I think that it is all what is needed to use Train Mission code.
I hope you will enjoy this new rule to help you for interlocking tower path assignment.
And do not hesitate to post in the forum if you need some help or only to make some some comments.

Regards.
Pierre GUY (61392)

[[Category:Help|MissionCode Manager]]
[[Category:Rules]]
{{FUN-bot}}

MissionCodes Manager

2019-02-17T10:08:38Z

Pguy: /* Train Mission Codes : how to assign a code to an interlocking tower and path */

{{FUN-top}}

===Mission Code Manager rule===
[[File:Help-missioncodemanager-rule-img01.png]]

'''MissionCode Manager''' is a rule ( <kuid:61392:8200> ) which enables to add, edit and manage Mission Code strings, which can be assigned to trains and can be used to auto select paths in interlocking towers to route the trains to their destination.

''This page has been updated to support new features brought with version 60 of Mission code Manager and associated stuff.

=== Train Mission Codes : what is it and for which purpose ?===

A train mission code is any string choosen in a list of arbitrary mission code strings that needs first to be defined by editing the MissionCode Manager Rule (<kuid2:61392:8200>) under surveyor.
After defining all the train mission codes you will use in your session, you can assign one or several train mission codes to any available train using either the trains tab while editing MissionCode Manager rule, or using the driver command SetMissionCode ( <kuid:61392:8201> ) to assign the first mission code to your current train and AddMissionCode ( <kuid:61392:8203> ) to add another mission code to the current train.
All trains, by default have no mission code assigned but may be assigned one or several train mission codes. The mission codes will stay linked to the train until new mission codes are assigned to the train or the mission codes are cleared using also the SetMissionCode driver command. Mission codes linked to a train are kept when a session is saved and later restored. Several trains may be assigned simultaneously the same mission codes.

After defining and setting train mission codes for a train, you can then select while editing the Mission code Manager rule any existing interlocking tower and path and assign to the path any mission code and options. Later in driver mode, when a train with mission codes, will reach the entry signal, the Mission Code Manager Rule will be called as a listener for the interlocking tower, and will activate a path at this entry signal matching one of the the mission codes currently assigned to the train.

You may look at mission codes as a set of keys assigned to a train. When searching for a path at an entry signal, MissionCode Manager will only look to paths matching one of the keys assigned to the train. Only paths with matching mission code will be used for a train when searching for a path at an entry signal.

=== Train Mission Codes : in practice how to define them ===

To use train mission code features in a session, you need first to add to your session rules the Mission Code Manager rule, then edit the rule and define your list of available train mission code strings for this session.
When editing the MissionCode Manager rule, the first page displayed will show the list of all available mission code strings already defined and will offer to add some new mission code, to rename or clone or delete existing ones.

[[File:Help-missioncodemanager-rule-img02.png]]

In the example above, four mission codes strings (CentralToSouth,NorthToSouth,SouthToCentral,SouthToNorth) have been defined for the current session.

This page enables also to set the default global values for Mission Code Manager options like default follow path depth, default follow path option, follow path search distance, exit signal track check mode, unique path select mode option, process all trains option and debugging mode which will be detailed later below in their respective section. The page includes also links to copy MCM data to the common clipboard and to paste MCM data from the common clipboard in order to enable copying MCM data between sessions. It has also a link repair mission codes from internal data that enables to try to recreate missing mission codes from internal MCM data if you have by mistake deleted some still needed mission codes.

=== Train Mission Codes : how to assign a code to a train ===

Now that we have defined the mission codes to be used, the next step is to assign mission codes to trains.

There are now two methods to assign mission codes to train. you can either use the trains tab while editing Mission Code Manager Rule or you can use one between several driver commands to assign mission code at run time.

==== Using the trains tab in Mission Code Manager rule ====

[[File:Help-missioncodemanager-rule-img06A.png]]

As you can see in the above example, the trains tab in Mission Code Manager Rule will list all the trains available in your session ( it is in fact a copy of the list of all trains defined in the driver setup rule ) and the mission codes assigned to it. Using the add mcode and remove mcode links, you can add or suppress a mission code in the set of mission codes assigned to this train.

When the session will start, the MissionCode Manager rule will assign all the mission codes that were defined to each of the available train.

This method is the easiest way to assign mission codes to a train as it does not need to use any driver command in schedules.

==== Using driver commands ====

The other method is to use driver commands to assign mission codes to a train.

SetMissionCode driver command ( <kuid:61392:8201> ) will first clear any existing mission codes set assigned to the current train and will then assign the mission code selected in the menu to the current train.
AddMissionCode driver command ( <kuid:61392:8203> ) will add the mission code selected in the menu to the current train mission codes set.
RemoveMissionCode driver command ( <kuid:61392:8204> ) will do the reverse and will suppress the mission code selected in the menu from the current train mission codes set if the mission code had been previously added to the set.

In order to use these commands, the first step is to enable SetMissionCode, AddMissionCode and RemoveMissionCode driver commands for the current session. To do so, you just need to edit the DriverCommands rule under surveyor and tick the SetMissionCode, AddMissionCode and RemoveMissionCode driver commands.

[[File:Help-missioncodemanager-rule-img06.png]]

[[File:Help-missioncodemanager-rule-img07.png]]

Then you can now select in any driver order bar the SetMissionCode driver command (or AddMissionCode or RemoveMissionCode ) and choose the mission code to assign to the current driver train. You can also do the same in the DriverSetup rule to insert SetMissionCode driver command in a scheduled driver order bar.

[[File:Help-missioncodemanager-rule-img08.png]]

=== Train Mission Codes : how to assign a code to an interlocking tower and path ===

The last step is now to assign mission codes to Interlocking Tower Paths.

In order to do so, just select the interlocking tower page by clicking on the interlocking towers tab. Mission Code Manager will now display the list of all available interlocking towers in the current session :

[[File:Help-missioncodemanager-rule-img03.png]]

Then to select an Interlocking Tower Path in an Interlocking Tower, just click on the interlocking tower view paths link you want to display. It will then display the Interlocking Paths page with all the defined paths in the selected Interlocking Tower.

''Since release 28, this page has also now a link to globally enable or disable the path auto assignment standard routine which is automatically called when a train is on approach of a signal at 0.5 mile. With the option disabled no path auto assignment is done for train with mission codes and explicit path assignment must be done using ITSetPathXXX, ITMCAssignNextPath, path trigger or follow path options
''

[[File:Help-missioncodemanager-rule-img04.png]]

And finally, to display, add or suppress mission codes assigned to a path, just click on the view details link for the path you want to look at.

[[File:Help-missioncodemanager-rule-img05.png]]

On this path details page, you have some links to add new mission code to the current selected path or to remove some already assigned mission codes.

It is also possible to define a priority between 1, 2 and 3 for a path mission code assignment. This priority will be used when the Mission Code Manager has to activate a path for a train at an entry signal. If several paths are available at the entry signal and the mission code is valid for several of these paths, the mission code manager will try first to activate an eligible path (available path with mission code assigned to this path) with mission code priority 1, then 2 and last 3. If several paths are eligible for a mission code at the same priority level, the mission code manager will try to activate a randomly chosen path between paths with same priority.
This feature may be usefull for passengers train at a station or goods train at a yard : mission code manager will first try to activate one of the eligible paths with priority 1. If none are activable, it will then search for paths with priority 2 and then priority 3. Using adequate priorities, you can send a passenger train on a path to a preferred platform, with the opportunity to send the train to another platform using another path if the first one is already occupied.

It is also possible on this page to edit the auto assign AI flag and auto assign flag for the current path.

The option follow path is an option by default set to none, that can be set to either "on path activation" or to "on train entering path". When the option is set to "on path activation", when the current path will become active, Mission code manager will search forward for the next entry signal after the current path exit signal, and will try to activate a new path (follow path) for the current train at this new entry signal using the same assignment process than above. With the on train entering path, it is only when the current train enters the current path (leaves the current path entry signal) that the follow path at the next entry signal is searched. Using these options you can in fact chain paths activation following either the activation or the progression of the train in the previous paths.<br>

You can set a global default value for the follow path option, which can be overridden by a default value at the path level, which can also be overridden at the mission code level.

Chaining path activation by using follow path option is limited by the current follow path depth. The follow path depth defines the maximum number of paths activated but not entered that a train can have. If a follow path activation is requested but the follow path depth is exceeded, the follow path activation will be delayed until the current number of paths activated but not entered will decrease under the follow path depth. The follow path request is not lost but is only delayed.

There is a global default follow path depth which is set on the initial mission code page. This value can be overridden at the mission code level by entering another value for any mission code on the initial mission code page.

There is another way to add/remove mission code eligibility for a path. This can be done using the "view paths" link for a specific mission code on the initial mission code page. This link will display all the available paths in all towers :

[[File:Help-missioncodemanager-rule-imgallpaths.png]]

The paths displayed in low green are path that are unique (only path available) at their entry signal and are by default considered as eligible for any mission codes without the need to configure anything. Paths displayed in high green are paths that have been explicitly made eligible for the selected mission code by validating the selected mission code for the path. Paths displayed in low grey are paths not eligible for the currently selected mission code.

On each path line, depending on its current status, you will find either a "add selected mcode to path config" or "suppress selected mcode from path config" to add or suppress mission code eligibility for the path. By listing for a selected mission code all paths eligibility, it is easy to have a global value of all the paths already enabled for a mission code and to update the configuration if needed. The view details link remains available also on this page to switch to a path view of all eligible mission codes for entering other specific parameters like priority and follow path option.

The page includes at its beginning an option to display all paths or only eligible paths and a tower name filter to enable to tailor this page to your need. To add new mission code eligibility to a path currently not eligible, of course you need to have the display option set to all paths and not limited to eligible paths.

=== Train Mission Codes auto path assignment : how it works ? ===

And now that you have defined your mission codes, assigned them to trains and to specific interlocking tower paths, how all these will work together for path assignment.

Quite simple: when a train approach an entry signal, then interlocking tower will call the mission code manager rule as a listener to assign a path for the current train.

The mission code manager will look at the incoming train and retrieve all the mission codes assigned to the train. If the train has no mission code, it will return to the interlocking tower that it does not support the train and the normal interlocking tower processing will be done for this train with no mission codes. But for a train with some mission codes, the mission code manager will return to the interlocking tower that it takes care of the current train path and that no further processing is needed.

Then the mission code manager will look at all the available paths at the current entry signal and will extract only the list of all available paths at this entry signal eligible for one of the current train mission codes set. A path is eligible for a train only if there is a matching mission code in the list of the path supported mission codes.

To choose the target path, Mission Code Manager will then look in this list of eligible paths for paths with matching mission code at priority 1 then 2 then 3 and will try to assign a path not occupied in the priority order. It is smart enough that if there is only one path available at an entry signal, it will assign this unique path even if no mission code has been assigned to it. If there are several paths available and no paths are eligible the train will remain stuck at the entry signal.

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

So when you have configured all your mission codes, trains and paths assignment, you only need to run your session and the paths will be auto assigned based on one of the current train mission codes and following your paths mission codes assignment configuration defined in Mission Code Manager.

=== Train Mission Codes auto path assignment : and what are path triggers ? ===

PathTriggers are standard trackmarks or triggers that help to assign path following the method above when the standard assignment routine called when the train approaches the entry signal is not convenient. PathTrigger enables to do the same assignment process, but earlier or later than with the standard routine called when the train approaches then entry signal (about 1 mile before reaching it). It enables also to assign manual paths (paths with the AI auto assign and Player auto assign flags not set).

To assign paths earlier, you need only to position a trackmark or trigger on the track to the entry signal before the 1 mile standard distance for path assignment. You then need to register in the pathtrigger tab of the mission code manager rule the path trigger you are using. And that's all. When a train will reach a registered path trigger, MissionCode Manager will be called, will look forward for the entry signal along a distance of maximum 10 km and when the next entry signal is found it will immediately launch the auto path assignment process as if the train had already reached the 1 mile distance to the signal.
This way you can fire some early auto path assignment before the standard signal reached routine is called.

Path assignment when fired by a PathTrigger is a little different from standard path assignment. As with standard assignment, it will first search for paths with AI auto assign flag or Player auto assign flag set for AI trains or Player train, but if it does not find any available paths, it will then do a second search where it will also look to manual paths (paths with no AI auto assign or Player auto assign flags set). This dual step search is mainly done to enable late path assignment. To do some late path assignment (later than the standard method called at 1 mile from the entry signal) , you need to only use manual paths at the entry signal. When the standard routine will be called at 1 mile from the entry signal, it will find no available paths and so will not assign any path for the train. When later, the train will reach a path trigger, the process will restart, will still find no available paths with AI auto assign or Player auto assign flags set, but it will then look to manual paths and will then assign a path between the eligible manual paths at the entry signal. Using this feature, you can also do some late auto path assignment but only if at the entry signal there are no paths with the AI or Player flag set.

[[File:Help-missioncodemanager-rule-img09.png]]

PathTriggers are optional and need to be used only when the standard path auto assignment routine fired when a train approaches an entry signal is not convenient for your session. Most of my sessions using Mission Code Manager do not have any path trigger, but sometimes in some specific cases path trigger may be very usefull for some specific train behavior.

There is also in the package a driver command ITMCAssignNextPath ( <kuid:61392:8202> ) that will do the same processing as a path trigger on the current train when the command is executed. This driver command may be usefull for train stopped at a platform or a yard to start some auto path assignment process chain with follow on options.

=== Train Mission codes : some other miscellaneous features ===

Another usefull feature is on the interlocking paths list display. The interlocking paths are displayed in high green when the current selected mission code has been added to the interlocking path. It is displayed in low green, when there is only one path available at the entry signal, and in this case Mission code Manager is smart enough to assign the unique path at run time under driver for any mission codes. And the path name is displayed in grey, when several paths are available at the entry signal but the current selected mission code has not been assigned to this path. On the example above, SouthV4 and SouthV5 have selected mission code MONGAR in their mission codes assignments. SouthV2 is not eligible for mission code MONGAR. And V1South, v2South, v3South, v4South, V5South have all a unique path defined at their entry signal that will be selected for any mission code train. This path list page screen supports filtering on both interlocking tower and mission code. You can also select "no filtering" for the interlocking tower, and all the available interlocking towers and paths will be displayed with the high green, low green or grey color and it can be usefull to check for a mission code what are the paths eligible and not.

I think that it is all what is needed to use Train Mission code.
I hope you will enjoy this new rule to help you for interlocking tower path assignment.
And do not hesitate to post in the forum if you need some help or only to make some some comments.

Regards.
Pierre GUY (61392)

[[Category:Help|MissionCode Manager]]
[[Category:Rules]]
{{FUN-bot}}

MissionCodes Manager

2019-02-17T10:04:29Z

Pguy: /* Train Mission Codes : how to assign a code to an interlocking tower and path */

{{FUN-top}}

===Mission Code Manager rule===
[[File:Help-missioncodemanager-rule-img01.png]]

'''MissionCode Manager''' is a rule ( <kuid:61392:8200> ) which enables to add, edit and manage Mission Code strings, which can be assigned to trains and can be used to auto select paths in interlocking towers to route the trains to their destination.

''This page has been updated to support new features brought with version 60 of Mission code Manager and associated stuff.

=== Train Mission Codes : what is it and for which purpose ?===

A train mission code is any string choosen in a list of arbitrary mission code strings that needs first to be defined by editing the MissionCode Manager Rule (<kuid2:61392:8200>) under surveyor.
After defining all the train mission codes you will use in your session, you can assign one or several train mission codes to any available train using either the trains tab while editing MissionCode Manager rule, or using the driver command SetMissionCode ( <kuid:61392:8201> ) to assign the first mission code to your current train and AddMissionCode ( <kuid:61392:8203> ) to add another mission code to the current train.
All trains, by default have no mission code assigned but may be assigned one or several train mission codes. The mission codes will stay linked to the train until new mission codes are assigned to the train or the mission codes are cleared using also the SetMissionCode driver command. Mission codes linked to a train are kept when a session is saved and later restored. Several trains may be assigned simultaneously the same mission codes.

After defining and setting train mission codes for a train, you can then select while editing the Mission code Manager rule any existing interlocking tower and path and assign to the path any mission code and options. Later in driver mode, when a train with mission codes, will reach the entry signal, the Mission Code Manager Rule will be called as a listener for the interlocking tower, and will activate a path at this entry signal matching one of the the mission codes currently assigned to the train.

You may look at mission codes as a set of keys assigned to a train. When searching for a path at an entry signal, MissionCode Manager will only look to paths matching one of the keys assigned to the train. Only paths with matching mission code will be used for a train when searching for a path at an entry signal.

=== Train Mission Codes : in practice how to define them ===

To use train mission code features in a session, you need first to add to your session rules the Mission Code Manager rule, then edit the rule and define your list of available train mission code strings for this session.
When editing the MissionCode Manager rule, the first page displayed will show the list of all available mission code strings already defined and will offer to add some new mission code, to rename or clone or delete existing ones.

[[File:Help-missioncodemanager-rule-img02.png]]

In the example above, four mission codes strings (CentralToSouth,NorthToSouth,SouthToCentral,SouthToNorth) have been defined for the current session.

This page enables also to set the default global values for Mission Code Manager options like default follow path depth, default follow path option, follow path search distance, exit signal track check mode, unique path select mode option, process all trains option and debugging mode which will be detailed later below in their respective section. The page includes also links to copy MCM data to the common clipboard and to paste MCM data from the common clipboard in order to enable copying MCM data between sessions. It has also a link repair mission codes from internal data that enables to try to recreate missing mission codes from internal MCM data if you have by mistake deleted some still needed mission codes.

=== Train Mission Codes : how to assign a code to a train ===

Now that we have defined the mission codes to be used, the next step is to assign mission codes to trains.

There are now two methods to assign mission codes to train. you can either use the trains tab while editing Mission Code Manager Rule or you can use one between several driver commands to assign mission code at run time.

==== Using the trains tab in Mission Code Manager rule ====

[[File:Help-missioncodemanager-rule-img06A.png]]

As you can see in the above example, the trains tab in Mission Code Manager Rule will list all the trains available in your session ( it is in fact a copy of the list of all trains defined in the driver setup rule ) and the mission codes assigned to it. Using the add mcode and remove mcode links, you can add or suppress a mission code in the set of mission codes assigned to this train.

When the session will start, the MissionCode Manager rule will assign all the mission codes that were defined to each of the available train.

This method is the easiest way to assign mission codes to a train as it does not need to use any driver command in schedules.

==== Using driver commands ====

The other method is to use driver commands to assign mission codes to a train.

SetMissionCode driver command ( <kuid:61392:8201> ) will first clear any existing mission codes set assigned to the current train and will then assign the mission code selected in the menu to the current train.
AddMissionCode driver command ( <kuid:61392:8203> ) will add the mission code selected in the menu to the current train mission codes set.
RemoveMissionCode driver command ( <kuid:61392:8204> ) will do the reverse and will suppress the mission code selected in the menu from the current train mission codes set if the mission code had been previously added to the set.

In order to use these commands, the first step is to enable SetMissionCode, AddMissionCode and RemoveMissionCode driver commands for the current session. To do so, you just need to edit the DriverCommands rule under surveyor and tick the SetMissionCode, AddMissionCode and RemoveMissionCode driver commands.

[[File:Help-missioncodemanager-rule-img06.png]]

[[File:Help-missioncodemanager-rule-img07.png]]

Then you can now select in any driver order bar the SetMissionCode driver command (or AddMissionCode or RemoveMissionCode ) and choose the mission code to assign to the current driver train. You can also do the same in the DriverSetup rule to insert SetMissionCode driver command in a scheduled driver order bar.

[[File:Help-missioncodemanager-rule-img08.png]]

=== Train Mission Codes : how to assign a code to an interlocking tower and path ===

The last step is now to assign mission codes to Interlocking Tower Paths.

In order to do so, just select the interlocking tower page by clicking on the interlocking towers tab. Mission Code Manager will now display the list of all available interlocking towers in the current session :

[[File:Help-missioncodemanager-rule-img03.png]]

Then to select an Interlocking Tower Path in an Interlocking Tower, just click on the interlocking tower view paths link you want to display. It will then display the Interlocking Paths page with all the defined paths in the selected Interlocking Tower.

''Since release 28, this page has also now a link to globally enable or disable the path auto assignment standard routine which is automatically called when a train is on approach of a signal at 0.5 mile. With the option disabled no path auto assignment is done for train with mission codes and explicit path assignment must be done using ITSetPathXXX, ITMCAssignNextPath, path trigger or follow path options
''

[[File:Help-missioncodemanager-rule-img04.png]]

And finally, to display, add or suppress mission codes assigned to a path, just click on the view details link for the path you want to look at.

[[File:Help-missioncodemanager-rule-img05.png]]

On this path details page, you have some links to add new mission code to the current selected path or to remove some already assigned mission codes.

It is also possible to define a priority between 1, 2 and 3 for a path mission code assignment. This priority will be used when the Mission Code Manager has to activate a path for a train at an entry signal. If several paths are available at the entry signal and the mission code is valid for several of these paths, the mission code manager will try first to activate an eligible path (available path with mission code assigned to this path) with mission code priority 1, then 2 and last 3. If several paths are eligible for a mission code at the same priority level, the mission code manager will try to activate a randomly chosen path between paths with same priority.
This feature may be usefull for passengers train at a station or goods train at a yard : mission code manager will first try to activate one of the eligible paths with priority 1. If none are activable, it will then search for paths with priority 2 and then priority 3. Using adequate priorities, you can send a passenger train on a path to a preferred platform, with the opportunity to send the train to another platform using another path if the first one is already occupied.

It is also possible on this page to edit the auto assign AI flag and auto assign flag for the current path.

The option follow path is an option by default set to none, that can be set to either "on path activation" or to "on train entering path". When the option is set to "on path activation", when the current path will become active, Mission code manager will search forward for the next entry signal after the current path exit signal, and will try to activate a new path (follow path) for the current train at this new entry signal using the same assignment process than above. With the on train entering path, it is only when the current train enters the current path (leaves the current path entry signal) that the follow path at the next entry signal is searched. Using these options you can in fact chain paths activation following either the activation or the progression of the train in the previous paths.<br>

You can set a global default value for the follow path option, which can be overridden by a default value at the path level, which can also be overridden at the mission code level.

Chaining path activation by using follow path option is limited by the current follow path depth. The follow path depth defines the maximum number of paths activated but not entered that a train can have. If a follow path activation is requested but the follow path depth is exceeded, the follow path activation will be delayed until the current number of paths activated but not entered will decrease under the follow path depth. The follow path request is not lost but is only delayed.

There is a global default follow path depth which is set on the initial mission code page. This value can be overridden at the mission code level by entering another value for any mission code on the initial mission code page.

There is another way to add/remove mission code eligibility for a path. This can be done using the "view paths" link for a specific mission code on the initial mission code page. This link will display all the available paths in all towers :

[[File:Help-missioncodemanager-rule-imgallpaths.png]]

The paths displayed in low green are path that are unique (only path available) at their entry signal and are by default considered as eligible for any mission codes without the need to configure anything. Paths displayed in high green are paths that have been explicitly made eligible for the selected mission code by validating the selected mission code for the path. Paths displayed in low grey are paths not eligible for the currently selected mission code.

On each path line, depending on its current status, you will find either a "add selected mcode to path config" or "suppress selected mcode from path config" to add or suppress mission code eligibility for the path. By listing for a selected mission code all paths eligibility, it is easy to have a global value of all the paths already enabled for a mission code and to update the configuration if needed. The view details link remains available also on this page to switch to a path view of all eligible mission codes for entering other specific parameters like priority and follow path option.

=== Train Mission Codes auto path assignment : how it works ? ===

And now that you have defined your mission codes, assigned them to trains and to specific interlocking tower paths, how all these will work together for path assignment.

Quite simple: when a train approach an entry signal, then interlocking tower will call the mission code manager rule as a listener to assign a path for the current train.

The mission code manager will look at the incoming train and retrieve all the mission codes assigned to the train. If the train has no mission code, it will return to the interlocking tower that it does not support the train and the normal interlocking tower processing will be done for this train with no mission codes. But for a train with some mission codes, the mission code manager will return to the interlocking tower that it takes care of the current train path and that no further processing is needed.

Then the mission code manager will look at all the available paths at the current entry signal and will extract only the list of all available paths at this entry signal eligible for one of the current train mission codes set. A path is eligible for a train only if there is a matching mission code in the list of the path supported mission codes.

To choose the target path, Mission Code Manager will then look in this list of eligible paths for paths with matching mission code at priority 1 then 2 then 3 and will try to assign a path not occupied in the priority order. It is smart enough that if there is only one path available at an entry signal, it will assign this unique path even if no mission code has been assigned to it. If there are several paths available and no paths are eligible the train will remain stuck at the entry signal.

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

So when you have configured all your mission codes, trains and paths assignment, you only need to run your session and the paths will be auto assigned based on one of the current train mission codes and following your paths mission codes assignment configuration defined in Mission Code Manager.

=== Train Mission Codes auto path assignment : and what are path triggers ? ===

PathTriggers are standard trackmarks or triggers that help to assign path following the method above when the standard assignment routine called when the train approaches the entry signal is not convenient. PathTrigger enables to do the same assignment process, but earlier or later than with the standard routine called when the train approaches then entry signal (about 1 mile before reaching it). It enables also to assign manual paths (paths with the AI auto assign and Player auto assign flags not set).

To assign paths earlier, you need only to position a trackmark or trigger on the track to the entry signal before the 1 mile standard distance for path assignment. You then need to register in the pathtrigger tab of the mission code manager rule the path trigger you are using. And that's all. When a train will reach a registered path trigger, MissionCode Manager will be called, will look forward for the entry signal along a distance of maximum 10 km and when the next entry signal is found it will immediately launch the auto path assignment process as if the train had already reached the 1 mile distance to the signal.
This way you can fire some early auto path assignment before the standard signal reached routine is called.

Path assignment when fired by a PathTrigger is a little different from standard path assignment. As with standard assignment, it will first search for paths with AI auto assign flag or Player auto assign flag set for AI trains or Player train, but if it does not find any available paths, it will then do a second search where it will also look to manual paths (paths with no AI auto assign or Player auto assign flags set). This dual step search is mainly done to enable late path assignment. To do some late path assignment (later than the standard method called at 1 mile from the entry signal) , you need to only use manual paths at the entry signal. When the standard routine will be called at 1 mile from the entry signal, it will find no available paths and so will not assign any path for the train. When later, the train will reach a path trigger, the process will restart, will still find no available paths with AI auto assign or Player auto assign flags set, but it will then look to manual paths and will then assign a path between the eligible manual paths at the entry signal. Using this feature, you can also do some late auto path assignment but only if at the entry signal there are no paths with the AI or Player flag set.

[[File:Help-missioncodemanager-rule-img09.png]]

PathTriggers are optional and need to be used only when the standard path auto assignment routine fired when a train approaches an entry signal is not convenient for your session. Most of my sessions using Mission Code Manager do not have any path trigger, but sometimes in some specific cases path trigger may be very usefull for some specific train behavior.

There is also in the package a driver command ITMCAssignNextPath ( <kuid:61392:8202> ) that will do the same processing as a path trigger on the current train when the command is executed. This driver command may be usefull for train stopped at a platform or a yard to start some auto path assignment process chain with follow on options.

=== Train Mission codes : some other miscellaneous features ===

Another usefull feature is on the interlocking paths list display. The interlocking paths are displayed in high green when the current selected mission code has been added to the interlocking path. It is displayed in low green, when there is only one path available at the entry signal, and in this case Mission code Manager is smart enough to assign the unique path at run time under driver for any mission codes. And the path name is displayed in grey, when several paths are available at the entry signal but the current selected mission code has not been assigned to this path. On the example above, SouthV4 and SouthV5 have selected mission code MONGAR in their mission codes assignments. SouthV2 is not eligible for mission code MONGAR. And V1South, v2South, v3South, v4South, V5South have all a unique path defined at their entry signal that will be selected for any mission code train. This path list page screen supports filtering on both interlocking tower and mission code. You can also select "no filtering" for the interlocking tower, and all the available interlocking towers and paths will be displayed with the high green, low green or grey color and it can be usefull to check for a mission code what are the paths eligible and not.

I think that it is all what is needed to use Train Mission code.
I hope you will enjoy this new rule to help you for interlocking tower path assignment.
And do not hesitate to post in the forum if you need some help or only to make some some comments.

Regards.
Pierre GUY (61392)

[[Category:Help|MissionCode Manager]]
[[Category:Rules]]
{{FUN-bot}}

File:Help-missioncodemanager-rule-imgallpaths.png

2019-02-17T09:55:22Z

Pguy:

MissionCodes Manager

2019-02-17T09:55:03Z

Pguy: /* Train Mission Codes : how to assign a code to an interlocking tower and path */

{{FUN-top}}

===Mission Code Manager rule===
[[File:Help-missioncodemanager-rule-img01.png]]

'''MissionCode Manager''' is a rule ( <kuid:61392:8200> ) which enables to add, edit and manage Mission Code strings, which can be assigned to trains and can be used to auto select paths in interlocking towers to route the trains to their destination.

''This page has been updated to support new features brought with version 60 of Mission code Manager and associated stuff.

=== Train Mission Codes : what is it and for which purpose ?===

A train mission code is any string choosen in a list of arbitrary mission code strings that needs first to be defined by editing the MissionCode Manager Rule (<kuid2:61392:8200>) under surveyor.
After defining all the train mission codes you will use in your session, you can assign one or several train mission codes to any available train using either the trains tab while editing MissionCode Manager rule, or using the driver command SetMissionCode ( <kuid:61392:8201> ) to assign the first mission code to your current train and AddMissionCode ( <kuid:61392:8203> ) to add another mission code to the current train.
All trains, by default have no mission code assigned but may be assigned one or several train mission codes. The mission codes will stay linked to the train until new mission codes are assigned to the train or the mission codes are cleared using also the SetMissionCode driver command. Mission codes linked to a train are kept when a session is saved and later restored. Several trains may be assigned simultaneously the same mission codes.

After defining and setting train mission codes for a train, you can then select while editing the Mission code Manager rule any existing interlocking tower and path and assign to the path any mission code and options. Later in driver mode, when a train with mission codes, will reach the entry signal, the Mission Code Manager Rule will be called as a listener for the interlocking tower, and will activate a path at this entry signal matching one of the the mission codes currently assigned to the train.

You may look at mission codes as a set of keys assigned to a train. When searching for a path at an entry signal, MissionCode Manager will only look to paths matching one of the keys assigned to the train. Only paths with matching mission code will be used for a train when searching for a path at an entry signal.

=== Train Mission Codes : in practice how to define them ===

To use train mission code features in a session, you need first to add to your session rules the Mission Code Manager rule, then edit the rule and define your list of available train mission code strings for this session.
When editing the MissionCode Manager rule, the first page displayed will show the list of all available mission code strings already defined and will offer to add some new mission code, to rename or clone or delete existing ones.

[[File:Help-missioncodemanager-rule-img02.png]]

In the example above, four mission codes strings (CentralToSouth,NorthToSouth,SouthToCentral,SouthToNorth) have been defined for the current session.

This page enables also to set the default global values for Mission Code Manager options like default follow path depth, default follow path option, follow path search distance, exit signal track check mode, unique path select mode option, process all trains option and debugging mode which will be detailed later below in their respective section. The page includes also links to copy MCM data to the common clipboard and to paste MCM data from the common clipboard in order to enable copying MCM data between sessions. It has also a link repair mission codes from internal data that enables to try to recreate missing mission codes from internal MCM data if you have by mistake deleted some still needed mission codes.

=== Train Mission Codes : how to assign a code to a train ===

Now that we have defined the mission codes to be used, the next step is to assign mission codes to trains.

There are now two methods to assign mission codes to train. you can either use the trains tab while editing Mission Code Manager Rule or you can use one between several driver commands to assign mission code at run time.

==== Using the trains tab in Mission Code Manager rule ====

[[File:Help-missioncodemanager-rule-img06A.png]]

As you can see in the above example, the trains tab in Mission Code Manager Rule will list all the trains available in your session ( it is in fact a copy of the list of all trains defined in the driver setup rule ) and the mission codes assigned to it. Using the add mcode and remove mcode links, you can add or suppress a mission code in the set of mission codes assigned to this train.

When the session will start, the MissionCode Manager rule will assign all the mission codes that were defined to each of the available train.

This method is the easiest way to assign mission codes to a train as it does not need to use any driver command in schedules.

==== Using driver commands ====

The other method is to use driver commands to assign mission codes to a train.

SetMissionCode driver command ( <kuid:61392:8201> ) will first clear any existing mission codes set assigned to the current train and will then assign the mission code selected in the menu to the current train.
AddMissionCode driver command ( <kuid:61392:8203> ) will add the mission code selected in the menu to the current train mission codes set.
RemoveMissionCode driver command ( <kuid:61392:8204> ) will do the reverse and will suppress the mission code selected in the menu from the current train mission codes set if the mission code had been previously added to the set.

In order to use these commands, the first step is to enable SetMissionCode, AddMissionCode and RemoveMissionCode driver commands for the current session. To do so, you just need to edit the DriverCommands rule under surveyor and tick the SetMissionCode, AddMissionCode and RemoveMissionCode driver commands.

[[File:Help-missioncodemanager-rule-img06.png]]

[[File:Help-missioncodemanager-rule-img07.png]]

Then you can now select in any driver order bar the SetMissionCode driver command (or AddMissionCode or RemoveMissionCode ) and choose the mission code to assign to the current driver train. You can also do the same in the DriverSetup rule to insert SetMissionCode driver command in a scheduled driver order bar.

[[File:Help-missioncodemanager-rule-img08.png]]

=== Train Mission Codes : how to assign a code to an interlocking tower and path ===

The last step is now to assign mission codes to Interlocking Tower Paths.

In order to do so, just select the interlocking tower page by clicking on the interlocking towers tab. Mission Code Manager will now display the list of all available interlocking towers in the current session :

[[File:Help-missioncodemanager-rule-img03.png]]

Then to select an Interlocking Tower Path in an Interlocking Tower, just click on the interlocking tower view paths link you want to display. It will then display the Interlocking Paths page with all the defined paths in the selected Interlocking Tower.

''Since release 28, this page has also now a link to globally enable or disable the path auto assignment standard routine which is automatically called when a train is on approach of a signal at 0.5 mile. With the option disabled no path auto assignment is done for train with mission codes and explicit path assignment must be done using ITSetPathXXX, ITMCAssignNextPath, path trigger or follow path options
''

[[File:Help-missioncodemanager-rule-img04.png]]

And finally, to display, add or suppress mission codes assigned to a path, just click on the view details link for the path you want to look at.

[[File:Help-missioncodemanager-rule-img05.png]]

On this path details page, you have some links to add new mission code to the current selected path or to remove some already assigned mission codes.

It is also possible to define a priority between 1, 2 and 3 for a path mission code assignment. This priority will be used when the Mission Code Manager has to activate a path for a train at an entry signal. If several paths are available at the entry signal and the mission code is valid for several of these paths, the mission code manager will try first to activate an eligible path (available path with mission code assigned to this path) with mission code priority 1, then 2 and last 3. If several paths are eligible for a mission code at the same priority level, the mission code manager will try to activate a randomly chosen path between paths with same priority.
This feature may be usefull for passengers train at a station or goods train at a yard : mission code manager will first try to activate one of the eligible paths with priority 1. If none are activable, it will then search for paths with priority 2 and then priority 3. Using adequate priorities, you can send a passenger train on a path to a preferred platform, with the opportunity to send the train to another platform using another path if the first one is already occupied.

It is also possible on this page to edit the auto assign AI flag and auto assign flag for the current path.

The option follow path is an option by default set to none, that can be set to either "on path activation" or to "on train entering path". When the option is set to "on path activation", when the current path will become active, Mission code manager will search forward for the next entry signal after the current path exit signal, and will try to activate a new path (follow path) for the current train at this new entry signal using the same assignment process than above. With the on train entering path, it is only when the current train enters the current path (leaves the current path entry signal) that the follow path at the next entry signal is searched. Using these options you can in fact chain paths activation following either the activation or the progression of the train in the previous paths.<br>

You can set a global default value for the follow path option, which can be overridden by a default value at the path level, which can also be overridden at the mission code level.

Chaining path activation by using follow path option is limited by the current follow path depth. The follow path depth defines the maximum number of paths activated but not entered that a train can have. If a follow path activation is requested but the follow path depth is exceeded, the follow path activation will be delayed until the current number of paths activated but not entered will decrease under the follow path depth. The follow path request is not lost but is only delayed.

There is a global default follow path depth which is set on the initial mission code page. This value can be overridden at the mission code level by entering another value for any mission code on the initial mission code page.

There is another way to add/remove mission code eligibility for a path. This can be done using the "view paths" link for a specific mission code on the initial mission code page. This link will display all the available paths in all towers :

[[File:Help-missioncodemanager-rule-imgallpaths.png]]

=== Train Mission Codes auto path assignment : how it works ? ===

And now that you have defined your mission codes, assigned them to trains and to specific interlocking tower paths, how all these will work together for path assignment.

Quite simple: when a train approach an entry signal, then interlocking tower will call the mission code manager rule as a listener to assign a path for the current train.

The mission code manager will look at the incoming train and retrieve all the mission codes assigned to the train. If the train has no mission code, it will return to the interlocking tower that it does not support the train and the normal interlocking tower processing will be done for this train with no mission codes. But for a train with some mission codes, the mission code manager will return to the interlocking tower that it takes care of the current train path and that no further processing is needed.

Then the mission code manager will look at all the available paths at the current entry signal and will extract only the list of all available paths at this entry signal eligible for one of the current train mission codes set. A path is eligible for a train only if there is a matching mission code in the list of the path supported mission codes.

To choose the target path, Mission Code Manager will then look in this list of eligible paths for paths with matching mission code at priority 1 then 2 then 3 and will try to assign a path not occupied in the priority order. It is smart enough that if there is only one path available at an entry signal, it will assign this unique path even if no mission code has been assigned to it. If there are several paths available and no paths are eligible the train will remain stuck at the entry signal.

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

So when you have configured all your mission codes, trains and paths assignment, you only need to run your session and the paths will be auto assigned based on one of the current train mission codes and following your paths mission codes assignment configuration defined in Mission Code Manager.

=== Train Mission Codes auto path assignment : and what are path triggers ? ===

PathTriggers are standard trackmarks or triggers that help to assign path following the method above when the standard assignment routine called when the train approaches the entry signal is not convenient. PathTrigger enables to do the same assignment process, but earlier or later than with the standard routine called when the train approaches then entry signal (about 1 mile before reaching it). It enables also to assign manual paths (paths with the AI auto assign and Player auto assign flags not set).

To assign paths earlier, you need only to position a trackmark or trigger on the track to the entry signal before the 1 mile standard distance for path assignment. You then need to register in the pathtrigger tab of the mission code manager rule the path trigger you are using. And that's all. When a train will reach a registered path trigger, MissionCode Manager will be called, will look forward for the entry signal along a distance of maximum 10 km and when the next entry signal is found it will immediately launch the auto path assignment process as if the train had already reached the 1 mile distance to the signal.
This way you can fire some early auto path assignment before the standard signal reached routine is called.

Path assignment when fired by a PathTrigger is a little different from standard path assignment. As with standard assignment, it will first search for paths with AI auto assign flag or Player auto assign flag set for AI trains or Player train, but if it does not find any available paths, it will then do a second search where it will also look to manual paths (paths with no AI auto assign or Player auto assign flags set). This dual step search is mainly done to enable late path assignment. To do some late path assignment (later than the standard method called at 1 mile from the entry signal) , you need to only use manual paths at the entry signal. When the standard routine will be called at 1 mile from the entry signal, it will find no available paths and so will not assign any path for the train. When later, the train will reach a path trigger, the process will restart, will still find no available paths with AI auto assign or Player auto assign flags set, but it will then look to manual paths and will then assign a path between the eligible manual paths at the entry signal. Using this feature, you can also do some late auto path assignment but only if at the entry signal there are no paths with the AI or Player flag set.

[[File:Help-missioncodemanager-rule-img09.png]]

PathTriggers are optional and need to be used only when the standard path auto assignment routine fired when a train approaches an entry signal is not convenient for your session. Most of my sessions using Mission Code Manager do not have any path trigger, but sometimes in some specific cases path trigger may be very usefull for some specific train behavior.

There is also in the package a driver command ITMCAssignNextPath ( <kuid:61392:8202> ) that will do the same processing as a path trigger on the current train when the command is executed. This driver command may be usefull for train stopped at a platform or a yard to start some auto path assignment process chain with follow on options.

=== Train Mission codes : some other miscellaneous features ===

Another usefull feature is on the interlocking paths list display. The interlocking paths are displayed in high green when the current selected mission code has been added to the interlocking path. It is displayed in low green, when there is only one path available at the entry signal, and in this case Mission code Manager is smart enough to assign the unique path at run time under driver for any mission codes. And the path name is displayed in grey, when several paths are available at the entry signal but the current selected mission code has not been assigned to this path. On the example above, SouthV4 and SouthV5 have selected mission code MONGAR in their mission codes assignments. SouthV2 is not eligible for mission code MONGAR. And V1South, v2South, v3South, v4South, V5South have all a unique path defined at their entry signal that will be selected for any mission code train. This path list page screen supports filtering on both interlocking tower and mission code. You can also select "no filtering" for the interlocking tower, and all the available interlocking towers and paths will be displayed with the high green, low green or grey color and it can be usefull to check for a mission code what are the paths eligible and not.

I think that it is all what is needed to use Train Mission code.
I hope you will enjoy this new rule to help you for interlocking tower path assignment.
And do not hesitate to post in the forum if you need some help or only to make some some comments.

Regards.
Pierre GUY (61392)

[[Category:Help|MissionCode Manager]]
[[Category:Rules]]
{{FUN-bot}}

File:Help-missioncodemanager-rule-img05.png

2019-02-17T09:38:42Z

Pguy: Pguy uploaded a new version of "File:Help-missioncodemanager-rule-img05.png"

Screen capture for assigning a mission code to a path