Wait for Trigger command issue

pware said:

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.

Click to expand...

Agreed. See this test I made (time ago):

A rather medium route (120 boards or so) filled with all kind of triggers trackmarks and everything. Create a session of it. There is only one loco at this point. Wait for trigger works. Start populating the session, and (Very tedious to do) when I get to 32 locos, Wait for Trigger stops working. Great! you may say: we have the magic number. Nope, do another test with a different route, same number of locos and this time by when I get 18 locos, Wait for Trigger stops working! So what is going on here?

Now a second instance on commodities: Make a route with 2 or 3 industries and populate about 4 commodities on them. Commodity picker works, and you can see the menu showing available commodities for you to assign these to cars. But if you increase the variety of commodities (not the number, variety), at some point the picker shows nothing. Probably due to the same timeout effect due to "too many commodities". And just to be sure I am talking about commodities built-in that show no errors.

At the transition from TS12 to one of the SP's, I remember reading somewhere that for the sake of performance, timeout issues would show. But that is long ago. Hard to believe that after "The best ever" and "Best in the World" hips, things are still as they were for so long. To quantify (in my view), We have gained 30% in graphics, but 0 or very little on minute things like what we are discussing here.

pware said:

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.

Click to expand...

Is this a case of the additional drivers causing multiple scans at the same time? Could these be offset by a short period to ensure that each driver scan doesn't hog the process?

Thanks RBrooks, I've been having the same problem with Wait for Trigger. Tried the VarniTriggernelParancs above and it works fine for me as well.:Y: Only apparent difference when using it is the title. I'm using build 103369 at present.

huddo said:

Thanks RBrooks, I've been having the same problem with Wait for Trigger. Tried the VarniTriggernelParancs above and it works fine for me as well.:Y: Only apparent difference when using it is the title. I'm using build 103369 at present.

Click to expand...

You're welcome, I hope more folks will find this command on DLS, because that was an issue for months, basically since the game was released.

I didn't look through it's script, maybe it has some different features, but if the title concerns you, you can change the name in config.txt, you can name it "Wait for Trigger that actually works", or smth :hehe:


PS - I can confirm, that it fully works, I did LOTS of testing last night, it worked every time, flawlessly.

pware said:

(SNIP) 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. (SNIP)

Click to expand...

Interesting. I knew about the spilt the drivers between 2+ rules, but did not think about a delay for the add on rules. Back to the Lab post haste for me...

RBrooks said:

You're welcome, I hope more folks will find this command on DLS, because that was an issue for months, basically since the game was released.

I didn't look through it's script, maybe it has some different features, but if the title concerns you, you can change the name in config.txt, you can name it "Wait for Trigger that actually works", or smth :hehe:


PS - I can confirm, that it fully works, I did LOTS of testing last night, it worked every time, flawlessly.

Click to expand...

Can anyone confirm it works in TANE?

When creating a session for TANE ECML I found that the Call at and Wait for Trigger did not even appear. These appeared in all smaller routes.
I would use the Trigger Rule instead but I can't work out to tie this into a driver command. Mostly I use the command to trigger the movement of another train.

Ken

KenGreen said:

When creating a session for TANE ECML I found that the Call at and Wait for Trigger did not even appear. These appeared in all smaller routes.
I would use the Trigger Rule instead but I can't work out to tie this into a driver command. Mostly I use the command to trigger the movement of another train.

Ken

Click to expand...

First I experience exactly the same. Second, the Call at I assume is related to the number of stations you have, not trackmarks or commoditites. It could also be related to the number of consists, so in this case the timeout issue must be related to this. Interesting is that I haven't seen any comments from N3V on this thread, or subject...

Wait for trigger works fine for me in TANE SP4 build 102323 but greys out in TRS19! Bit odd. I use call at for all stations and it works fine in both versions. Bit disappointed that the latest, high tech, trainz game i.e. TRS19 has a problem with 'wait for trigger' command, yet in older versions works fine.

Now why is that?

Hi All
One suggestion to help with tracking down this issue would be to enable the 'show script exception notifications', in case there is a script error occurring to cause this.

You can enable this setting by following these steps:

1) Double click on the Trainz icon on your desktop
2) Click on Trainz Settings
3) Click on the 'Dev' tab
4) Tick the option for 'show script exception notifications'

Please then try adding the command, and see if a script exception (the red bug icon) appears.

Please note, some larger routes with lots of trackmarks or triggers present on the route may cause these driver commands to time out, resulting in the command not functioning (or not functioning correctly), or causing a script error to appear. In this case, the fix is to remove any exceed trackmarks or triggers. For TANE, the only way to do this will be to add a new layer to your session, name it something you will remember ('hidden' works well here), set the visibility to 'hidden' by clicking on the eye icon, and then follow these steps:
1) Open the tracks tab
2) Go to 'trackmark' mode
3) Select the Properties tool (the ? icon)
4) Click on a trackmark you wish to hide/remove
5) Click on the 'bound layer' drop down box, and select your new 'hidden' layer
6) Click the checkmark in the properties window.

The trackmark should then disappear.

Unfortunately for some extremely large routes, such as the ECML routes, this may be quite a lengthy process.

A few comments on Zec suggestion: I refuse to eliminate trackmarks or triggers ( I need them for operations and I use them sparingly only as needed). Instead, Using rules and child ones I effectively do the same as Wait for trigger with even more refined capability. So, the Time Out issue has no demeaning effect when related to triggers (at least to me), but what about due to excess commodities?, is this mean that we should reduce the number of consists and commodities? Indeed, several years ago I did the "show script exception notes" and it showed a time out error. So, is good we understand what is happening, but I think the solution of cutting an arm (or a leg) is a draconian one.

I have tried the suggested alternative VarniTriggernelParancs but unfortunately with TANE ECML it still doesn't show.
Zec's suggestion is quite useful BUT this is something for N3V to test out. My view is that if you run a number of AI trains on ECML then the wait for trigger is essential.

Ken

I am having this issue. I enabled 'show script exception notifications' and here's what came up:

WaitForTriggerCommand : File menu.gs, Line 82, ER_Timeout

function
$void@WaitForTriggerCommand::AddCommandMenuItem(DriverCharacter,Menu), line 38

This error appeared twice, along with an unrelated JR script error.

acyunczyk said:

I am having this issue. I enabled 'show script exception notifications' and here's what came up:

WaitForTriggerCommand : File menu.gs, Line 82, ER_Timeout

function
$void@WaitForTriggerCommand::AddCommandMenuItem(DriverCharacter,Menu), line 38

This error appeared twice, along with an unrelated JR script error.

Click to expand...

At the Launcher, click on settings.

Then click on Dev and on the Compatibility scroll box, choose Maximise compatibility.

JCitron said:

At the Launcher, click on settings.

Then click on Dev and on the Compatibility scroll box, choose Maximise compatibility.

Click to expand...

This is in T:ANE.

acyunczyk said:

This is in T:ANE.

Click to expand...

You faked us out by posting in the TRS19 forum!

Check the DLS for a newer version. Some of these driver rules have been updated and this maybe one of them.

This thread was linked in my own thread on this topic. I just looked at the asset versions, and I have the latest version.

Just a quick heads up for those who's interested in using VarniTriggernelParancs rule.

It works well until there are 40 locos on the route session (it was in my case, at least). Thankfully, I barely managed to create a good session on a relatively big map with only 40 (I actually used 50 or even more, but some of them didn't have to use the trigger rule, so it was fine).