4. Hints and Tips
Here are some common sense hints and tips about how some of the new features in this release work. By reading these, you will be able to get the most out of your TRS2004:SP2 experience. As well as that, we will be adding tutorial sessions to the Trainz Exchange over the next few weeks and months that further demonstrate what SP2 can do.
4.1 Portals
The portal is one of the most exiting new features in SP2 and allows for the creation of more interesting sessions, however it does require a bit of common sense and understanding to use effectively. Here are some notes to keep in mind when using the portal.
AI end Emitted Trains:
The biggest and most noteworthy limitation is the emitting of trains and how that relates to the route outside the portal. When emitting a train, the portal pushes it out vehicle by vehicle and that train is under total control of the portal until the last vehicle has been pushed out and reached a trigger around 50 metres in from the entrance. This means that until a train has left the portal's control, it is being moved along without regard to the junctions, trains and signals out there on the map.
This can obviously become a problem with long trains. It wasn't really feasible to do this another way with integrated AI or anything too fancy. The portal does check its own track for presence of other trains, but it can't see outside signals/junctions.
Storage of Trains:
A portal can remember a total of 16 consists. Up to 8 of those 16 consists can be set as being produced consists in Surveyor. This means that if a portal's consist storage has reached its capacity of 16 consists, it will still consume a train (if configured to do so), but that consumed train won't be remembered. When a consumed consist is emitted, it will be deleted from the portal's consist storage database so another consist can take its place if needed.
Emitting to Another Portal:
The portal allows you to specify another destination portal to emit consumed consists from. When specifying the destination portal, be very careful to ensure you get the name exactly right. The settings of whether or not trains can be emitted/consumed in the destination portal will not be considered with this option - the portal here will simply directly instruct the specifies remote portal to emit the consist, regardless of that remote portal's settings/restrictions.
Timing:
When specifying delays in minutes for periodic consist emissions, the time is always done in real time and not game time. So regardless of whether you are running Trainz in real-time or an 8X clock, the portal will still wait in real time.
Portal is not a Drive-Thru:
You are not meant to connect a track at the lower-end of the portal. There is nothing to stop you from doing so as we can't currently enforce that, but we do try to make it quite obvious. The same situation applies to the passenger platform on the wharf - it is meant to be accessed from one end and hopefully the shape of the wharf industry scenery item would have made this obvious.
Rejected Consists:
If filtering of train consists is enabled or the portal is configured to not consume any consists, this means stray trains that enter the portal will be ignored. The portal should halt its own operations until the stray train has either been taken out by user or driven itself out. The portal will not get rid of stray rejected trains.
Orders on Exiting Trains:
Once a train has finished being produced, the portal hands it over to its driver (one will be chosen at random if the consist doesn't have one) and then go on and follow driver commands as usual. If the driver has no commands to follow, the train will sit their idle blocking access to the portal until you either drive it out yourself or give it some orders.
Slow entry of Trainz under AI:
When under AI driver control, the driver will appear to be entering the portal slowly at first. This is because it sees the end of the line ahead and is not going to rush in when the end of line is in sight (see my comments above on Drive-Thru). Once the first vehicle has reached a trigger some 50 metres in, the portal script takes over and it will push the train along and delete it vehicle by vehicle. You can drive in yourself going a bit faster than AI would and get away with it no problems, by going in at very high TGV-like speeds is tempting fate.
4.2 New Rules
Several new rules have been introduced with SP2 to help with the construction of sessions.
Consist Check Rule:
The Consist Check Rule operates in a continuous cycle waiting for any consist on the route matching its settings to exist. When such a consist exists, the rule will switch itself to a complete state and will start its child rules. While in complete mode, the rule still monitors consists and when no consist matching the specification can be found, the rule reverts back to its incomplete state. As such, the rule can operate continuously like this and through use of nested child rules, can be used to initiate something else like the playing of a .wav file every time a consist matching specification exists.
Resource Check Rule:
This rule operates in an identical manner to that of the Consist Check Rule except that it monitors a queue in a specific vehicle/industry. When the queue reaches the rule's required specifications, the rule reaches a complete state and activates child rules. When the monitored queue is no longer matching the specification, the rule goes back to its incomplete state and resumes monitoring the queue.
Trigger Check Rule:
This rule operates in an identical manner to that of the Consist Check rule except that it monitors one or more track triggers (not to be confused with industry triggers) for the presence of a train matching the rule's train filter settings. When any one of the triggers has a train matching the specification on it, the rule reaches a complete state and activates its child rules. Once all triggers are clear of any train matching the specification, the rule goes back to its incomplete state and resumes monitoring the triggers.
Note that this rule effectively makes the existing Trigger Rule redundant as it can do everything the Trigger Rule can plus more.
4.3 Some Background Notes on Driver Artificial Intelligence
The AI in SP2 has been significantly enhanced from SP1 and there are some important points that you need to understand so that you can better appreciate just how the AI functions and why it makes the decisions that it does.
First and foremost, the AI in Trainz operates from the perspective of a single driver. That is, each driver's 'AI' has a goal in mind and it will do what it can to reach that goal. In this respect drivers operate autonomously and do not communicate or interact with one another. This is where Trainz differs from a real world dispatcher.
Also in the real world a dispatcher has a 'global' view of the operations and movements in progress and makes decisions based on this. The Trainz codebase however operates on the basis of individual drivers performing 'path to destination' planning on the fly. This approach can (and likely will) lead to some decisions from time to time that you may not agree with. It's worth noting that Trainz has always operated like this and adding a fully functional dispatcher 'planning and pathing' module would have added a significant amount of time and was beyond our scope for SP2.
Driver path planning can become complex because of the fact that trains move about a route pretty much all of the time. Therefore when a driver tries to find a path to a destination he must assume that any trains that are blocking him will probably have moved by the time he arrives and as such a driver does not 'see' trains on a stretch of track as a potential obstacle.
Also, because drivers do not communicate with one another, a driver performing a path planning operation does not know what other drivers are doing or indeed intend to do. He is operating 'on his own' as it were. Problems can arise when that driver comes up against a red signal caused by another driver moving on a conflicting path. In this instance both drivers would have been moving toward their destinations and both would have been unaware that they were about to come upon one another. This is what we mean by the term "operating autonomously".
Given all of the above the AI in Trainz can be defined as having three distinct functions. First is path planning to a destination. Second is speed control whilst en-route and the third is conflict resolution after it has occurred. The Trainz AI does not perform pre-conflict resolution; this would require a fully pre-planned pathing environment and also a conflict prediction and resolution system based on known paths, neither of which is currently supported in Surveyor.
All of our efforts for SP2 have concentrated therefore on these three areas of AI. Given the current codebase and the method of operation outlined above, the AI in Service Pack 2 is about as good as it's going to get. Any further improvements would require a full rewrite, which is of course what we are doing for RSP (Rail Sim Pro).
Each of the three sections of AI has been improved in SP2 as follows:
1 - Path planning:
The addition of the 'drive via trackmark' command means that you can in essence override the default path forcing a train to drive a particular way. In fact Trainz is still path planning to the trackmark, but by placing the markers fairly close together it would be very unlikely indeed that a train would choose another route. Since trains do not slow down at a 'drive via trackmark' (but instead maintain their speed) it's quite easy to string a few together to 'force' a path.
In addition to the above SP2 now allows you to specify a particular track as a trains preferred track. To understand how this functions and to give you a better understanding of how Trainz does its path planning a few explanations are in order.
Firstly, and most important of all, a train will always take what it 'sees' as the shortest path to the destination. This calculation is distance based and does not include things like the speed limit of a track. The definition of the word 'sees' though is the key to path planning and it's by manipulating what a train 'sees' that gives us some degree of control.
Given two tracks of the exact same length a train will choose either to get to its destination. However, if one of those two tracks were a preferred track for that train all the path planning system does is to multiply the preferred tracks distance by a factor smaller than 1.0. Once this is done the preferred track now 'appears' shorter and hence it will the one chosen by the pathing system.
The bias that is applied to track length calculations is used in many cases in Trainz. For example, where a train must reverse to get to a destination the bias makes reversing show as a greater distance so that it's less preferred. Pathing around a blocked track has the blocked track showing as longer and finally as I've already mentioned track preferences (referred to as a track priority in game) also effect the length calculation.
Given the above it's important to remember then that a path is simply a preferred path based on distance calculations that have been biased under certain circumstances. It works most of the time but there will always be ways you can fool it. By describing to you how the system works it's our hope that you will be able to use this knowledge to better plan your layouts so as to help the pathing system do its job.
2 - Speed control whilst en-route:
We've spent quite bit of time on this section of the code and we're sure you'll see a number of improvements. The main improvements relate to the speed that AI trains accelerate and decelerate. In SP2 it's now much more prototypical, but still with a slant towards playability. We've also added some driver AI to help them better understand what distance they will need to stop based on the loco power, train mass and gradient.
What this means is that if you've placed your signals too close together, your trains may overshoot their target . If you find trains unable to brake in time it's almost certain that a real train couldn't have done so either and you probably need to move your signals a little further apart or introduce speed signs (causing a slowdown) a little earlier.
If a driver does SPAD (Signal Passed At Danger) in SP2 he'll now send you a message to that effect and stop. Then he'll send you another message saying that he is continuing his schedule in 10 seconds.
3 - Conflict resolution:
In SP2 conflict resolution has been enhanced with trains having the ability to re-path plan should they become blocked. In addition we've greatly increased your situational awareness by providing much better error messages and driver information. Now you can quickly see what's causing a problem and understand what you may need to do to resolve the situation.
Whilst the AI will often figure out conflict resolution on its own, there are times where you may want to intervene. Simply use the "Stop Train" command, solve the conflict by manually driving the train, then use the "Continue Schedule" to put the AI back in charge.
