Multiple Timeout Errors

Hello,

Okay, so on Trainz 12, I built all but the Pascack Valley & Atlantic City lines of the NJ transit system (138 stations), but building in surveyor there has become painstakingly slow and laggy... like one single frame per second laggy.
I decided to try and import the route into Trainz 2019. I am getting timeout errors that I never encountered in Trainz 12.

I built nearly every station using AJS' invisible platforms in order to control the amount of cars that will open their doors at each station, as they have different lengths, and used the "Call At" command in conjunction.

The issues I encounter in 19 now is that when I try to use the "Call At' command manually, like in driver to schedule it for one of the trains, the menu doesnt come up ("Call At" gets greyed out) and I get a timeout error that reads:

- <kuid2:122285:3499:23> : File stationlib.gs, Line 809, ER_Timeout
; <kuid2:122285:3499:23> : Script class: StationLib
; <kuid2:122285:3499:23> : Object: ScriptableObject{0x76d18fe0; asset:SpecReference{<kuid2:122285:3499:23> "AJS Station Library"}, class:GSClass{0x7044e2e0: StationLib}, refcount:523}
; <kuid2:122285:3499:23> : Object: ScriptableObject{0x76d18fe0; asset:SpecReference{<kuid2:122285:3499:23> "AJS Station Library"}, class:GSClass{0x7044e2e0: StationLib}, refcount:523}
; <kuid2:122285:3499:23> : Object: ScriptableObject{0x76d18fe0; asset:SpecReference{<kuid2:122285:3499:23> "AJS Station Library"}, class:GSClass{0x7044e2e0: StationLib}, refcount:523}
; <kuid2:122285:3499:23> : Object: ScriptableObject{0x76d18fe0; asset:SpecReference{<kuid2:122285:3499:23> "AJS Station Library"}, class:GSClass{0x7044e2e0: StationLib}, refcount:523}
; <kuid2:122285:3499:23> : Object: ScriptableObject{0x76d18fe0; asset:SpecReference{<kuid2:122285:3499:23> "AJS Station Library"}, class:GSClass{0x7044e2e0: StationLib}, refcount:523}


However, the scheduled commands i had preset from trainz 12 still execute with no problem. The issue renders me unable to add any new scheduled stops.

For Reference:

https://imgur.com/a/EeuanbX

Crazypologuy,

For station stops (over 100+ AJS Stations): use PGUY's drivercommands

• <kuid2:61392:7002:28> DriveToStation v2 (SP3 and later) DriveToStation drives to a random available platform at station. AI will take the shortest path to reach its intended destination in a schedule.
  
• <kuid2:61392:7005:28> NavigateToStation v2 (SP3 and later) NavigateToStation navigates to a random available platform at station. AI will attempt to detour to another path if the leading train is using the same path to reach its intended destination in a schedule ie: the lead train is going slower than the one tailing.

The station name follows andi06 virtual naming convention
station[extension]
with extension of type xx-cccc where xx is the virtual platform number of the first real station platform
examples : station A[1-West]
station A[3-East]
And for industries:
use auran's default commands

• <kuid:-3:10058> Navigate To
  
• <kuid:-3:11058> Drive To
  

They should both be limitless and shall not address timeouts on larger, dense routes.
But keep the trainz log window active so you can observe what is going on.

since call at is unusable due to the resultant of Andi06's death which he passed away several years ago after stopping making content. A beloved creator in trainz sadly has already departed off the forums. Not criticizing just cos I say this.

Sadly many scripts time out in TRS19/22


trs2009 and trs12 could handle more stored data in rules etc.


examples that often time out here:
-wait for trigger
-Portal timetable rule
-Path rule
-too many industries and its gameover for drivercommands


often a rule can be used 2x, with less data each, then it works
but it can't be that the newer Trains can't handle really big routes
the problem will only get worse.

G.M. said:

Sadly many scripts time out in TRS19/22


trs2009 and trs12 could handle more stored data in rules etc.


examples that often time out here:
-wait for trigger
-Portal timetable rule
-Path rule
-too many industries and its gameover for drivercommands


often a rule can be used 2x, with less data each, then it works
but it can't be that the newer Trains can't handle really big routes
the problem will only get worse.

Click to expand...

This is a dual-edged sword type of situation. The reason for the timeouts is because people complained about big stutters and pauses that were so common in TS12 and below. To improve the efficiency of the program and reduce the stutters, the timeout was put in place.

What was causing the stutters?

There were many causes including really poorly created assets such as Smart Cars with 100K polygons, and really, really huge buildings with no LOD. But even after solving those issues by putting in error messages and warnings to fix the assets, the next more drastic step took place which was to enforce a timeout period on errant scripts.

There are many scripts that build tables as you know, that reference such things as track marks, signals, commodities, train numbers, and so on. Instead of limiting a range for the data, the tables are built to catalog every instance of that object. This works fine for small routes, and these worked fine in the beginning when Trainz wasn't as complex as it is today. With today's complex routes, the answer was to impose a timeout on the processes to reduce the long pauses during the simulation.

The two classic examples of these timeouts caused by too much of a good thing are ARN and commodities. Some freight cars for instance had a road number range in the 100,000-plus range. When the cars were placed, there was an instant timeout. After some poking around, I came upon the range in one of the freight cars and reduced that to 50 road numbers max and that solved the problem.

Commodities do the same with industries and for the freight. When every iteration of every possible combination of what a hopper can carry, for example is included, that presents a problem. Placing these hoppers in TS12 meant waiting and waiting for the hopper to appear before placing the next one. By reducing the number of commodities to a reasonable amount, the performance increased substantially.

As I said it's a dual-edged sword type of situation and believe me I'm annoyed with this as well.

If the cure is worse than the illness, its not good
people will make and want larger routes, a process that can't be stopped.


My own main route is 400km north to south and 200km east to west, 6k baseboards
it runs fluent with 45 passenger trains, but only cause i take great care what i use
that responsibility is with the route/session creator.


Limiting Trainz because some people make ego or bad content is not good.


To help out, I made a trackmark that warps you to another route/session
so you don't have to merge, but it's a temp solution.


if scripts/rules/commands are known to timeout, they need to be repaired
when base or built-in by n3v, otherwise by a content creator.
always willing to help if needed.

G.M. said:

If the cure is worse than the illness, its not good
people will make and want larger routes, a process that can't be stopped.


My own main route is 400km north to south and 200km east to west, 6k baseboards
it runs fluent with 45 passenger trains, but only cause i take great care what i use
that responsibility is with the route/session creator.


Limiting Trainz because some people make ego or bad content is not good.


To help out, I made a trackmark that warps you to another route/session
so you don't have to merge, but it's a temp solution.


if scripts/rules/commands are known to timeout, they need to be repaired
when base or built-in by n3v, otherwise by a content creator.
always willing to help if needed.

Click to expand...

You're preaching to the choir here on this. There shouldn't be a bandage used to fix the leaking pipe and the pipe should be fixed. The built-in scripts were those that were made by others and worked in the past. Like everything we have it's an amalgamation of old and new at the same time. With many of the scripts encrypted, repairing them becomes a bigger issue and I think that's part of the problem in addition to the lack of manpower and hours to do any kind of script updates.

That track mark sounds very helpful. I use i-Portals for that now and they work pretty well. I have a couple of really huge routes I built in the past but maintaining them became an issue when sessions had to be rebuilt due to various reasons. It was then I decided to try the i-Portals and they work great for that because I can maintain smaller segments a lot easier.