Where do they hire these people?

nfitzsimmons

New member
Learning how to create sessions, and have a strange situation.

Currently have two consists, one is a long coal drag. The other is a passenger train.

This is how I set everything up:

I gave the passenger train orders using the Navigate To command three stations in order, stopping to load and unload at each. The coal train has one order set, to navigate to a portal at the other end of the same line. I configured it to wait 5 minutes before beginning its trip.

The passenger train I set to Priority one. The coal train is set to Priority 2.

The first station where I want the passenger train to stop is a two track station with the actual station on the right hand side.

This is what happens when I run the session:

The passenger train departs as directed. The coal train leaves 5 minutes later.

The passenger train arrives at the first station on the left hand track. It cruises through the station without stopping. About three miles further on, it stops, then reverses back to the station for unloading and loading. Meanwhile the coal train is proceeding along the right side track. It passes through the station at the speed limit while the passenger train is stopped for loading and unloading. (Obviously an unsafe condition for the passengers.) It continues down the line while the priority 1 passenger train is now trapped behind the slower-moving freight drag.

Is this just AI stupidity, or am I doing something wrong?
 
Put a track mark on the track the station is and have the ai go to that trackmark, then the station. That way it doesn't get confused on which track to take or how to get there.
 
You can also put in another trackmark for the freight. You then use a drive via track mark. and then follwing the track mark in the driver's schedule, you put in a max speed command. There are values to choose from when setting it up. Once you pass your slow part, you can then increase then resume the speed again afterwards.
 
Well, this is interesting. Tried running the passenger train as the only consist. Ran it several times with no changes, and sometimes it chooses the left hand track and sometimes the right one. In all cases it passes through the station and continues to the point where the two tracks converge again. At that point it always stops and reverses back to the station on the left side track for loading and unloading. Is there some way this can be controlled?
 
Well, this is interesting. Tried running the passenger train as the only consist. Ran it several times with no changes, and sometimes it chooses the left hand track and sometimes the right one. In all cases it passes through the station and continues to the point where the two tracks converge again. At that point it always stops and reverses back to the station on the left side track for loading and unloading. Is there some way this can be controlled?

Can you drive the train yourself?

To me it sounds like it's a broken track, missing junction lever, or a reversed direction mark.

I just ran into that issue myself and discovered when my drivers go stuck at the end of a bridge. I had relaid the track and forgot to connect the track splines to it. The drivers were trying with all their might to get to their destinations, but couldn't. In some cases, they were backing up while others were just sitting there. The No path to selected destination message was a clue. I only wish there was a bit more details on who was saying that because I spent a half hour checking drivers until I found out the one with the problem at the time.
 
Use a priority trackmark. Since the passenger train is 1, set the mark for only consists with 1 leading to the track you want. It may not solve the problem of AI passing the station and returning to it once it realizes it has passed it. You're lucky, sometimes the train will continue to the end of the World not returning (courtesy of the AI stupidity). One more thing: Once a consist enters a portal, it will return with the defaullt priority of 2. What I do is to have a command that changes priority as soon as it exits the portal, so nothing is screwed. For AI going to wrong tracks, I use directional trackmarks. For trains not stopping at stations, I make sure the setting of platform length is adequate for the length of the train you are using. Take a look at what happens on the command line when the passenger train is arriving: Does the station icon goes away and the loading icon remains? Are you using those passenger load commands that open doors? What kind of station do you use? Experimentation, sometimes with a test track will help to diagnose.
 
My focus is moving more toward a similar approach to TRS19 - actually creating a railroad environment in a working situation. I see similar very odd problems. From the discussion, thus far, it seems that the customer should consider managing the AI environment as much as they can with the tools available. N3V has focused their product on the visuals while the AI gets little, or no attention. To compound the evolution, some changes do impact AI and N3V is not prepared to deal with them from a budgetary viewpoint.

