Wait for Trigger command issue

Cheers everyone, I'm new here.

Bought TRS19 some time ago, but only recently tried to create my own sessions, and found out I can't use waitfortrigger command. It worked perfectly fine in TRS12 (which is what I was playing before). When I try it - it just blurs out, or "greys out", whatever you can call it. Here's a pic:

https://imgur.com/NJ88ng6

It's really frustrating. The only thing I found on the internet is that maybe an issue when you create too many trains, well I have 4, is that too much now? Tried it on different routes, and it's the same result.

PS - the same thing happens with the Decouple command. I don't understand it. Maybe it's a known issue, can somebody help me with this?

The WaitForTrigger driver command is working without any problems in the Driver Setup Rule in my TRS19 SP1 (build 104261). I very rarely use it so I cannot say if it was working or not in earlier TRS19 builds but it worked in TANE.

The Decouple driver command cannot be used in the Driver Setup Rule. There are alternatives that can be used instead - see the Trainz Wiki at http://online.ts2009.com/mediaWiki/index.php/Driver_Commands_List#Train_Operation_Commands

Judging by the Russian characters in the UI, perhaps the trigger rule doesn't like non-English characters in the trigger names? (Just a thought).

I have come across with the same problem in the later beta builds (I am using Build 104261)
I have a large route and using the trigger rule and it worked fine in TANE and the early TRS19. The problem appears to that if I set up a new trigger I can not select the trigger as the WaitForTrigger selection is "greyed out".

TS19
Build 100240.

I also have this problem and can not run one of my routes due to this. It was working fine in the early construction stages, but now it went on strike and refuses to work. Even the commands that were already set in place now just do nothing but hang up. If I fire off a fresh route build, it works fine. Even driving other routes where the issue did not present itself still uses the rule as advertised. I suspect that there is something locally specific our affected routes/sessions going on here, and nothing on a global scale. I am only guessing here, but, could this rule be timing out after the trigger count gets too high? Now that I think about it, I see this happening on my larger route builds with the smaller ones escaping unaffected. Hmm...

maruffijd said:

TS19
Build 100240.

<snip>

I am only guessing here, but, could this rule be timing out after the trigger count gets too high? Now that I think about it, I see this happening on my larger route builds with the smaller ones escaping unaffected. Hmm...

Click to expand...

That possibility also occurred to me so I ran some tests. I normally only use about 10-20 triggers in a route and have never come across this problem - so how many is "too high"?

I created a test route and session in build 104261 with 75 triggers and the WaitForTrigger driver command worked perfectly - both when adding the command to a drivers command bar and in its operation. I then transferred the route and session to build 100240 and saw the same result.

Perhaps more time (and mouse clicking energy) is needed to significantly increase the trigger count well above 75 and try again?

EDIT: I just doubled the number of triggers to 150 and the result is the same.

I encountered these difficulties after upgrade to TRS2019. Prior to upgrade I was using Tane where Triggers Appeared to work without the need to follow the procedure that I have outlined below.
This is my current procedure.
1 - Select the route to edit
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138041
2 - Select Sessions & Select Edit Session
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138040
3 - Select Track Icon then Track Mark Icon then Trigger
4 - Add Trigger in required position on the track. Provide the trigger with a recognisable name. As you are operating in Edit Session you need to select the ? mark then the Trigger and change Layer to Route Layer.
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138042
5 - Select Edit Session, 2nd Icon top left. If this is the first trigger - Select ADD, Bottom left, and add Driver Command "Trigger Check".
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138043
6 - Select this new Trigger Check command and select Edit. Add the train.
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138044
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138045
7 - While remaining in Edit session - Select ADD, again and Add DRiver Command "Trigger Rule"
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138046
8 - Select this new Trigger Rule command and select Edit. Add the train.
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138047
https://www.trainzportal.com/mytrainz/view_media_post?media_post_id=138048

I decide to add a "Trigger Rule" for each Trigger, not sure if this is required, however it provides a quick reference to the applicable trigger.

That is my two bob's worth.

pware said:

That possibility also occurred to me so I ran some tests. I normally only use about 10-20 triggers in a route and have never come across this problem - so how many is "too high"?

I created a test route and session in build 104261 with 75 triggers and the WaitForTrigger driver command worked perfectly - both when adding the command to a drivers command bar and in its operation. I then transferred the route and session to build 100240 and saw the same result.

Perhaps more time (and mouse clicking energy) is needed to significantly increase the trigger count well above 75 and try again?

EDIT: I just doubled the number of triggers to 150 and the result is the same.

Click to expand...

My trigger count is 350+. I found out the driver command also counts other types of triggers beyond the little green cross trigger. It also includes triggers like all the ATLS trigger types, The sound bells and sound horns just to name a few. I think the command looks at all triggers that are true triggers regardless of their intended purposes. Food for thought...

pware said:

The Decouple driver command cannot be used in the Driver Setup Rule. There are alternatives that can be used instead - see the Trainz Wiki at http://online.ts2009.com/mediaWiki/index.php/Driver_Commands_List#Train_Operation_Commands

