Is there a limit to the number of moving consists?

[autodctr]

I have 24 trains and 14 go karts moving at once. I tried adding 8 trams. When I went back in to drive the trams, only one of them had a driver. So, I put drivers in all of them. But then, I saw that one moving train no longer had a loco attached to it! Looked around and found another moving train w/o a loco. I exited w/o saving and went back in. Both of the trains now had locos and were running as they should. Only one tram had a driver assigned. I assigned 3 more drivers to 3 of the other trams and lost both locos that I had lost before. What gives? I do use any AI....everything is manually controlled.

Ryzen 9 7900, RTX 3080, 32 gig RAM.

 

[PGibbons]

I don't know about TRS22 but I have upwards of 50 consists running in TANESP4 all with drivers and loading running instructions from the Schedule library. Some are generated by Portals others situated on the route. Works fine for me.
PG

 

[autodctr]

If there isn't a limit, then why is this happening?

 

[autodctr]

New twist today: I deleted all of the trams. No consists lost their drivers. However, one consist is now going the opposite way! I have a 252 mile main route (sightseeing route) with 13 consists running on that line, all manually controlled. I take the first one out, get it's speed to about 40MPH. Then the second goes out: speed to 39-40MPH. Same with the next 11. On other tracks, 14 other consists moving, each on their own tracks. 14 go karts running. Looking at temps of CPU and GPU, nothing is near maxed out. Why so many problems? No faulty content, did extended DBR. Still these issues. Very disappointing.

 

[autodctr]

No thoughts anyone? The few hundred hours that I spent doing this layout and now I can just delete it and try again and hope that the next one works?

 

[Kennilworth]

Hi

About 10 years ago when I was using SCS2013 in TRS12 I ran some tests by adding a train, letting it run from A to B and then deleting it. I got up to about 62 trains before it failed. From this I deduced that each train needed its own thread and once it reached the maximum things went wrong. There were a couple of threads used by SCS2013 for housekeeping in the program. The trains just consisted of a loco and they were only on the route for maybe 30 seconds before deletion.

Of course this may have been a limitation of SCS2013 so I have no idea if this information has any relevance with the recent versions of Trainz as since then we have a new game engine plus 10 years of development but that was what I observed at that time.

What you are seeing though suggests to me that there is still a limit on the number of trains that you can have on a route.

Sorry I can't offer any advice on your problems.

Regards

Brian

 

[Paul_Bert]

I have a route with over 80 trains running without a problem. I have build 123794, which is the latest Trains Plus version. Not quite sure from your description what the problem may be.

 

[JCitron]

Hi

About 10 years ago when I was using SCS2013 in TRS12 I ran some tests by adding a train, letting it run from A to B and then deleting it. I got up to about 62 trains before it failed. From this I deduced that each train needed its own thread and once it reached the maximum things went wrong. There were a couple of threads used by SCS2013 for housekeeping in the program. The trains just consisted of a loco and they were only on the route for maybe 30 seconds before deletion.

Of course this may have been a limitation of SCS2013 so I have no idea if this information has any relevance with the recent versions of Trainz as since then we have a new game engine plus 10 years of development but that was what I observed at that time.

What you are seeing though suggests to me that there is still a limit on the number of trains that you can have on a route.

Sorry I can't offer any advice on your problems.

Regards

Brian

That would mean there's a total of 64 threads 0 - 63 being zero inclusive in total.

There may very well be a limit to the number of drivers. I've had up to somewhere in the high 50-something range without issues on a simple route. On a more complex route everything was running sluggishly with AI doing their best to make things worse. Signals too messing up with some not displaying the correct aspect, or not displaying anything at all and ATLS road crossings weren't interacting properly with the passing trains.

In my opinion, I think at that point the whole system was falling apart due to all the threads pushing everything right to the edge.

 

[JCitron]

New twist today: I deleted all of the trams. No consists lost their drivers. However, one consist is now going the opposite way! I have a 252 mile main route (sightseeing route) with 13 consists running on that line, all manually controlled. I take the first one out, get it's speed to about 40MPH. Then the second goes out: speed to 39-40MPH. Same with the next 11. On other tracks, 14 other consists moving, each on their own tracks. 14 go karts running. Looking at temps of CPU and GPU, nothing is near maxed out. Why so many problems? No faulty content, did extended DBR. Still these issues. Very disappointing.

One driver going the wrong way? I would've checked the consist direction to ensure that one is facing the correct direction.

If the AI randomly stops and then reverses, it's the issue we've been complaining about and tickets have been submitted.

I'm sorry I didn't respond the other day. I had the COVID-19 shot followed by some side-effects that left me achy and very fatigued. I'm finally getting back to my old self but still very tired.

 

[autodctr]