Using the message of llberz as an example the customer should be prepared to take a more in-depth role in the AI process. Trackmark managed routing seems the be a way to regain control of the automatic train movement process. The best way to "run your railroad" may be choosing the recommended portals, industry tracks and trackmarks - placement and type. Other tools may be needed and a conversation should be started by people who have experience dealing with them.

Creating an operating railroad using the tools that "appear" to be appropriate is the usual approach. It would be nice if N3V sponsored the creation of a recommended set of tools for various objectives and not always imply that the customer should rely on AI. Reliance on Navigate to __________ maybe a bad choice.
 
Last edited:
Strategically placed track marks do help with herding the AI drivers around and forcing them into submission. ;)

I run an extensive AI-driven operation which runs quite well with an occasional mess up which I am troubleshooting now. I had an issue where some drivers were backing themselves up and recently I took a look at each driver's route. Almost immediately, I saw why this was occurring. This was a case of egg on my face as I had put in the wrong track mark, and yeah they were doing what they were told, but not what I thought I had told them!

In another instance, I had done some track work, replaced a bridge, and rebuilt the mainline to make it faster running. It all looked great, but I forgot to connect some tracks. The AI were driving along and then backing up suddenly, or stopping. It wasn't until I saw a No path to selected destination did I know there was a problem. When I visited a stuck driver, it would be nice if there was a way to tell who was stuck and complaining, I found the disconnected track. Oops!

Once we get past these technical difficulties, the AI can run quite well using simple track marks, wait commands, and direction markers. We have to keep in mind too the subtle difference too between the Drive to___ and Drive via____ versus the Navigate to____ and Navigate via____ commands.

Drive to/via____ is a bit more direct, meaning the AI won't seek an alternative path around an obstacle. These are great for direct driving through complex track work such as yards and terminals. For open main lines and long branches, use the Navigate to or Navigate via to meander a long these open stretches.

I find too placing track marks before, in the middle, and after complex places, keeps the AI on track (pun intended). This is particularly helpful where there are complex junctions and wye configurations. The first encountered track mark is the one to initiate the sequence. The one in the middle is to keep the AI focused because it's close, and the final is the exit through the busy area. This works well because the drivers will look for the shortest path between two points even it if doesn't appear to be that way. The closer placed track marks end up breaking up the longer path by making the destination shorter.

Another thing I find is keeping the number of track marks to the minimum needed. Too many track marks can be just as bad as that seems to bog down the processing of the commands. Those little slowdowns cause awful performance as well when there's a lot of them so use them where they're needed the most.

Granted the AI logic needs work, and Tony admitted that and it's being looked at, but we can't wait for the developers to do what they need to do, and instead we need to make use of the current tools we have to get the job done.
 
I just downloaded a route off the dsl. This route has been around since 2009 or maybe 2004 and new versions have come out with each new Trainz version. Ran 2 sessions also on dsl, each ran for about 2hrs and had mutiple trains. I only saw one error from the ai, an steam engine went to a turntable without uncoupling to the consist. The trains made pickups and drops. So with all the problems with the ai, they can be made to operate properly. Route is "sumer lake track new trs19". Not the best looking route I have seen but the session are interesting. On the steam version you have to jump around to operate the turntable went an engine arrives. There are many turntables and you get a notice to do the turn.

Rob
 
Strategically placed track marks do help with herding the AI drivers around and forcing them into submission. ;)

I run an extensive AI-driven operation which runs quite well with an occasional mess up which I am troubleshooting now. I had an issue where some drivers were backing themselves up and recently I took a look at each driver's route. Almost immediately, I saw why this was occurring. This was a case of egg on my face as I had put in the wrong track mark, and yeah they were doing what they were told, but not what I thought I had told them!

In another instance, I had done some track work, replaced a bridge, and rebuilt the mainline to make it faster running. It all looked great, but I forgot to connect some tracks. The AI were driving along and then backing up suddenly, or stopping. It wasn't until I saw a No path to selected destination did I know there was a problem. When I visited a stuck driver, it would be nice if there was a way to tell who was stuck and complaining, I found the disconnected track. Oops!