Click to expand...

Thanks, I'll look into that.

Tony_Hilliam said:

Judging by the Russian characters in the UI, perhaps the trigger rule doesn't like non-English characters in the trigger names? (Just a thought).

Click to expand...

Nah, it's not that. My game version is Russian, but everything I type in (drivers, triggers, etc) is in English.

jhatchman said:

I have come across with the same problem in the later beta builds (I am using Build 104261)
I have a large route and using the trigger rule and it worked fine in TANE and the early TRS19. The problem appears to that if I set up a new trigger I can not select the trigger as the WaitForTrigger selection is "greyed out".

All existing Triggers work fine. I have tried to set up a small test route in Build 104261 and it appear to work ok.​

​

​

Click to expand...

maruffijd said:

TS19
Build 100240.

I also have this problem and can not run one of my routes due to this. It was working fine in the early construction stages, but now it went on strike and refuses to work. Even the commands that were already set in place now just do nothing but hang up. If I fire off a fresh route build, it works fine. Even driving other routes where the issue did not present itself still uses the rule as advertised. I suspect that there is something locally specific our affected routes/sessions going on here, and nothing on a global scale. I am only guessing here, but, could this rule be timing out after the trigger count gets too high? Now that I think about it, I see this happening on my larger route builds with the smaller ones escaping unaffected. Hmm...

Click to expand...

My build is 100332. I too have a small test route and I've tried WaitForTrigger - it all works fine, that's the strange thing. It's interesting you guys thinking maybe it's a number of triggers on the route that crashes things out. Because, here it says
"The presence of a large number of locos in a session can cause this command to fail due to a timeout error" (http://online.ts2009.com/mediaWiki/index.php/Driver_Commands_List#WaitForTrigger) - so I've managed to delete some trains from one of the bigger routes I have, and WaitForTrigger started to work again. As soon as I added a few trains back - it greyes out again. But why it works on my test route, no matter how many trains I add? It's odd. Maybe it's both things? I mean, maybe it's a number of trains AND a number of triggers that create the problem?

RBrooks said:

Thanks, I'll look into that.



Nah, it's not that. My game version is Russian, but everything I type in (drivers, triggers, etc) is in English.




My build is 100332. I too have a small test route and I've tried WaitForTrigger - it all works fine, that's the strange thing. It's interesting you guys thinking maybe it's a number of triggers on the route that crashes things out. Because, here it says
"The presence of a large number of locos in a session can cause this command to fail due to a timeout error" (http://online.ts2009.com/mediaWiki/index.php/Driver_Commands_List#WaitForTrigger) - so I've managed to delete some trains from one of the bigger routes I have, and WaitForTrigger started to work again. As soon as I added a few trains back - it greyes out again. But why it works on my test route, no matter how many trains I add? It's odd. Maybe it's both things? I mean, maybe it's a number of trains AND a number of triggers that create the problem?

Click to expand...

Years ago, I found exactly the same conclusion you have: The number of locos used would make this command inoperative, perhaps due to the timeout error. Issue was shown to helpdesk and made public several times here. It did not happen in TS12. Finally I took it as a price to pay for "progress", and went on with life. At least, N3V should have the decency of issuing a statement outlining what is the "recommended maximum number of locos accepted", and if this is a fixable issue for future SP's.

People, I found the solution. Well, KIND OF.

There's a driver command named "VarniTriggernelParancs", it's on DLS (<kuid:293370:100006>), I think it basically repeats WaitForTrigger script, based on description. And... it works. So far, it worked where WaitForTrigger didn't for me! So, guys, this is it, if you need it - use it instead.

llebrez said:

Years ago, I found exactly the same conclusion you have: The number of locos used would make this command inoperative, perhaps due to the timeout error. Issue was shown to helpdesk and made public several times here. It did not happen in TS12. Finally I took it as a price to pay for "progress", and went on with life. At least, N3V should have the decency of issuing a statement outlining what is the "recommended maximum number of locos accepted", and if this is a fixable issue for future SP's.

Click to expand...

Yeah, and this issue doesn't even make any sense. I had only 4 trains on the route, with 3 it worked, with 4 it didn't. Like, 4 is too much already? :hehe:

And there is a basic in-game session with trains, which are operating by waitfortrigger rule, and it works for them. Why can't I do the same? Weird. Thankfully, it looks like I found the work-around.

1) With a name like that, we come to think that extraterrestrials are around. Indeed the command exists and it downloads plus it shows in the list of commands.
2) So I green tick on it and go to a session, open the commands available for a particular loco. Still I have what I had before, but this VarniTrig is not there. Pretty much as the Waitfortrigger effect.

I have to mention that during the age of TS12 this particular command (Wait for trigger), would work but made for a slow reaction to selecting commands. Normally you click on the icon and the list of commands would take 1 or 2 seconds to appear. Because of that, I decided not to green tick it, and then everything returned to normal (fast reaction time). Since I keep record of most of what I do, I can attest that I have mentioned this 3 times over the course of years to helpdesk and more times here in the forums.

Later I have "discovered' that using Check for trigger rule and indent other rules, I can do pretty much what this command do, so why bother?