The train was reversed on the track....like I stopped everything, and completely flipped the entire train around. It was still traveling the speed that I had it set to, nut was going to shortly run head-on to the train that was, at one time, behind it and following it.

I have seen my fair share of odd ball things happen in Trainz, but this one was bizarre.

Is there a way of salvaging that layout or do I just through away a few hundred hours of work? And, how do I prevent it from happening again?

Hope you feel better REAL soon!

 

[JCitron]

The train was reversed on the track....like I stopped everything, and completely flipped the entire train around. It was still traveling the speed that I had it set to, nut was going to shortly run head-on to the train that was, at one time, behind it and following it.

I have seen my fair share of odd ball things happen in Trainz, but this one was bizarre.

Is there a way of salvaging that layout or do I just through away a few hundred hours of work? And, how do I prevent it from happening again?

Hope you feel better REAL soon!

Your layout is fine. I would check the quirky consist in your session editor to ensure it is facing the right direction before running. If it is, then it's that weird and very frustrating bug we're all experiencing. For some of us, the AI will drive along, encounter a train in front, stop then reverse. Like you, I've had my share of collisions where they will actually derail a train ahead, or sometimes couple to them, which removes the other driver's commands from the train rendering his schedule dead.

In addition to the random backing up, we've had AI sit at signals until prodded into motion by moving them past the signal and then CTRL-right-clicking on them to Continue Schedule. This works most of the time but not always. Some of us have found putting a wait command between the Drive To/Via, Navigate To/Via commands and the load/unload commands. I found that it worked most of the time, then everything went tits up a short time later for no reason at all.

With things the way they are now, I do very little driving and concentrate on finishing up parts of my big route I've been digging and working at for the past few months.

Thanks... I'll probably head off for a nap in a bit. I'm totally wiped.

 

[autodctr]

But, I don't use any AI. None. Never have. The only thing that might come close to that is the Yarn crossing that comes with TRS19. <2:124017:30018:4> And I have used that on every route that I ever made with no probs.

 

[Paul_Bert]

Your layout is fine. I would check the quirky consist in your session editor to ensure it is facing the right direction before running. If it is, then it's that weird and very frustrating bug we're all experiencing. For some of us, the AI will drive along, encounter a train in front, stop then reverse. Like you, I've had my share of collisions where they will actually derail a train ahead, or sometimes couple to them, which removes the other driver's commands from the train rendering his schedule dead.

In addition to the random backing up, we've had AI sit at signals until prodded into motion by moving them past the signal and then CTRL-right-clicking on them to Continue Schedule. This works most of the time but not always. Some of us have found putting a wait command between the Drive To/Via, Navigate To/Via commands and the load/unload commands. I found that it worked most of the time, then everything went tits up a short time later for no reason at all.

I have little hope that theses issues will be fixed in the next release. I have found the Autodrive command has provided a “fix” for most of these issues on my routes. This has resulted in a re-thinking on how to use track marks and juction directions in different way. I have also been replacing all my “navigate to” commands with “drive to” commands. Also adding many additional directional markers along the route.

My hope is that more stuff isn’t broken in the next release. I have reported these issues but received no feedback, so i am not sure anybody is addressing these issues.

 

[autodctr]

I have little hope that theses issues will be fixed in the next release. I have found the Autodrive command has provided a “fix” for most of these issues on my routes. This has resulted in a re-thinking on how to use track marks and juction directions in different way. I have also been replacing all my “navigate to” commands with “drive to” commands. Also adding many additional directional markers along the route.

But, I don't use any of that! None of it. I use this program like I used to have a model railroad layout 55 years ago: just tracks and scenery.

 

[JCitron]

I have little hope that theses issues will be fixed in the next release. I have found the Autodrive command has provided a “fix” for most of these issues on my routes. This has resulted in a re-thinking on how to use track marks and juction directions in different way. I have also been replacing all my “navigate to” commands with “drive to” commands. Also adding many additional directional markers along the route.

My hope is that more stuff isn’t broken in the next release. I have reported these issues but received no feedback, so i am not sure anybody is addressing these issues.

I was trying to be positive ;-)

But seriously you are very right about this and we can only hope that their silence means they're busy trying to fix the problem rather than ignoring it. Whatever updates they did for the new TLR thing broke the existing code that worked perfectly fine for nearly 20 years before. The way I see this is none of the developers bothered to test anything after the code was implemented and assumed the public beta would catch it. I won't start that bumpy road again, but it is what it is and where we're at right now.

I haven't used Autodrive in ages and I'm not sure that would work with my routes. At the moment I'm also reluctant to make drastic changes to my complex driver command schedules because they worked as they should prior, so for now I'll continue to work in Surveyor and avoid driving. They're complex, not with lots of oddball scripts and triggers but with the number of driver commands, loading, and other normal things we've used since TRS2004 at least.

