TS 2022 plagued by drivers who back up when they should not do do.

JonMyrlennBailey

Well-known member
This is a long-standing issue that has not been a problem for me, for the most part, in TANE SP4 and the final build of TS2012.

I've just sent my logs into N3V with the following notes:

Drivers back up their trains when they should not do so. Drivers on schedules are unwilling to wait behind or follow the lead train right in front of them when given the command to drive to/via a track marker directly ahead of them beyond the lead train. Drivers, however, will proceed forward to a track marker if there is no other train between them and the intended track marker straight ahead.


 
Last edited:
Steam version or the store version?

The Steam version has those issues that for some reason weren't addressed as they are in the N3V Store version which is Build 126280.
 
Steam version or the store version?

The Steam version has those issues that for some reason weren't addressed as they are in the N3V Store version which is Build 126280.
Mine is the downloaded store version. TS22 Platinum Build 126273

Please keep in mind that I have been editing the cloned version of another author's Route, namely, West From Denver, and have created a Session off of that. I could make my own test route from scratch and see if those problems persist.
 
Keep in mind that what we think of as a route with a single path can contain alternative paths. If a Driver is stuck by a blocked path, for whatever reason, the algorithm will try every other possible path to reach the next destination. If that reguires backing up, then that's that it will do. It's up to us as the designer to block every other path.
 
Keep in mind that what we think of as a route with a single path can contain alternative paths. If a Driver is stuck by a blocked path, for whatever reason, the algorithm will try every other possible path to reach the next destination. If that reguires backing up, then that's that it will do. It's up to us as the designer to block every other path.
I tried that by blocking alternate paths with a direction marker already. Drivers sometimes drive against direction markers paying them no mind. No dice. I have not had this issue in TANE SP4 even with complete closed-loop routes. By default in those older Trainz editions, drivers had been trying to only get to the track marker by taking the closest path to the marker and not by backing around a long way, sometimes 50 miles or more, to get to the marker in front of the train blocking the marker. I have plenty of closed loop routes in TS 2102 latest build and TANE SP4 that don't have this backing up issue. The algorithm for my edition of TS 2022 is obviously programmed haywire. Trainz programmers also should ensure drivers absolutely do not drive against direction markers. Treat them as a diode or one-way check valve that will admit electric current in one direction only. Drivers should be forced to wait behind trains ahead of them.

Are the "software engineers" for Trainz in kindergarten or preschool?
 
Last edited:
Drivers sometimes drive against direction markers paying them no mind.
Direction Markers are not absolute, in that they present a resistance value to a Driver who attempts to go against it, sort of like an electric diode. But even a diode can be overwhelmed if the voltage is high enough. Given multiple alternative paths, the one with the least resistance is the one that gets selected. If every other path is worse than the one with the Direction Marker against it, then from a logical point of view, that is the one that will be used. Perhaps you don't like it but then it is up to you to ensure that that situation doesn't occur.
 
Direction Markers are not absolute, in that they present a resistance value to a Driver who attempts to go against it, sort of like an electric diode. But even a diode can be overwhelmed if the voltage is high enough. Given multiple alternative paths, the one with the least resistance is the one that gets selected. If every other path is worse than the one with the Direction Marker against it, then from a logical point of view, that is the one that will be used. Perhaps you don't like it but then it is up to you to ensure that that situation doesn't occur.
These diodes are more like Zener diodes. A Zener diode works so that they act like a diode should until the voltage reaches a certain level then they flood and let that voltage out, usually to ground, but sometimes to shunt the voltage elsewhere for some other purpose much like the AI being taking an alternative route.
 
These diodes are more like Zener diodes. A Zener diode works so that they act like a diode should until the voltage reaches a certain level then they flood and let that voltage out, usually to ground, but sometimes to shunt the voltage elsewhere for some other purpose much like the AI being taking an alternative route.
Suffice it to say, this backing up behavior is not consistent with the real world of rail transportation operation. AI should be programmed like it was TANE SP4 in terms of direction and path logic. Take the shortest path to the track marker regardless of resistance levels encountered to do so. Short takes precedence over long, not weak resistance takes precedence over strong resistance. That Amtrak California Zephyr train does not back all the way from Salt Lake City to Oakland and all the way to Chicago backwards when there is a freight train derailment five miles ahead. It waits at Union Station five hours until the track ahead is cleared and then moves forward. I sat at the stupid Utah station back in 1986 for five hours as proof of that. I might have encountered less resistance had I got off the stupid train and hopped aboard an airplane to Denver instead.
 