RBrooks said:

Yeah, and this issue doesn't even make any sense. I had only 4 trains on the route, with 3 it worked, with 4 it didn't. Like, 4 is too much already?

Click to expand...

If it's a timeout issue then that result is quite possible. Something in the rule itself means that there is a timeout problem when there are too many trains. But it's other things in the game (including the route, other rules, the sequence of the rules, even the PC specs) that determines how many trains is too many.

SailorDan said:

If it's a timeout issue then that result is quite possible. Something in the rule itself means that there is a timeout problem when there are too many trains. But it's other things in the game (including the route, other rules, the sequence of the rules, even the PC specs) that determines how many trains is too many.

Click to expand...

As creators produce larger and larger layouts, some with hundreds of baseboards, it is inevitable that these timeout issues occur more frequently. When I wrote my scripts awhile back, I called the system for a list of maybe 10 or 20 trackmarks. Now they can number in the hundreds. There is no practical way for N3V to tell you the limits with the mixture of objects.

The TimeOut thing is not a malady associated to WaitForTrigger coomand. It also happens with commodities and perhaps others. I am no expert, but it seems that when there is a function that requires scanning hundreds of items, it takes too long and generates the error. Then maybe that scanning could be limited to a maximum the program considers acceptable, and if required, do a second scanning for the rest. As it is now, when the number of consists or commodities exceeds the time alocated for the thing to work, it just stops. Again this may not be what is causing the error, but in my humble understanding, could be. And I have no solution, as this is very intricate beyond my qualifications.

llebrez said:

The TimeOut thing is not a malady associated to WaitForTrigger coomand. It also happens with commodities and perhaps others. I am no expert, but it seems that when there is a function that requires scanning hundreds of items, it takes too long and generates the error. Then maybe that scanning could be limited to a maximum the program considers acceptable, and if required, do a second scanning for the rest. As it is now, when the number of consists or commodities exceeds the time allocated for the thing to work, it just stops. Again this may not be what is causing the error, but in my humble understanding, could be. And I have no solution, as this is very intricate beyond my qualifications.

Click to expand...

I'm no programmer, although I did do some while taking college classes. From what I can see you might be on to something.

The program now loads up all of the of track marks by using a scan command to scan for track marks. The problem now is this takes awhile and that causes the timeout. The time-out is a sacrifice for better performance overall and fewer stutters as scripts sit there and load everything in one shot.

To get around this one shot, but still needing to load a bunch of track marks and not want to quit in the middle of the scan, which happens now with the time-out, this could be run multiple times and check for the first 100 track marks. This group of 100 track markers are counted and are recorded in a table. The loop repeats and does another check, if more are found, these are placed in the table, and the routine repeats until no more are found. Once there are none, it stops and goes on to the next steps.

The way I see it is the smaller runs overcome the timeouts by repeating the gathering step in smaller loops instead of attempting to load everything at once into memory. This scheme could work for other things too such as train numbers, signals, and so on.

How this gets implemented, if it's possible at all, is left up to the programmer gurus to figure out.

Two other items that are affected by timeouts (or so I believe) that I know of are the Autodrive driver command and the Driver Setup Rule*. Both involve "too many" locos in a session.

JCitron said:

The way I see it is the smaller runs overcome the timeouts by repeating the gathering step in smaller loops instead of attempting to load everything at once into memory. This scheme could work for other things too such as train numbers, signals, and so on.

Click to expand...

That is exactly the recommended workaround for the Driver Setup Rule timeouts. Split the drivers being allocated to locos into two separate copies of the Driver Setup Rule and place the second copy as a child of a Wait Rule which has been set to a delay of 1 or 2 seconds.

EDIT: * reported as fixed in TRS19 SP1 beta and Trainz Plus beta.

Several observations/comments. The WaitforTrigger Command and Autodrive both seem to suffer from the same issue. When there are too many trackmarks and/or triggers in the route both of these rules seem to close down (grey out in the selection menu).

John mentions a idea of multiple scans which would be a work around for the timeout issue.

But the Navigate to Trackmark and Navigate via Trackmark commands do not suffer from this issue, at least that I have seen to date. So what is different in the way the Navigate commands scans the available trackmarks from the way WaitforTrigger and Autodrive commands scans the commands?

Why don't the Navigate commands suffer from the same time out issue? I know nothing about the inner workings of these commands, but it would appear that they work in completely different ways in assembling the lists of available trackmarks.

Paul_Bert said:

The WaitforTrigger Command and Autodrive both seem to suffer from the same issue. When there are too many trackmarks and/or triggers in the route both of these rules seem to close down (grey out in the selection menu).

Click to expand...

From testing that I and others have done, the problem does not appear to be too many trackmarks or triggers. One tester had 350 triggers in a route without any problems with the WaitForTrigger command but adding or subtracting drivers did affect the command.

Generally speaking, the "scans" are now done with asynchronous API calls. However, the programmer cannot predict when they will complete. Also, if the returned data is large, the currently executing code might time out processing it. Code written in the past may not have been upgraded to async.