The way the driver sessions worked, there were very few conflicts and they used to run for hours on end without issue. I do use many signals and many direction markers, so perhaps I'm not at a total loss but still the random turning around of a consist when it encounters a block of some kind is the pisser that ruins the driving session completely as it interrupts whatever I was doing because I have to constantly babysit the AI drivers.

Overall, since TRS22 has come out, the AI driver behavior has changed. I've noticed that they are more "aggressive" and lock junctions more frequently at longer distances, and drive headlong as if no one else is there in the way. User-driven trains now have a low priority and any switches set by a user get overridden even if the user-train is in close proximity of the switch! Many times, I've been stuck with an AI driver grabbing a junction just as I approach it and I'm unable to stop in time. I either derail or end up bumping into the AI train and ruining the run.

 

[JCitron]

But, I don't use any AI. None. Never have. The only thing that might come close to that is the Yarn crossing that comes with TRS19. <2:124017:30018:4> And I have used that on every route that I ever made with no probs.

Your consist must've been facing the wrong direction then to do that and you didn't notice the arrows.

 

[autodctr]

No sir. All of the consists on the main line had made several round trips w/o any issues. I would just tweak their speed when one of them got too close to another one. None of them were ever stopped for any reason. All of the trouble started when I added the tram line. When I completed it, I put 13 trams on it. 8 were on the track with 5 more in the yard. I started the first tram and let it get a bit out of the station. Then started the second one at the same throttle setting so it would stay spaced from the first one. Went to start the third one and it didn't have a driver for some reason. So, I checked the rest of them: none had drivers. So, I added 6 drivers and assigned one each to the other 6 cars on the track and not in the yard. When I started the 3rd tram, I noticed the consist on my mainline going past the station for the trams. I zoomed out a bit to see how close it was to any other consist on the mainline and that's when I saw it just about to collide head on to the consist that normally is behind it!

I immediately paused the game, saved it with a new number, and exited the game. I checked for faulty content: none found. I then did an extended DBR: no issues. Checked for faulty content again: none. Went back into the layout with the newest save: both trains heading right towards each other! Exited out of that and went to the previously saved session and found the two consists a lot further away from each other, but with the lead consist going the wrong way.

 

[Paul_Bert]

The way the driver sessions worked, there were very few conflicts and they used to run for hours on end without issue. I do use many signals and many direction markers, so perhaps I'm not at a total loss but still the random turning around of a consist when it encounters a block of some kind is the pisser that ruins the driving session completely as it interrupts whatever I was doing because I have to constantly babysit the AI drivers.

The frustrating thing about all of this is that it so inconsistent, therefore heard to explain unless you have experienced it. For instance i have two trains with exactly the same instruction set on the same route.the second train follows the first train by three or four signals - maybe one base board in distance. The first train runs along fine along the entire route. The second train, using exactly the same instructions goe into spastic shock. It stops for no reason, it reverse direction and proceeds in the wrong direction for as long as you let. If i am lucky I can stop the train and the “continue” the schedule correctly until it closes in on the first train, and then it starts the random cycle of events all over. The real problem is if you are running or instance 30 AI controlled trains on a route you spend all your time straightening things out and no time enjoying route.

This is a difficult thing to report to quality control since the issue is not consistent from one route to another. I have also found that the problem is also somewhat dependent upon the length of the train. Shorten the length of the first train and sometimes the following trains will behave less erratic.

I have found that Autodrive totally eliminates the problem when trains are following one another, but it takes many hours of work to setup the track marks and switch junctions properly for it to be successful. I just hope the next update doesn’t destroy Autodrive.

 

[PGibbons]

In my Sydney Metro route (in TANESP4) I have set up instructions in the Schedule Library to replicate the real schedules for many of the lines in the Sydney network. My first experiment was the T1 which, in my route runs from Wynyard to Penrith, with an 'all stations' version and an 'express' version. I generate consists from a Portal north of Wynyard, at 10 minute intervals which then load and execute the schedules. By the time the first consist gets to Penrith and exit at a Portal, there are many other consists on the route all with the same name Driver and running the same schedules. I've run this for several hours with no issues other than of my own cause. I now have several other Sydney routes running which after some fine tuning also work fine.
It takes a lot of effort to fine tune the schedule instructions and test but in the end they work as desired. One problem is that when updating the route with Interlocking Towers or merging additional sections of the network everything needs to be revisited and tested.
All I can say is keep at it and good luck.
PG

 

[PGibbons]

Ive copied the route and session across to TRS2022 (122418) and there are several problems appearing.
Schedule Library only has some of the schedules listed.
IT Set Path shows as invalid.
+ several others.

I guess I'll stay with TANE for a while yet where all of the rules and driver instructions seem to work as advertised.
Its a shame that the developers didnt get the basics right before introducing too much 'bling' into TRS22.
PG