Suffice is to say, this backing up behavior is not consistent with the rail-world of rail transportation operation.
The world of real rail transportation operation has human drivers, dispatchers and signallers who make "on the spot" decisions not based on algorithms or computer logic.

Ask yourself why the California Zephyr (which I have travelled on) uses a human driver (and, in some of the states it passes through, two human drivers) with dispatches/signallers setting signals and switches along the route? Why hasn't Amtrac or the freight line owners replaced those humans with ChatGPT or similar?

Yes, Trainz is much simplier and your routes/sessions are, arguably, not as complex as most real real railroads. The Trainz AI does not understand ALL the different rules, exceptions and operating procedures (some of them contradictory) that are found in ALL the world's railways. I find the fact that it can set a path (eventually) through a complex junction as well as control the speed of an unattended train to be a "neat trick". A trick that I usually find to be difficult to achieve manually.

In my experience it almost always comes down to the human session creator who has set the rules and driver commands, has placed the signals (visible and invisible) and switches, added the invisible markers (track, direction, priority and trigger) that the AI has to work with.
 
The world of real rail transportation operation has human drivers, dispatchers and signallers who make "on the spot" decisions not based on algorithms or computer logic.

Ask yourself why the California Zephyr (which I have travelled on) uses a human driver (and, in some of the states it passes through, two human drivers) with dispatches/signallers setting signals and switches along the route? Why hasn't Amtrac or the freight line owners replaced those humans with ChatGPT or similar?

Yes, Trainz is much simplier and your routes/sessions are, arguably, not as complex as most real real railroads. The Trainz AI does not understand ALL the different rules, exceptions and operating procedures (some of them contradictory) that are found in ALL the world's railways. I find the fact that it can set a path (eventually) through a complex junction as well as control the speed of an unattended train to be a "neat trick". A trick that I usually find to be difficult to achieve manually.

In my experience it almost always comes down to the human session creator who has set the rules and driver commands, has placed the signals (visible and invisible) and switches, added the invisible markers (track, direction, priority and trigger) that the AI has to work with.
Then again, why have I not had this backing-up problem with TANE SP4 and similar closed-loop setups?

Someday, American railroads, and automobiles, will become fully autonomous. It will take software geniuses to make this safe and feasible, for sure. NASA has operated spaceships that self-fly. Lockheed has built an L10-11 Tri-Star jumbo jet which has safely landed, and pulled up to a loading gate all by herself.
 
Take the shortest path to the track marker regardless of resistance levels encountered to do so. Short takes precedence over long, not weak resistance takes precedence over strong resistance.
That's not how it works, even in real life. If the shortest distance is through the middle of a busy freight yard, the consist will be routed around the busy areas and take another path. The resistance levels that you disparage are just a substitute for the decision making process that determines the best route and not necessarily the shortest route from A to B.
 
Then again, why have I not had this backing-up problem with TANE SP4 and similar closed-loop setups?

According to posts in these forums since "forever" there have always backing-up problems in all versions of Trainz (including in TANE SP4). You can certainly argue that the AI is better or worse in some earlier versions than in later versions. Using the "Navigate To" or Navigate Via" driver commands instead of the "Drive To" or "Drive Via" commands, for example, will increase your chances of backing-up.
NASA has operated spaceships that self-fly. Lockheed has built an L10-11 Tri-Star jumbo jet which has safely landed, and pulled up to a loading gate all by herself.
The SpaceX rockets can even land themselves back on Earth.

