Addressing Trains Going in Wrong Direction

[AdvancedApproach]

It's easy to blame the developer and others for our mistakes but in reality, 99% of the errors are user-caused. This isn't saying that there aren't bugs and believe me there are plenty of them in Trainz including some unexplainable behaviour that we cannot and will never be able figure out. We have to keep in mind that the AI will only do what we instruct them to do and not what we think we instructed them to do. We stare at the track marks, we stare at the commands, and our brain says things are okay but in reality, we've sent the AI down the wrong track both figuratively and literally no pun intended. Oh, these are probably the worst and most difficult things to find right up there and next to direction markers facing the wrong direction, by the way.

AI drivers will seek out the shortest path between points. What may appear to us to be a longer path is mathematically the shortest path even if it means taking, often the slowest trip through a yard at 5 mph, instead of taking the 65 mph mainline. The solution here is to place track marker somewhere in the middle of the mainline and instruct the AI to drive via or navigate via those track markers. This puts the AI well past the junctions so they're unable to take a trip through the yard then back up to hit the track marker they missed.

Direction markers really are helpful. They will not only prevent AI drivers from heading into tracks where we don't want them to go unless we drive there ourselves, if used like do not enter signs. They can also be used to direct the AI down a specific track. Us non-left-hand drivers need to use them more often than those in the left-hand driving world.

The other thing to watch for is signaling. I can't stress this enough. Learn the signal types inside and out and copy what is done in the real-world. Seriously. I have found 9 times out of 10 that the AI will follow the signaling pretty well and there are some exceptions where realistic signaling is impossible due to AI and we have to compromise.

In the end, remember that session building is easy, troubleshooting the session and debugging is hard and time-consuming. Depending up on the complexity of the session, this can sometimes take weeks and even months to work the bugs out.

Another thing is a train shouldn't get stuck just because the track maker they're instructed to go to is occupied or being approached by another train. If the signal indication isn't stop, then the train should just keep going. That's how it works in real life. The workaround is to utilize the autodrive command as the navigate to or via ones don't always work either. I'd like for N3V to address this and stop dragging their feet despite me submitting a ticket and bug report nothing has been done. Not even a reply within the last week.

 

[pware]

That's how it works in real life.

Not in my experience with real railways.

Another thing is a train shouldn't get stuck just because the track maker they're instructed to go to is occupied or being approached by another train. If the signal indication isn't stop, then the train should just keep going.

If a path for a train is occupied, both in Trainz and real life, then the signal indication will be STOP. In Trainz paths are set by the next destination in the drivers command list. If that destination is occupied then the AI will not simply ignore it and "skip" to the following destination (which may require using the exact same path anyway, which is occupied).

In real railways the first option is to wait until the track is no longer occupied. If that is not going to happen then a human controller steps in to redirect trains around the blockage (if that is possible) otherwise they have to wait. A few years ago after I was stuck in a train that was blocked by a failed train in the next section (in Trainz terms the destination trackmark was occupied), I asked an acquaintance who was a railway signaler why didn't they simply run the down trains on the up track to get around the problem. He very was clear in his response that that would only happen in a very serious situation, would require a great deal of planning, was highly risky and would end up causing more delays.

I'd like for N3V to address this and stop dragging their feet despite me submitting a ticket and bug report nothing has been done. Not even a reply within the last week.

