Trigger Issue

I cannot get the Trigger to activate another train. Train arrives from portal travels across the trigger. It stops at a trackmark, uncouples and the engine returns to the portal. The trigger should have activated a waiting engine to now couple to the consist dropped by the original train and proceed to an assigned activity.

But, the waiting engine that is to take the consist to the activity never moves. I have tried moving the trigger and different waiting engine to no avail. This worked in ts2019 a few years ago. The wait for trigger thing does not seem to work. Spent hours yesterday trying various things.

Addendum: More work. Eventually was able to trigger another train with a portal emitted train. However, the triggered train ran through the now stopped emitted train to couple to the front of it. No damage to either the train or the engine as it properly coupled to the undamaged train and proceeded with the task.

AI (at least here) has issues. Unfortunately, not using it results in a rigid task. Using AI allows for reasonable changes in time or other conditions and the AI should adapt and complete its task. But... Running the same task structure over and over is boring. Weather or fictional delays to arriving and departing trains adds flavor. Variables makes the program interesting IF they work consistently.

I have deleted that schedule process and will look at other avenues - Thanks For Reading

I have learned to give emitting portals a wide berth - like one baseboard's worth - especially since the developer made the irrational decision, in TRS19, to have portals, a theoretical construct we imagine, operate under a real world-emulating physics package. This attempted fusion of the the theoretical with hard equations seems to have created great variability as to when the consist is released from the portal, when the final car is added, when the physics take hold, when it is truly certain the consist will not come apart, when the portal-issued commands are assigned and executed, when the driver is assigned, and when the consist can be considered ordinary, having completed the spawning process, and is able to act like a full-fledged driven consist.

Likewise when an emitted train can sense or trip a trigger is also unpredictable from my experience. I would make your emitted train travel one baseboard worth to ensure complete berthing and worthiness.

Wait until you recall your portal from a stored session or game save. They don't remember what they were supposed to, and I dare say that some of the hard-fought portal fixes achieved in TRS19 SP4 have been undone in TRS22. Drivers are not reliably assigned, creating runaway uncontrollable destructive zombie trains that heed no control directives. I am preparing a bug report to this effect.

deneban said:

I have learned to give emitting portals a wide berth - like one baseboard's worth - especially since the developer made the irrational decision, in TRS19, to have portals, a theoretical construct we imagine, operate under a real world-emulating physics package. This attempted fusion of the the theoretical with hard equations seems to have created great variability as to when the consist is released from the portal, when the final car is added, when the physics take hold, when it is truly certain the consist will not come apart, when the portal-issued commands are assigned and executed, when the driver is assigned, and when the consist can be considered ordinary, having completed the spawning process, and is able to act like a full-fledged driven consist.

Likewise when an emitted train can sense or trip a trigger is also unpredictable from my experience. I would make your emitted train travel one baseboard worth to ensure complete berthing and worthiness.

Wait until you recall your portal from a stored session or game save. They don't remember what they were supposed to, and I dare say that some of the hard-fought portal fixes achieved in TRS19 SP4 have been undone in TRS22. Drivers are not reliably assigned, creating runaway uncontrollable destructive zombie trains that heed no control directives. I am preparing a bug report to this effect.

Click to expand...

Yup. I've also encountered those zombie trains running ruthlessly through a route, destroying a perfectly working session up until that point. It doesn't occur often for me to pinpoint down what's causing that which makes that so difficult to troubleshoot.

Like you, I give a portal an extra baseboard, or sometimes two to ensure the consists are fully emitted and issue a wait 20-seconds command in the command queue to ensure everything has settled down prior to issuing any other driver commands. This wait... 20-seconds really helps I noticed to mitigate the runaway issue, but that doesn't always work.

I have a problem using triggers to emit trains from portals. I set up a session using just 2 portals and 2 triggers. I used central portal control rule and emit train on trigger rule. All worked fine on first run and I saved the session. When I tried to run the session again neither trigger would cause it’s corresponding portal to emit a consist. Help please!!

Hi everyone,

the "wait for trigger" no longer works on TRS22.

However, G.M. has created a new rule that works very well.

Search the forum with the words "wait for trigger v2". You will find a link to download this command : "wait for trigger v2u".

Very interesting. Indeed the messages describe the issue I encountered which were quite odd. The analysis of the complexity seems on target as well with the various pitfalls. Each of the calculations sequences may work on paper but the conditions, while the software "crunches the numbers", may change. Sometimes this reveals a problem of an interrupt not being well handled. The baseboard trick makes sense and a "better" command may solve all.

Big Thanks for the contributions.
Dick

nunez said:

Hi everyone,

the "wait for trigger" no longer works on TRS22.

Click to expand...

Wonderful, TRS22 has broken portals and now at least one built-in script.

During the TRS19 critique threads I had implored N3V to adopt a structured written and approved test procedure with verification for new releases rather than the unstructured group testing employed. Still hoping some day this will happen.

Here is the result of the unstructured testing approach: We went through an extensive effort to fix portal behavior in TRS19, only to have all that effort undone in TRS22. In other words many wasted debugging hours

The more broad Trainz and its features get, the more the chance for breakage by revision, and the more need for structured testing.

boleyd said:

The baseboard trick makes sense and a "better" command may solve all.

Dick

Click to expand...

No, I said the opposite. When you reload your session or game, the portal will malfunction, baseboard buffer and revised script notwithstanding.

Sorry, misread.... If N3V would NOW do a structured test a proper portal might evolve. Enough problem scenarios have been reported to quickly feed a test scenario. Again - thanks.

nunez said:

Hi everyone,

the "wait for trigger" no longer works on TRS22.

However, G.M. has created a new rule that works very well.

Search the forum with the words "wait for trigger v2". You will find a link to download this command : "wait for trigger v2u".

Click to expand...

When I search the forum for that, I get 498 results. Want to help me narrow that down a bit?

Try searching for this: <kuid:99999:80001> Wait For Trigger v2 this is more than likely what you are looking for.

BN1970 said:

Try searching for this: <kuid:99999:80001> Wait For Trigger v2 this is more than likely what you are looking for.

Click to expand...

And this is what I get:

Found it. Weird that the Search of the forum for "Wait for trigger v2" does not show the actual thread with that title in the first 25 results. Probably because their search engine removes small words from the query. Actually, given this is Trainz we are talking about, it is not that wierd.

Also, the database error that was generated by the search went away after removing the '<' and '>' from the query. Redirect operators can be dangerous, but should not cause a properly coded search function to crash out.