In WWII the USAAF converted a B17 bomber to fly under radio control to a target. The takeoff still required a pilot who bailed out after the aircraft reached cruising altitude. They even set up an early TV camera in the cockpit that transmitted a continuous image of the cockpit instruments to the remote pilot - that was radical stuff! It was only ever used on one mission where it was loaded with explosives (no wonder the pilot bailed out early) and rammed itself, Kamikaze style, into the target. It was later discovered that the target had already been destroyed in a previous bombing mission by the RAF using actual pilots.

In all these cases there is no crossing traffic, no "broken rails" or fallen trees/rocks across the tracks (a highlight of my trip on the California Zephyr was the driver and train crew having to leave the train to clear fallen rocks from the track near Denver).

Aircraft autopilots have had the ability to land without any human input for some years now. Takeoffs are the most dangerous part of any flight and are still controlled by the human pilots. Again these systems work when all possible problems, such as other aircraft on the taxiways or the designated loading gate suddenly becoming unavailable, have been eliminated.
 
That's not how it works, even in real life. If the shortest distance is through the middle of a busy freight yard, the consist will be routed around the busy areas and take another path. The resistance levels that you disparage are just a substitute for the decision making process that determines the best route and not necessarily the shortest route from A to B.

So, what I have to do now in this confounded TS 2022 is put each and every scheduled train on it's own dedicated siding in the staging area for holding until each train takes its turn to run on the mainline. In earlier versions of Trainz, I could simply have one long siding to put all the scheduled trains being held lined up one behind the other with each successive lead train's being periodically released on the mainline line. The lead train would drive to and hold at a track mark on the schedule and follow wait-for commands. Trailing train on this holding siding for time releasing trains in this fashion would just stand there and wait until the train ahead pulled forward. Hopefully, when a passenger train is stopped in Granby, Colorado westbound at the passenger train station on the mainline, any train that happens to be coming up close from the rear won't decide to stop and back up back toward Denver. I hate using portal-emitted trains.

No, in America, a train under way on a mainline will NORMALLY stop and hold for a train routinely stopped at a station or signal ahead until it is clear to proceed forward. Backing up is a special circumstance as in an emergency situation such as damage to the track ahead as from a train wreck.
 
No, you have to ensure that each and every consist has totally unambiguous instructions and a single possible path to get from A to B.

A slight paraphrase: "If instructions (words of command) are not clear and distinct, if orders are not thoroughly understood, then the designer (general) is to blame. " Sun Tzu
 
No, you have to ensure that each and every consist has totally unambiguous instructions and a single possible path to get from A to B.

A slight paraphrase: "If instructions (words of command) are not clear and distinct, if orders are not thoroughly understood, then the designer (general) is to blame. " Sun Tzu
I don't have to do anything. All I can say for now is I liked the TANE AI setup much better. I'm not about to butcher the West From Denver route to shreds. If I have even to run engines trains around at the ends of routes then so be it.
 
My main route is a series of islands, there is no alternative route so if they back up to find one it is a software problem.
Before the latest fix my consists would block bridges by trying to do just that.
Now all is well apart from the Schedule Library, frustrating.
It seems an easy fix but obviously not.
 
If I have even to run engines trains around at the ends of routes then so be it.
A "Trainz World" solution (i.e. an AI solution) to a problem will probably never match a "railroading world" solution to that same problem.

The history of computer science is full of stories about computers being given tasks by programmers but the end result was not what was expected. It is all too easy to blame this on "bugs" and computer "glitches" but the reality is often the fault of the-humans. Computers will always do exactly what the programmers tell them to do - unfortunately this is not always the same as what the programmers wanted them to do. Human logic and computer logic are often on different paths

The trick, as Martinvk points out above, is to remove all possible ambiguity from your instructions and the operating environment.

It seems an easy fix but obviously not.

Nothing in programming is ever simple and easy.
 
I am experiencing this problem too. I have adjusted how I schedule trains from my previous experience with TRS 2010.

Even on a route with dedicated double track, frequent track marks and directional marks, drivers have reversed direction passing thru red signals and ignoring directional marks.

My newest irritation involves following trains that stop and remain stopped in front of a green/proceed trackside signal. I have to restart every train, in addition to the driver who has already backed up 5 miles trying to drive to a track mark at any cost. So far I have resorted to using the delete this train command far too often.
 
Back
Top