Once we get past these technical difficulties, the AI can run quite well using simple track marks, wait commands, and direction markers. We have to keep in mind too the subtle difference too between the Drive to___ and Drive via____ versus the Navigate to____ and Navigate via____ commands.

Drive to/via____ is a bit more direct, meaning the AI won't seek an alternative path around an obstacle. These are great for direct driving through complex track work such as yards and terminals. For open main lines and long branches, use the Navigate to or Navigate via to meander a long these open stretches.

I find too placing track marks before, in the middle, and after complex places, keeps the AI on track (pun intended). This is particularly helpful where there are complex junctions and wye configurations. The first encountered track mark is the one to initiate the sequence. The one in the middle is to keep the AI focused because it's close, and the final is the exit through the busy area. This works well because the drivers will look for the shortest path between two points even it if doesn't appear to be that way. The closer placed track marks end up breaking up the longer path by making the destination shorter.

Another thing I find is keeping the number of track marks to the minimum needed. Too many track marks can be just as bad as that seems to bog down the processing of the commands. Those little slowdowns cause awful performance as well when there's a lot of them so use them where they're needed the most.

Granted the AI logic needs work, and Tony admitted that and it's being looked at, but we can't wait for the developers to do what they need to do, and instead we need to make use of the current tools we have to get the job done.
For the most part, I agree with all of the above, and I am not going to elaborate. Now, having said that, do a very simple command: Couple at track mark. Chances are that the loco will run the other way, forever. However, if you stop the action and gain manual control, and then you resume, the loco goes and couples as intended! To compound confusion, it does not happen all the time, just here and there. Naturally you'll say it depends on signals, trackmarks and all that. Sorry to say, it happens with only one set of points in between. If there are many, it could happen that the loco will sit right and there until you change the points manually. Run a new session and everything seems to work more or less perfectly. Save the session, and open again, and things will not go as on the first run. If this is a session you have run several save times, good luck. You may as well start a session all over again. The condition has been there since I can remember, many iterations ago. Like Boleyd (#8) says, N3v resources are directed at pretty pictures more than a real full functionality. What should be a simple straight forward programing (using the tools provided) of trains running, takes hours if not days of frustration and work. Again, that is my grain of salt.
 
For the most part, I agree with all of the above, and I am not going to elaborate. Now, having said that, do a very simple command: Couple at track mark. Chances are that the loco will run the other way, forever. However, if you stop the action and gain manual control, and then you resume, the loco goes and couples as intended! To compound confusion, it does not happen all the time, just here and there. Naturally you'll say it depends on signals, trackmarks and all that. Sorry to say, it happens with only one set of points in between. If there are many, it could happen that the loco will sit right and there until you change the points manually. Run a new session and everything seems to work more or less perfectly. Save the session, and open again, and things will not go as on the first run. If this is a session you have run several save times, good luck. You may as well start a session all over again. The condition has been there since I can remember, many iterations ago. Like Boleyd (#8) says, N3v resources are directed at pretty pictures more than a real full functionality. What should be a simple straight forward programing (using the tools provided) of trains running, takes hours if not days of frustration and work. Again, that is my grain of salt.

Your grain of salt is pretty much spot on with the run around command and the couple command as well. Yeah I've seen it myself when using the simple couple command and not the couple at track mark. Stopping the driver and the command will be excuted fine. To me it looks like something is getting lost between the issuing, initialization, and execution of the command.

Auran maybe the owner of the command, but I don't think they wrote it a decade and half ago. The code needs to be looked at to see what's happening in it in order to be fixed. With many of these commands compressed and encrypted, unfortunately that has to be done by N3V unless they can't decrypt the commands either. I'm not trying to make excuses for them, but I see that as an obstacle to fix these and many, many other commands that we use.
 
..........The best way to "run your railroad" may be choosing the recommended portals, industry tracks and trackmarks - placement and type......

Yesterday the new portals for trs19 were uploaded. When you said ''recommended'' are you thinking this uploads?
 
Back
Top