HELP! - Assistance needed with troubleshooting large route

Some of you may remember me - I'm working on a large fictional UK light rail route, and I pop in now and then to assure everyone it's not total vapourware. https://forums.auran.com/trainz/sho...-Light-Rail-Modern-Tramway-in-Progress/page37

I'm in a position where I'd like to release an update to the route, but I'm having some significant problems with AI trams skipping stops in the schedule - a tram will try to set off from one stop to the next, but instead of moving, it will delete the next command or commands in the schedule, one by one, until it usually stops, and will then attempt to perform the next command in the list (usually a station stop miles down the line). Although there are some patterns (often the same stops missed), this is very inconsistent behaviour with no obvious cause. I've tried drive to, navigate to and load at commands with equal levels of failure. Sometimes completely rebuilding a station has appeared to work, but I'm not even sure about that.

All of the tram stops are AJS stations / tram stops of various types (though some are under other's KUIDs). Some are using the latest script library versions, and some are unchanged since build 2.2. I can't see any pattern as to which stops get skipped. I have a large number of trams & trains running using schedules from an extensive schedule library. The issue has followed me from earlier versions of Trainz (at least since T:ane), and from an earlier PC - my new one is much more capable. I haven't managed to find anything in the log files that indicates a problem, but there's a lot going on in such a large route, and I may have missed something. I'm not aware that I've had the same issue with any other routes, but I don't spend a lot of time on other routes.

So, has anyone had similar issues, or is anyone prepared to have a look at this large unfinished layout to see if they can work out what might be going wrong? I'd really appreciate some assistance, even if only to check if the problem is reproducible.

Thanks,

Paul

I have had problems like you but on different things like junctions returning to default state as soon as the loco has passed and derailing the consist. This all started after a windows update and mostly applies to newer additions or alterations to assets. All my other similar assets that have not been touched are working fine. My EIT worked fine until I added a new path and now only the default paths work.

Hello Paul,

I may be able to throw some light on your problem. I am having similar issues and run a few experiments. I can tell you what I found and see if that takes you anywhere.

All of these assets by Cosey were modified by me up to 3.7 for Tane. I had been running the trams on my route for a while but recently a few issues emerged. The first being the platform triggers lost the plot and the trams would not stop in the right place on the platform but they used to work just fine. I sorted that out by deleting the triggers I knew I would not need. I can make a useful point here for others to remember that trams driving into a european station use the trigger system in reverse to us as they drive on the 'wrong side' for UK set ups.

My next perplexed expression came a few weeks ago when I asked a tram to drive a new road that I added to my route. The tram went away from the terminus with intructions to stop at each tram stop and deal with passengers and move on to the next stop etc. The tram stopped at the first stop and loaded passengers and went on its way. It then cruised passed each stop after that until it reached the terminus at end 'B'. Totally ignored every instruction for the other stops.

The trams used to stop as required, doors open, unload and load by themselves and then close the doors and move on to the next stop. I did not need to use the "load-unload" commands. For an experiment I added the "load passengers rule" but this made the doors open and close twice but the tram did stop at each tramstop. I took this further and added a very short "wait" command for 10 seconds and the trams would now work as they used to and stop at all the stops, load, wait and move on.

As I said earlier, I updated the tram stops and they worked well untill a month or so ago. I can only hazard a guess that it is an AI thing that has manifested itself. For some reason the driver command are being ignored and I am hearing from others that the driver commands are not being saved. There we are then. I am able to explain a similar form of your problem so that may give you a lightbulb moment. As yet I don't have the answer as to what is actually going on.


Doug

Thanks for having a think about this. I'm not sure if your problem is quite the same as mine, Doug. In my case the tram waits at the first stop and the next command in the list disappears without the tram moving. This happens to a number of commands in sequence until eventually the process stops, and it performs the next command in sequence. I'll see if I can take a video to demonstrate.

Anyone else got any ideas? Anyone got time to help with some trouble-shooting?

Paul

So I just took a quick video of the worst offending driver with Clipchamp, and everything ran absolutely perfectly. after I switched screen recording off, problems started to happen again. I'm doing the same thing now, just to check it's not a freak, and so far the results are the same. I seem to remember something about screen recorders locking frame rates, and this sometimes having a stabilising effect. have I remembered this right?

Paul

Just a quick bump to see if anyone has any thoughts, or would like to give this route a quick test to see if my problems are repeatable...

Thanks!

Paul,

This sounds like something to do with script related to the stations. Why this fixed itself when you used a screen recorder is odd but that may have something to do with the Trainz being interrupted enough to allow the stations to work properly.

One of the issues I've run into, while similar in behavior but not the same I don't think was caused by level crossings and signals being too close to the station platforms. I noticed that the signals would indicate to the AI to proceed and instead of the AI slowing down for the station they would accelerate through the station instead. Once the skipped one station, they continued on as though they were on a tour rather than running an actual schedule. What's more interesting is that sometimes the session worked fine, making troubleshooting difficult. I noticed that the placement of the signals worked fine in some locations but not others and the difference was the distance from the platforms. By adjusting the distance from the platforms, the AI interacted fine with the stations and the stations "caught" the AI driven trams fine and pulled them into the stations.

In some locations, the issue was related to some level crossings which were placed a bit too close to the stations. In real life, stations have roads that cross from one side to the other at the ends of the stations and I wanted to imitate that as well, however, with Trainz I had to move the roads about 30 meters from the stations in order for the AI to interact with the crossings and the stations just like I did with the signals.

So I'm still having the same problems (yes I move pretty slowly), but now I'm also getting crash to desktop (CTD) every time I run the route. This is usually about the 3 minute mark, but occasionally sooner. If I delete the commands from most of my drivers, or remove their trains/trams from the session, it will run for quite a bit longer, and the ignoring commands thing doesn't seem to happen. The route / session has a lot of content, but my machine is powerful to get around 30FPS when it is running, and never crashes in surveyor. For the record, there are about 150 ATLS intersections, 52 consists (all with drivers - 40 of whom start off with driver commands). Driver commands mostly use the Schedule Library rule.

I've put my computer through its own internal diagnostics, including a BIOS update, graphics card update and a memory test. Task manager shows memory and CPU usage in the 50-60% range preceding the crashes, and the main fan (which works fine when the computer is really working) doesn't even start up.

The only significant change is that since the route last ran without crashing, I've updated Trainz to the latest Trainz Plus build. I was previously on the last one before HD terrain was introduced. I haven't converted the route to HD as I had another issue.

I'm hoping that I can persuade someone to have a look at this on their own computer - this is the only way I can see of getting any nearer to another progress release of the route, which I realise is long overdue - there is a lot more to it than at the last release.

Thanks,

Paul

I vaguely recall in my days with Trainz 2004/2009/2010 that the driver commands would occasionally fail and get dropped from the queue. I also vaguely recall failed driver commands dropping the train out of automatic driving without deleting them. I do not recall either in any detail, but it seems to me that your driver commands are failing without halting the train.

That said, I have been reading a lot of noise about the changes made for the Living Railroad breaking various driver commands and industry interactions. If that is the cause of your issues, you aren`t likely to be able to fix them in a way that still works when they repair the damage that their updates have caused. I hope I`m wrong, but you may just have to delay the next release for a while longer.

The skipping commands - train gets to next command, but does nothing as several commands disappear from the queue one by one - has been going on for a while, including on my previous machine running TS19 (or possibly earlier). The CTD is new, and coincides with the more recent Trainz builds. Interestingly, the workaround where the commands would behave while capturing video in ClipChamp no longer works.

I'd really like to find someone with time to test this out on their home machine. The test doesn't need to be long - things go wrong pretty quickly for me.

Paul

Hi Paul, I'm happy to have a look at this for you - I already have an older version of one of your Bridgehampton routes from the DLS so should have most of the dependencies etc. Send me a PM if you want.

Kind regards,

Gary

Having seen this happen a few times on older routes brought into TRS19, I suspect the issue is related to using track made for older versions of Trainz. I first became aware of it when using a banking script on some 2t trackwork, which I'd changed for a newer track type using bulk asset replace. The script could not scan along the track. I relaid all the affected track and the script began to work. You may have used a bridge with built-in or predefined track, and then connected to it with more modern track. The track on the bridge may look the same, but will still be considered as whichever track the original asset builder used for the bridge. A "list dependencies recursively" command in CMP should find any example of old track in use on the route, and then its a question of finding the instances.

The technique is to lower the bridge slightly and then connect your modern track across, ignoring the bridge track spline points.

Another thread that reported CTD finally got a solution that the bios was faulty.

Solved. Took the new PC into the shop and they confirmed the CTDs. The tech said that the BIOS was detecting an erroneous memory fault which was causing the issues. They updated the firmware and were able to get rid of the erroneous fault. Subsequent stress tests were fine. Just ran my first successful session without any issues. Thankfully nothing was lost in the process. Now back to route building. Thanks to all for suggestions and advice.

@paulzmay, it sounds to me like you have two unrelated problems. When you get the crashes sorted, I suggest taking a closer look at the route for why the AI drivers are dropping commands.

@stagecoach, I remember that thread.

Thanks for all your suggestions and offers of help. I'm sorry it's taken so long to reply, but I've been traveling for work. For those who would like to try the route, here is a link to the current version. On my machine it generally runs for a couple of minutes before crashing to desktop. If I delete most of the trains / trams, then it will run much longer. The skipping stops issue can pretty reliably be seen by observing the first driver in the list - he visits the first stop correctly, and then will skip several commands, and eventually set off for a stop several beyond the next one.


This is a link to the one item of my content that is missing - it's not important, but I don't really want to upload it to the DLS as it's not complete. Everything else should be on the DLS.


Many thanks in advance.

Paul

p.s. I just realised that the route also uses Boat's ASB system. I don't think it's important for this test, but you can get it here: http://www.boatztrainz.co.uk/turnout.html

Traveling for work? Not a problem. Have you had any opportunity yet to try out any of the suggestions?

@MasterTracklayer - I haven't yet. I'm hoping that if someone can either replicate or fail to replicate the CTD, I can look at that first. After that, there are some good suggestions for the stop skipping issue, but again, it helps to know if these issues can be replicated on others' machines.

Fair enough. As for the crash-to-desktop issue, back in the day you had to worry about crash-so-hard-it-locks-up-the-entire-computer-and-even-control-alt-del-won`t-work-not-even-reset-gotta-pull-the-plug. CTD ain`t so bad, compared to that, eh? One of the things that often seems like it-couldn`t-possibly-be-related-to-my-issues but manages to help anyway too often to ignore is to make sure that your drivers are all up-to-date. Check on that, please, and let me know if it helps, ok?

Just downloaded the route into a clean TRS22 Plus 123794 with missing assets.

<kuid:400089:102491> n_man 2
<kuid2:400089:43:1> C random people
<kuid2:60850:23804:3>
<kuid2:1942:25020:1>
<kuid2:425700:101356:1>
<kuid2:60238:37036:1>
<kuid:400089:101996> c_school
<kuid2:1942:25012:1>
<kuid2:1942:26036:3>
<kuid:400089:102004> c_admin zdanie 2
<kuid2:134105:28044:1>
<kuid2:82412:5000588:1>
<kuid:400089:102540> n_man walk 4
<kuid:400089:101941> c_torg centr
<kuid2:82412:614145:1>
<kuid2:60850:23805:3>
<kuid2:82412:611314:1>
<kuid2:68236:100146:1>
<kuid2:425700:100082:2>
<kuid2:124017:10053:3>
<kuid2:68236:23301:3>
<kuid2:68236:23301:4>
<kuid2:1942:25017:1>
<kuid2:82412:49891006:1>
<kuid2:60850:23806:3>
<kuid2:82412:614146:1>
<kuid2:82412:614125:1>
<kuid2:82412:614182:1>
<kuid2:82412:614167:1>
<kuid2:52:28119:1>
<kuid2:82412:5000585:1>
<kuid:134105:45001>
<kuid:378673:100056>
<kuid2:52:28120:1>
<kuid2:328583:16037:1>
<kuid:565830:100167>
<kuid2:82412:614163:1>
<kuid2:82412:614176:1>
<kuid2:82412:614164:1>
<kuid:103475:37012>
<kuid2:82412:614174:1>
<kuid:146087:70019>
<kuid2:1942:25027:2>
<kuid2:82412:611313:1>
<kuid2:52:37361:2>
<kuid2:1942:37008:2>
<kuid2:523:1142:2>
<kuid2:82412:44040:2>
<kuid2:76656:80100:10>
<kuid2:82412:333201:2>
<kuid2:82412:5000594:1>
<kuid2:342053:25042:2>
<kuid2:342053:25049:2>
<kuid2:523:1113:3>
<kuid2:82412:885182726:2>
<kuid2:60238:38212:1>
<kuid2:68236:100155:1>
<kuid2:82412:885182720:2>
<kuid2:71378:1805:1>
<kuid2:661281:44310:1>
<kuid2:82412:24031:2>
<kuid2:1942:25023:2>
<kuid2:82412:50003007:2>
<kuid2:60850:23807:3>
<kuid2:134105:28043:1>
<kuid2:1942:25018:1>
<kuid:342053:25942>
<kuid2:82412:5000571:1>
<kuid2:262137:10251:1>
<kuid:342053:25943>
<kuid2:328583:20398:1>
<kuid2:328583:20414:1>
<kuid2:328583:20430:2>
<kuid2:84912:29270:4>
<kuid2:60850:23802:3>
<kuid2:439337:100845:1>
<kuid2:661281:44239:2>
<kuid:342053:25944>
<kuid2:1942:11000:1>
<kuid2:122285:3320:21>
<kuid2:1942:25005:1>
<kuid2:1942:25015:1>
<kuid2:1942:25019:1>
<kuid2:1942:25025:1>
<kuid2:1942:25032:3>
<kuid2:60238:26032:1>
<kuid2:82412:5000583:1>
<kuid2:82412:23008:1>
<kuid2:60850:23113:6>
<kuid:59940:20502>
<kuid2:60238:26:1>
<kuid2:60238:26127:1>
<kuid2:82412:23023:1>
<kuid2:60850:23801:3>
<kuid2:60850:23803:3>
<kuid2:82412:23024:1>
<kuid:60850:27120>
<kuid2:64038:27780:1>
<kuid2:64038:272414:1>
<kuid2:35412:28282:1>
<kuid2:68236:39002:1>
<kuid2:82412:5000555:1>
<kuid2:82412:5000554:1>
<kuid2:82412:5000595:1>
<kuid:134105:28075>
<kuid:370528:1291>
<kuid:342053:25909>
<kuid:283805:28550>
<kuid:342053:25789>
<kuid:342053:25908>

I am missing a lot of TUME assets. I don't know whether they were meant to be part of one of the built-in routes for an earlier version of Trainz but I have seen this in both UK and European routes:
<kuid2:82412:44040:2>
<kuid2:82412:23024:1>
<kuid2:82412:333201:2>
<kuid2:82412:614125:1>
<kuid2:82412:614146:1>
<kuid2:82412:614164:1>
<kuid2:82412:614167:1>
<kuid2:82412:614182:1>
<kuid2:82412:5000583:1>
<kuid2:82412:5000585:1>
<kuid2:82412:5000588:1>
<kuid2:82412:50003007:2>
<kuid2:82412:885182720:2>
<kuid2:82412:885182726:2>
Also two of your own
<kuid:134105:28075>
<kuid:134105:45001>
And six Domsarto:
<kuid:342053:25909>
<kuid:342053:25789>
<kuid:342053:25908>
<kuid:342053:25942>
<kuid:342053:25943>
<kuid:342053:25944>

Kind regards,

Gary