Red Signals - Only One Train on Route?

If Trainz is laying out the route on the fly, I have seen that. I have also seen the switches set when entering driver mode which is probably indicative of the train being with the the "calculate" zone already. My routes are heavily treed with a full complement of assets to fit the functional need of a town based upon its size.
So, accepting all of that the remaining question is why does the train go through such a time consuming ballet of slow to 2mph, then 1 mph, then 0 and GO. Is this just a bit of theater to mask what might be a 2 or 3 second stop while the program catches up with route calculation.? Surly it does not take 30 seconds to calculate through to the next switch, or set of switches, if they are within the "to be calculated" zone. While the behavior is annoying and unrealistic at least it tell me that to maximize my $70 investment I need to spend several hundred dollars to have it perform properly. Since my "stuff" is about 5 years old I need to take the hint. Thanks for the insight.
Wait 2 or 3 seconds to calculate a train path and set all turnouts seems to me ages for a modern PC. Even if your route has 10,000 junctions, it can be represented by a fairly simple data structure like a tree or a graph. In a graph it does not matter whether two junctions are separated by 20 feet or 20 miles of track - they are merely two nodes identified by a bunch of simple properties. Any such data structure can be computed in matter of microseconds, unless Trainz uses extremely inefficient algorithm.
 
AI on 95720 TR19: With only one train on an entire route why would that train, operating under AI Session Rules, encounter ANY red signals? There is no occupancy by engines/locomotives or cars/wagons. A logically sterile environment.

I have encountered this on all previous versions that I have used.

I also noticed this behaviour in TS12 on correctly signaled routes. I think this has something to do with making trains more life-like - when approaching a diverge signal, the driver has to stop to visually inspect the track ahead.
 
Nothing like a programmer creating a "version of reality". I suspected that as well but with today's PC power reality can be conditional not a set of fixed routines. Time for Tony and his crew to take the risk and dig into the AI code. All of the "controlled" behavior we see seems without reason and was just a crude attempt years ago to add a small amount of reality. That has now become a liability. There are enough rail operations people on here to offer real conditions that AUTHORS can incorporate in a much more sensible manner.

As a non-rail person how is a route "pre-signaled" in real life? If a train crosses 20 switches in a planned journey, who and when are the switches set? Maybe Tony needs a "railroad consultant" to tell his crew what really happens.
 
Hi

If you want AI trains to act as they do in real life then why don't you use Enhanced Interlocking Towers and Mission Codes? These play the role of dispatcher and set the routes that you have programmed into them. If trains don't do what you think they should then it is usually because you haven't given the correct instructions to them. I appreciate that you have to put a bit of effort into setting it all up but at least it saves your blood pressure from going through the roof when the AI doesn't do what you think it should do. It isn't even necessary to set the whole route up with EITs but you can just use them where the AI has difficulty.

If you don't like the EITs then there are at least two other pathing rules and their driver commands that you can use instead.

If setting paths isn't your thing then I always found that the success of AI depended on the amount of time and effort that you put into setting them up. For example in a yard make sure that all the switches are set in Surveyor to take a train into the outermost track as this means that a train entering or leaving one of the middle tracks only needs to throw one switch to find its path. I always go through a route that I'm going to use and set the switches in all of the yards and stations in this way and also make sure that all the switches are set to allow a train to travel the main line without having to throw a switch. This minimises the amount of route setting that the AI needs to do. Half an hour spent preparing the route in this way can save you hours of frustration later on.

With regard to signalling I suggest that you have a look at prototypical routes such as the Mojave Sub Division or any of Jointed Rails routes such as Midwest Grain. I learned all I know about US signalling from studying the way these routes were signalled (I'm UK based so I can't check how it's actually done on the ground).

Regards

Brian
 
Tony mentioned somewhere that the AI code needs to be revamped at some point and will happen. His post somewhere here says that this is a major undertaking and requires a lot of work so that things don't get broken completely.

Part of the problem we are seeing is the revert to T:ANE SP1 driver behaviors. If anyone remembers, in T:ANE SP2 we had stalled drivers due to implementation of some new code. When SP3 came out, we were returned to "normal" so at least our AI are running again. This normal, if we want to call it that, is working albeit a bit clunky.

I use Ecco's method and have used that for years. I don't seem to have too much of a problem with AI until they get to complicated track layouts such as yards and major route junctions. It's then they sit there and figure out where they're heading. I find that if I go ahead and set the switches for the driver I am driving with, barring no other drivers are in the vicinity, my driver will move unimpeded across the map at track speed.

As a general observation, I will noticed that the AI behavior overall changed after the introduction of EITs as though the program requires them to work optimally rather than use them optionally. Once we got the EITs the normal behavior, if you can call that normal was never the same.
 
This arrangement will not work if you have 2 trains traveling the same direction and if you wish the faster train to overtake the slower one. Personally, I use track direction markers sparsely, because they tend to make my routes less versatile.
I agree. But my engineers just plod along one after another. The only passing is when one is off the mainline loading or unloading product.

The purpose of my passing sidings is to provide oncoming trains a way to safely pass by each other. Management has decided that making the entire route dual track is just too expensive.
 
Wait 2 or 3 seconds to calculate a train path and set all turnouts seems to me ages for a modern PC. Even if your route has 10,000 junctions, it can be represented by a fairly simple data structure like a tree or a graph. In a graph it does not matter whether two junctions are separated by 20 feet or 20 miles of track - they are merely two nodes identified by a bunch of simple properties. Any such data structure can be computed in matter of microseconds, unless Trainz uses extremely inefficient algorithm.
It gets a little more complicated when there are twenty other trains on the route all going in different directions.

However, I do agree that taking minutes to set a signal is inexplicable.
 
AI managing multiple trains

It gets a little more complicated when there are twenty other trains on the route all going in different directions.

However, I do agree that taking minutes to set a signal is inexplicable.
In case of multiple trains it is best to solve this problem as in real railways. Divide route into sections of track protected by signals and then manage access to each section by the mean of trains order and priority. Once you devise correct logic for a single section, you can apply this logic to many sections, no matter how big your route is. Of course, there can be a deadlock, if there are not enough sections or too many trains.

Yesterday, I had AI controlling 2 trains approaching from opposite directions. Both trains went to a standstill, while switching one of the junctions between them would allow a swift passage. This junction had been locked by one of the trains. AI kept locking this junction forever. Very dumb behaviour indeed.
 
Back
Top