This is part 2 of 'Using the Trainz AI in sessions'. Please refer to Part 1 for simpler techniques.
Breaking up trips at appropriate locations using intermediate trackmarks
Using '(drive / navigate) via trackmark' commands to set waypoints for the AI to help it find the path you intend it to use to get somewhere is a straightforward concept. But this is not the only effect that breaking up an AI's journey into sections will have. Remember that the AI command chooses a route for the train to take right at the start when the command is first executed. By breaking the journey down into multiple sections across multiple driver commands, you allow it to make the decisions for the later sections when it gets there, rather than planning the entire route all at the beginning.
Consider the example of an AI train needing to take a loop to overtake another slower AI train. The slower train might be stopping regularly on the mainline (e.g. in station platforms), and a following fast train needs to take a loop to overtake when it catches the slower train, but should continue on the mainline in other cases.
You might approach this by issuing multiple 'navigate via trackmark' orders to the fast train – each one heading to a trackmark just before the points at each station. If there is no train on the mainline, it will continue through the station without taking the loop. When there is a train on the mainline, it will take to the loop to go round it. By delaying the decision until the train is approaching each station, the obstacle avoidance properties of the 'navigate' command can be used to choose the correct path, even in a mainline situation.
An intermediate '(drive / navigate) to trackmark' order can also be useful in some circumstances. Even though 'drive to' is typically used when stopping at the location, the fact the train slows right down and approaches the track mark very closely might be important. Consider a train which needs to take a junction, and will route across oncoming AI traffic. You want it to make the call as late as possible, to avoid it taking locks on the junctions on the other line for too long. And as it is taking a slow speed divergence through a series of points anyway, the behaviour of the train slowing down on approach is realistic anyway.
When deciding where to break a trip, understanding how the AI will drive based on the list of instructions is important.
Once a driver command has generated a list of instructions, it executes this list in sequence. This list is a list of junction directions followed by a target object (where the command intends to stop), which is commonly a trackmark or industry.
Assuming the next object in it's path is a junction, it will attempt to take a lock, and set it in the direction it wants to travel over it.
Each time it reaches close enough to the junction that it would start braking for it, it takes the next junction in it's sequence. This braking curve means it will lock junctions further ahead at high speed than at low speed.
Note that this means an AI will always try to get a lock on the next junction no matter how far away it is, unless the current driver order finishes before the next junction. This junction locking behaviour can be a problem for routes with very few junctions, e.g. a single track line with a few passing loops. You can prevent this by making the AI '(drive / navigate) via trackmark' with a trackmark that is just before the problem junction. The AI will then only try to lock the junction when it is within braking distance of the trackmark.
There is normally a signal on approach to a cluster of junctions. If the signal is red, the AI will be braking not because of the junction, but because of the signal. So instead of trying to lock more junctions in sequence, it will only lock the first one after the signal, and then come to a stand at the signal waiting for it to change.
If the signal is not red on approach, the AI may start locking more junctions as each one gets into braking range. Because Trainz signals clear opportunistically (they don't know the route that the approaching train is intending to take, so they report for the currently set route) the signal may drop to red in front of the AI if it then sets an incomplete path across the junction. Depending on the distance between the signal and the junction, the AI may even be unable to stop before the (newly red) signal.
You can force an AI to slow down by giving it a '(drive / navigate) to trackmark' order. It will approach the trackmark slowly, expecting to stop, and then finish the order and start the next one.
When an AI is sat at a red signal, it will look at the object the signal reports as the reason for being red. If it is a train, the AI will wait patiently for the train to move. If the signal indicates it is red because a junction is set against the path ahead, the AI will try taking a lock on this junction and changing it – even if that junction isn't the next junction, and even if it isn't on the AI's path.
It is possible that this will result in a clear path – but it may not be the one the AI intends to take. The AI can then continue, but if it does not cross the junction it locked as part of it's future movement, the lock will not be released until the completion of the entire driver order. If this takes a lot of time (e.g. half an hour to drive to the next location), then this may cause following AIs to be delayed (waiting for a lock that will not be released for some time).
If you are experiencing stuck junction locks left behind, you can place a trackmark just after the cluster of junctions, and tell the problem AI to '(drive / navigate) via trackmark'. This will make sure the stuck lock is cleaned up sooner, as the command has finished and the AI will release all it's locks. You can also fix this by changing the default direction of the junction (so it doesn't see the problem junction reported by the signal as the reason for the red). Junction direction can be pre-set in the route, session, or changed at an appropriate time from the session rules.
A change in default junction direction may also help stuck AIs which don't manage to set a working route across a particularly complex junction. It is often the second junction after the signal that needs to be set the other way in this case. Careful choice of default junction direction may also help in the case of dropped signals. If the junctions are not pre-set for a valid route, the AI is far less likely to be presented with a false clear indication.
Breaking up trips at appropriate locations using intermediate trackmarks
Using '(drive / navigate) via trackmark' commands to set waypoints for the AI to help it find the path you intend it to use to get somewhere is a straightforward concept. But this is not the only effect that breaking up an AI's journey into sections will have. Remember that the AI command chooses a route for the train to take right at the start when the command is first executed. By breaking the journey down into multiple sections across multiple driver commands, you allow it to make the decisions for the later sections when it gets there, rather than planning the entire route all at the beginning.
Consider the example of an AI train needing to take a loop to overtake another slower AI train. The slower train might be stopping regularly on the mainline (e.g. in station platforms), and a following fast train needs to take a loop to overtake when it catches the slower train, but should continue on the mainline in other cases.
You might approach this by issuing multiple 'navigate via trackmark' orders to the fast train – each one heading to a trackmark just before the points at each station. If there is no train on the mainline, it will continue through the station without taking the loop. When there is a train on the mainline, it will take to the loop to go round it. By delaying the decision until the train is approaching each station, the obstacle avoidance properties of the 'navigate' command can be used to choose the correct path, even in a mainline situation.
An intermediate '(drive / navigate) to trackmark' order can also be useful in some circumstances. Even though 'drive to' is typically used when stopping at the location, the fact the train slows right down and approaches the track mark very closely might be important. Consider a train which needs to take a junction, and will route across oncoming AI traffic. You want it to make the call as late as possible, to avoid it taking locks on the junctions on the other line for too long. And as it is taking a slow speed divergence through a series of points anyway, the behaviour of the train slowing down on approach is realistic anyway.
When deciding where to break a trip, understanding how the AI will drive based on the list of instructions is important.
Once a driver command has generated a list of instructions, it executes this list in sequence. This list is a list of junction directions followed by a target object (where the command intends to stop), which is commonly a trackmark or industry.
Assuming the next object in it's path is a junction, it will attempt to take a lock, and set it in the direction it wants to travel over it.
Each time it reaches close enough to the junction that it would start braking for it, it takes the next junction in it's sequence. This braking curve means it will lock junctions further ahead at high speed than at low speed.
Note that this means an AI will always try to get a lock on the next junction no matter how far away it is, unless the current driver order finishes before the next junction. This junction locking behaviour can be a problem for routes with very few junctions, e.g. a single track line with a few passing loops. You can prevent this by making the AI '(drive / navigate) via trackmark' with a trackmark that is just before the problem junction. The AI will then only try to lock the junction when it is within braking distance of the trackmark.
There is normally a signal on approach to a cluster of junctions. If the signal is red, the AI will be braking not because of the junction, but because of the signal. So instead of trying to lock more junctions in sequence, it will only lock the first one after the signal, and then come to a stand at the signal waiting for it to change.
If the signal is not red on approach, the AI may start locking more junctions as each one gets into braking range. Because Trainz signals clear opportunistically (they don't know the route that the approaching train is intending to take, so they report for the currently set route) the signal may drop to red in front of the AI if it then sets an incomplete path across the junction. Depending on the distance between the signal and the junction, the AI may even be unable to stop before the (newly red) signal.
You can force an AI to slow down by giving it a '(drive / navigate) to trackmark' order. It will approach the trackmark slowly, expecting to stop, and then finish the order and start the next one.
When an AI is sat at a red signal, it will look at the object the signal reports as the reason for being red. If it is a train, the AI will wait patiently for the train to move. If the signal indicates it is red because a junction is set against the path ahead, the AI will try taking a lock on this junction and changing it – even if that junction isn't the next junction, and even if it isn't on the AI's path.
It is possible that this will result in a clear path – but it may not be the one the AI intends to take. The AI can then continue, but if it does not cross the junction it locked as part of it's future movement, the lock will not be released until the completion of the entire driver order. If this takes a lot of time (e.g. half an hour to drive to the next location), then this may cause following AIs to be delayed (waiting for a lock that will not be released for some time).
If you are experiencing stuck junction locks left behind, you can place a trackmark just after the cluster of junctions, and tell the problem AI to '(drive / navigate) via trackmark'. This will make sure the stuck lock is cleaned up sooner, as the command has finished and the AI will release all it's locks. You can also fix this by changing the default direction of the junction (so it doesn't see the problem junction reported by the signal as the reason for the red). Junction direction can be pre-set in the route, session, or changed at an appropriate time from the session rules.
A change in default junction direction may also help stuck AIs which don't manage to set a working route across a particularly complex junction. It is often the second junction after the signal that needs to be set the other way in this case. Careful choice of default junction direction may also help in the case of dropped signals. If the junctions are not pre-set for a valid route, the AI is far less likely to be presented with a false clear indication.