WaitforTrigger problem

[Fineas10]

Hello! I was trying to use the waitfortrigger command, and I found out that is not working in Trainz 22. People are saying it is because of the number of trains that are on the map, but it doesn't seem to be the issue for me. Any ideas? Thank you!

 

[pware]

The best advice I can give is to submit a bug report at https://n3vgames.typeform.com/to/xRdryu

TRS22 is currently a beta version only so bugs are to be expected.

 

[Tony_Hilliam]

A simple test here indicates it's working fine. When you submit your bug report, please include all the details including KUID for the command, steps used to set the command up, how many triggers on your route etc.

Trainz Bug Report

 

[G.M.]

It cannot be found/solved by just running a simple test


Many drivercommands will eventually timeout and greyout, why?
people have faster PC's and use bigger routes and drive more trainz
yet the underlying system often using that new async search can't cope


Too many triggers, too many industries, too many trainz and, boom grey out
so hope in the future, a system can be designed/implemented, that has no limits
(or a simple popup: Loading please wait...)


One step i made here, is script a trigger that brings you to the next session/route
this gives me unlimited route size, it simply load the next part (many games work this way)

 

[JCitron]

It cannot be found/solved by just running a simple test


Many drivercommands will eventually timeout and greyout, why?
people have faster PC's and use bigger routes and drive more trainz
yet the underlying system often using that new async search can't cope


Too many triggers, too many industries, too many trainz and, boom grey out
so hope in the future, a system can be designed/implemented, that has no limits
(or a simple popup: Loading please wait...)


One step i made here, is script a trigger that brings you to the next session/route
this gives me unlimited route size, it simply load the next part (many games work this way)

The timeout condition was introduced in TANE due to the awful performance we experienced in TS12 and prior versions. It was a trade-off for having unlimited trains, doodads, and commands, or suffering from constant stutters. The reason for many of the timeouts is that these commands and scripts search an entire route for assets associated with the script. With larger and larger and more complex routes and driver schedules, these commands would take forever to process and hog processing for long periods of time, and this is what caused the awful pauses and stutters we experienced in TS12. One of the nondriver related scripts to suffer from this is ARN. Some content creators put in 100,000 or more number ranges for various wagons. This caused massive timeouts, and in TANE produced the famous red bug to appear. I discovered this and reduced my road numbers down substantially for various wagons and that resolved the problem. Having 100 possible boxcars is more reasonable than 100,000 boxcars in the same series. Even with the smaller number, I don't think we'll see the same one twice.

Your new script sounds interesting. Right now, I've been using iPortals to achieve the same thing. I experimented with them and applied them to a couple of routes and now I'm going through the arduous task of setting up the sessions and populating the routes and basic portals.

 

[G.M.]

One thing we could have learned from the past
setting a max (limitation) for anything on a PC will eventually bite you hard
remember dos names 8.3, the 2MB file size, the millenium bug etc etc.
Trainz in 2021 soon 22 should have the limitations removed as much as possible
they were needed in the past, but now our PC's are 10x as fast.
On the other hand people should think before making resource hogging content.


the Sessiontrigger topic is here
including a working version

 

[JCitron]

One thing we could have learned from the past
setting a max (limitation) for anything on a PC will eventually bite you hard
remember dos names 8.3, the 2MB file size, the millenium bug etc etc.
Trainz in 2021 soon 22 should have the limitations removed as much as possible
they were needed in the past, but now our PC's are 10x as fast.
On the other hand people should think before making resource hogging content.


the Sessiontrigger topic is here
including a working version

I agree on you about the limitations. The issue was these scripts were written in such as a way as to lock down program threads for long periods of time with long periods being relative to computer time. The thread hogging prevented other resources from being used and cause the program to halt. These limits right now, I agree may bite us in the future, but who knows because the way things work now that may change. How quickly? You know how slow things go around here.

Thank you for the link. I'll take a look at it.