Clearly Trainz is causing you much angst and frustration. N3V, a very small organisation, is not responding instantly to your every issue (I often don't get a response for a Bug Report or Help Ticket in under a week), and those issues you have are clearly far more important than anything else. I have noted that some of your past issues have been the result of your own misunderstanding of how things work, not "bugs" or "incompetence", as you claimed, by N3V. Perhaps it is time you took a long break from Trainz.

 

[AdvancedApproach]

Not in my experience with real railways.


If a path for a train is occupied, both in Trainz and real life, then the signal indication will be STOP. In Trainz paths are set by the next destination in the drivers command list. If that destination is occupied then the AI will not simply ignore it and "skip" to the following destination (which may require using the exact same path anyway, which is occupied).

In real railways the first option is to wait until the track is no longer occupied. If that is not going to happen then a human controller steps in to redirect trains around the blockage (if that is possible) otherwise they have to wait. A few years ago after I was stuck in a train that was blocked by a failed train in the next section (in Trainz terms the destination trackmark was occupied), I asked an acquaintance who was a railway signaler why didn't they simply run the down trains on the up track to get around the problem. He very was clear in his response that that would only happen in a very serious situation, would require a great deal of planning, was highly risky and would end up causing more delays.

Clearly Trainz is causing you much angst and frustration. N3V, a very small organisation, is not responding instantly to your every issue (I often don't get a response for a Bug Report or Help Ticket in under a week), and those issues you have are clearly far more important than anything else. I have noted that some of your past issues have been the result of your own misunderstanding of how things work, not "bugs" or "incompetence", as you claimed, by N3V. Perhaps it is time you took a long break from Trainz.

Except it isn’t my fault. If the block is clear then a train should keep going. How is it when I use the autodrive command the trains move just fine but the drive to or via track mark commands have issues then? What I’m saying is I’ve had trains get stuck despite a clear block signal indication. The signals should be what guides AI drivers, not anything else. Even @JCitron complained about the AI drivers becoming dumber when you add more trains on your route and the support system bogging down causing them to get stuck. He said it here: https://forums.auran.com/threads/add-traffic-to-all-lanes-increase-realism.181986/

As for them being a small organization, maybe they ought to hire more people. I’ve been hearing that excuse for the longest time.

 

[pware]

I have never had that issue when I add AI controlled trains to my sessions.

I make sure that everything is as easy as possible for the AI (which, for some reason, people seem to think is far more intelligent and experienced than a human railway signaler/controller/driver). Providing invisible signals (at least two) and lower speed markers before a visible junction approach signal. Using session rules to set and lock junctions and signals to prevent opposing movements until the target consist has cleared a section. This is how real railways work - road knowledge for drivers (the invisible signals and extra speed signs) and controllers setting a clear path that locks out other trains (session rules).

maybe they ought to hire more people. I’ve been hearing that excuse for the longest time.

Only if you are prepared to pay a lot more for the product. The funny thing about putting on more staff is that they expect to get paid, receive leave entitlements, employer superannuation contributions, workcover expenses, etc, etc (it varies between countries). It all adds up and will eventually go onto the ticketed price at the checkout. Then you will see an avalanche of complaining posts and insults in these forums.

You seem to think that every problem you have is someone else's fault (some are but in my experience many problems are user induced, including by me) and has to be fixed immediately by N3V - no week long delays in getting out the acknowledgement that they are at fault and that they are giving this their highest priority. I note your earlier demand that the UDS feature be removed because it was not working - it was working but you misunderstood how to use it.

Yes, there are lots of improvements that could be made to the existing versions of Trainz, There are lots of bugs that need to be fixed (no software is bug free) and there are new "glitzy" features that users are demanding should be added - and all of it done by yesterday. Concentrating on one (e.g. fixing all the bugs before adding new features, a commonly posted demand) to the exclusion of the other is a recipe for failure.

To quote from one source I consulted on the matter

This is why you should be constantly working on both [new] features and known bugs. And the only thing you should prioritize is which features to work on first, and which bugs are the most urgent to eliminate.

The trick is to find the balance between the two which inevitably means that the bugs will not be fixed fast enough and the new features will not appear as frequently - and the inevitable complaining posts.

The problem with selecting which bugs and which features is that every user will have a different opinion on which is the most urgent. N3V are certainly doing both (fixing bugs and adding new features) but they could never do it fast enough to meet everyone's satisfaction.

 

[AdvancedApproach]

I have never had that issue when I add AI controlled trains to my sessions.

I make sure that everything is as easy as possible for the AI (which, for some reason, people seem to think is far more intelligent and experienced than a human railway signaler/controller/driver). Providing invisible signals (at least two) and lower speed markers before a visible junction approach signal. Using session rules to set and lock junctions and signals to prevent opposing movements until the target consist has cleared a section. This is how real railways work - road knowledge for drivers (the invisible signals and extra speed signs) and controllers setting a clear path that locks out other trains (session rules).

I've done everything to make it easy for AI. Placed additional track markers, verified everything is properly set up from signals to junctions and everything else in between exhaustively and still have issues. Now some of them are my fault but I can't control N3V not wanting to speed up the process of finding a path to a destination even though there's a clear signal straight ahead. On this particular route of mine there's only two sets of crossovers but none in a location that would cause conflict. They are located towards the front or back end depending on which way you're traveling and are needed for adding on helpers and getting them coupled onto trains or to the staging area where they can be refueled and set aside for their next trip. From my experience they haven't caused any conflict. That part I can confidently rule out.

Only if you are prepared to pay a lot more for the product. The funny thing about putting on more staff is that they expect to get paid, receive leave entitlements, employer superannuation contributions, workcover expenses, etc, etc (it varies between countries). It all adds up and will eventually go onto the ticketed price at the checkout. Then you will see an avalanche of complaining posts and insults in these forums.

Like we don't already pay a lot already. If we have to pay more then so be it so long as the price increase isn't outrageous by my standards. As for all the things they expect to get will have to be earned. They might just outsource or use automation and AI like every other company seeing how the world is headed.

You seem to think that every problem you have is someone else's fault (some are but in my experience many problems are user induced, including by me) and has to be fixed immediately by N3V - no week long delays in getting out the acknowledgement that they are at fault and that they are giving this their highest priority. I note your earlier demand that the UDS feature be removed because it was not working - it was working but you misunderstood how to use it.

Yes, there are lots of improvements that could be made to the existing versions of Trainz, There are lots of bugs that need to be fixed (no software is bug free) and there are new "glitzy" features that users are demanding should be added - and all of it done by yesterday. Concentrating on one (e.g. fixing all the bugs before adding new features, a commonly posted demand) to the exclusion of the other is a recipe for failure.

To quote from one source I consulted on the matter


The trick is to find the balance between the two which inevitably means that the bugs will not be fixed fast enough and the new features will not appear as frequently - and the inevitable complaining posts.

The problem with selecting which bugs and which features is that every user will have a different opinion on which is the most urgent. N3V are certainly doing both (fixing bugs and adding new features) but they could never do it fast enough to meet everyone's satisfaction.

For the most part they are the fault of someone else. I have at times stated on mistakes me by me and corrected them or didn't understand how things worked. I did that on Discord about moving trains on S2.0 or the height not being at the default level. I had to go into the world origin and change it because of some inexplicable glitch when transferring from T:ANE to TRS22. Didn't recall ever tampering with it because I never mess with the world origin height but had to make adjustments for things to work out properly. I don't demand new features immediately. I expect for them to be flawless or not so faulty that they're rendered useless or break other perfectly flawless features and then try to deflect blame on us. Such as the trackside items becoming stuck because of something they did. Now they provided a fix, but it shouldn't have come to that in my opinion. Other users might demand immediate new features but not me, at least until they can demonstrate an ability to provide fixes or updates without causing more problems than they resolve. To rebuttal your point, concentrating on only new features while neglecting the bugs, which means exclusion of much needed fixes is also a recipe for failure.

 

[JCitron]

Yes, the AI will begin to fail over time and are more prone to do this when there are lots of them. On my very large custom route, a route I started in January 2004, I have about 30 active drivers, dozens of static consists, multiple portals sending out many drivers in addition to the 30 captive ones, and lots of destinations covering close to 189 route miles. With a route this large, things begin to breakdown. I consulted with N3V on this issue and they said yes, the AI subsystem needs to be rebuilt, but that is extremely complex a job and they do not have the resources to dedicate to the task at this time. The other issue they explained is fixing the problem as it stands will break things more and that's something that isn't good. As time as gone on, they have fixed a few things but not at the extent that they really need to do.

Creating a session is really programming using OOP, or Object-Oriented Programming. Instead of writing subroutines of code, this is already done for you and by you placing the driver-commands and other rules in your session, you are actually putting these subroutines and submodules into a program to operate the session.

When first creating your driver schedules, use KISS. Peter mentioned this before as well. Once you've got the AI doing things simply, you can then add in triggers, popups, and other fancy stuff.

What you need to do is recreate your schedule from scratch one AI driver at a time and test each and every route as each driver is added. This will have the cumulative effect of each driver interacting with each other. By setting up each driver one at a time like this, you can doublecheck your schedules to ensure that they are working properly. I really recommend setting up the schedules first using the Schedule Library first because that will save tons of time later.

In addition to signals and track marks, you need to pick and choose your driver commands carefully based on the situation. Do you need to use Drive instead of Navigate to or via? The situation depends on which ones to use. The Drive commands are more controlled and direct whereas the Navigate commands allow the AI to seek their own path and the not-so-direct route to a destination. AI will also be more apt to turnaround using the Navigate commands because of this.

What Peter said regarding employees is true here as well as elsewhere. In the US many companies offer a 401K retirement plan, which comes with matching contributions, a matching split to FICA for Social Security and Medicare, and health insurance. This is well and above the weekly compensation, vacation, and sick pay. When added up, this can mean a small salary of around $20K a year costing a company close to $100K a year with compensation benefits.

 

[pware]

Now some of them are my fault but I can't control N3V not wanting to speed up the process of finding a path to a destination even though there's a clear signal straight ahead.

Once again the perception we tend to have is that the Trainz AI is some sort of all seeing, all knowing problem solver. Human logic and machine logic, from long personal experience, can be vastly different. The Trainz AI is far from perfect and the more tasks you throw at it the more obvious those imperfections can become. I limit the use of AI in my sessions, from none at all to very specific tasks that run without opposing traffic or, if there is opposing traffic, then I add logic (e.g. "Wait For" driver commands and "Trigger Check" and "Wait on Navigation" Rules, etc). That plus the placement of invisible signals, speed signs, trackmarks and triggers has allowed me to get the AI control that I want.

I expect for them to be flawless or not so faulty that they're rendered useless or break other perfectly flawless features and then try to deflect blame on us. Such as the trackside items becoming stuck because of something they did. Now they provided a fix, but it shouldn't have come to that in my opinion.

How much testing should N3V do? On how many different machines with how many different hardware, software and OS version combinations? With how many installed assets (DLS, third party and user created)? That is what beta testing is for but if the beta testers do not detect the problem then what? Large corporations such as MS, Apple, Adobe, etc cannot get that right. Incidentally, have you volunteered to become a beta tester? I have been one for many years and have reported many bugs as a result.

There have been issues complained about in these forums that were the result of MS updates or even from not installing MS updates. AV and VPN software are also common causes of "Trainz issues".

What was the problem ("should not have come to that") with them providing a "fix" to the trackside items issue?

at least until they can demonstrate an ability to provide fixes or updates without causing more problems than they resolve.

Welcome to the real world of computer software development. Every change, even minor ones, made to the code can have unintended and unexpected consequences elsewhere. That is what makes software development and testing so difficult, some would say impossible.

To rebuttal your point, concentrating on only new features while neglecting the bugs, which means exclusion of much needed fixes is also a recipe for failure.

My exact quote was

Concentrating on one ... to the exclusion of the other is a recipe for failure.

... which covered both possibilities.

 

[AdvancedApproach]

Yes, the AI will begin to fail over time and are more prone to do this when there are lots of them. On my very large custom route, a route I started in January 2004, I have about 30 active drivers, dozens of static consists, multiple portals sending out many drivers in addition to the 30 captive ones, and lots of destinations covering close to 189 route miles. With a route this large, things begin to breakdown. I consulted with N3V on this issue and they said yes, the AI subsystem needs to be rebuilt, but that is extremely complex a job and they do not have the resources to dedicate to the task at this time. The other issue they explained is fixing the problem as it stands will break things more and that's something that isn't good. As time as gone on, they have fixed a few things but not at the extent that they really need to do.

Creating a session is really programming using OOP, or Object-Oriented Programming. Instead of writing subroutines of code, this is already done for you and by you placing the driver-commands and other rules in your session, you are actually putting these subroutines and submodules into a program to operate the session.

When first creating your driver schedules, use KISS. Peter mentioned this before as well. Once you've got the AI doing things simply, you can then add in triggers, popups, and other fancy stuff.

What you need to do is recreate your schedule from scratch one AI driver at a time and test each and every route as each driver is added. This will have the cumulative effect of each driver interacting with each other. By setting up each driver one at a time like this, you can doublecheck your schedules to ensure that they are working properly. I really recommend setting up the schedules first using the Schedule Library first because that will save tons of time later.

In addition to signals and track marks, you need to pick and choose your driver commands carefully based on the situation. Do you need to use Drive instead of Navigate to or via? The situation depends on which ones to use. The Drive commands are more controlled and direct whereas the Navigate commands allow the AI to seek their own path and the not-so-direct route to a destination. AI will also be more apt to turnaround using the Navigate commands because of this.

What Peter said regarding employees is true here as well as elsewhere. In the US many companies offer a 401K retirement plan, which comes with matching contributions, a matching split to FICA for Social Security and Medicare, and health insurance. This is well and above the weekly compensation, vacation, and sick pay. When added up, this can mean a small salary of around $20K a year costing a company close to $100K a year with compensation benefits.

I use the schedule library rule, and it's been of great help to me. Keeping the tasks simple has something I've tried to do at varying degrees of success. After adding more track marks to decrease the time of searching for a path to destination at Zec's recommendation, I ran into some problems caused by my own doing. The track mark was properly named but on the wrong track so I had to rename it and then redo the AI driver commands to resolve the problem. Even then it was of limited help, so I had to use the auto drive command. That has worked best but has its limitations.

 

[AdvancedApproach]

@JCitron @pware how you explain this?

 

[pware]

Not enough information to go on there.

Is the signal faulty? Has it been configured using the Set Signal Extended Rule to show Proceed? What are the distances between the signals?

What is the sequence of Driver Commands? Are they in a correct order?

What other traffic is on the line? Why is the next signal (on the track line at the bottom) showing Caution?

Do you have a hidden consist somewhere on the track ahead? (e.g. the result of a CTD, freeze or similar in an earlier running of the session)

Is the NBL player the cause (Lakers???)

There are so many variables in situations such as this that it can be a long and tedious task to find the culprit.

All I can do is repeat what I have always stated. Problems like this need to have a repeatability on more than one system. I have never had the above issue in any of my AI session.

 

[JCitron]

Why are you using an absolute or Type 04 signal at this location? You should only use a Type 04 signal where lines join such as going from double to single track or where a siding joins the main track.

Since this is in the middle of the track, a permissive or advanced signal would be more appropriate. That would be a Type 05 signal.

Are those Navigate via or Drive via commands?

I can't tell any more than that from what I can see.

 

[AdvancedApproach]

Not enough information to go on there.

Is the signal faulty? Has it been configured using the Set Signal Extended Rule to show Proceed? What are the distances between the signals?

What is the sequence of Driver Commands? Are they in a correct order?

What other traffic is on the line? Why is the next signal (on the track line at the bottom) showing Caution?

Do you have a hidden consist somewhere on the track ahead? (e.g. the result of a CTD, freeze or similar in an earlier running of the session)

Is the NBL player the cause (Lakers???)

There are so many variables in situations such as this that it can be a long and tedious task to find the culprit.

All I can do is repeat what I have always stated. Problems like this need to have a repeatability on more than one system. I have never had the above issue in any of my AI session.

The signal isn't faulty. No script errors have come about. I set the signals at roughly every four baseboards. The signals show caution probably due to being approach lit. This is the case with every signal system from Jointed Rail I use. Once you pass the signal, the following one will turn green so I generally ignore it. There's other trains on the line but the one directly in front of it was at least 20-30 miles away. No hidden consists either otherwise the signal would be red. I did have a hidden consist earlier due to my computer automatically updating despite me telling it not to but I deleted it before continuing on.

 

[AdvancedApproach]

Why are you using an absolute or Type 04 signal at this location? You should only use a Type 04 signal where lines join such as going from double to single track or where a siding joins the main track.

Since this is in the middle of the track, a permissive or advanced signal would be more appropriate. That would be a Type 05 signal.

Are those Navigate via or Drive via commands?

I can't tell any more than that from what I can see.

The first picture is drive via and the second one is navigate via.

 

[pware]

I use the Navigate commands, not the Drive commands. The advantage is Navigate will not force the drivers to go off script (e.g. wrong road) to get around an issue but that is my personal preference. Why mix the two types?

 

[AdvancedApproach]

I use the Navigate commands, not the Drive commands. The advantage is Navigate will not force the drivers to go off script (e.g. wrong road) to get around an issue but that is my personal preference. Why mix the two types?

I was trying to see if switching them out with one another would solve the issue. Doesn't the navigate to command allow AI to reroute around trains? The drive to command will instruct them to take the shortest path. Based on my route structure there's only one way forward unless the train backs up and then switches tracks which is exactly what I don't want. The navigate via command prompted the block is in use by another train message.

 

[pware]

Both Navigate and Drive commands will select the shortest possible available path (allowing for track direction and track priority markers).

Doesn't the navigate to command allow AI to reroute around trains?

You are right, I got that around the wrong way. It can be confusing. If using the Navigate commands a driver will be stopped if the path ahead is not clear and it will not attempt to find an alternative route. The fact that the signal in your screenshots is showing Proceed but the train is not moving may be the result of a signal problem.

I don't use any US signals as they do not apply here nor do I understand their operation. The signals I use have never had the issue shown in your screenshots. As a debugging suggestion try using a simple "generic" semaphore signal to see if that makes a difference.

 

[AdvancedApproach]

Then it says waiting for access beyond junction 3924576 despite a clear signal. After taking control of the train and moving it past said junction I gave control back to AI and all of a sudden there's access as it continued on without incident. That should not be happening at all. Not a single train was in that block so what exactly was it trying to access? The junction was literally right in front of it.

 

[Forester1]

I don't know how these things work, but are Brian Cook and Nick Van Exel both approaching Junction 3924576? It mentions Brian Cook and then says "Approaching Junction 3924576 at 323ft, then says Nick Van Exel waiting access to track beyond 392476. Or are both statements referring to NIck Van Exel?

 

[AdvancedApproach]

I don't know how these things work, but are Brian Cook and Nick Van Exel both approaching Junction 3924576? It mentions Brian Cook and then says "Approaching Junction 3924576 at 323ft, then says Nick Van Exel waiting access to track beyond 392476. Or are both statements referring to NIck Van Exel?

Both statements are referring to Nick Van Exel.

 

[pware]

Have you tried changing the signal at that junction to a completely different one to see if that works. Also does that signal have any built-in properties that can be edited?