AI Inconsistency

I have always been a staunch defender of the AI and its capabilities, but I gotta say I'm losing the faith...

I have a very common situation on a route where a branch joins a double main line - three tracks into two. The interlocking comprises a crossover and a junction off one running line. Three junctions, three levers. The approach tracks are currently signalled with 08s on the main and an 06 on the branch, though I have tried other combinations.

I have tried about six different track combinations and goodness knows how many signal variations and what is intensely frustrating is that none of the arrangements work every time. And by that I don't mean at different times and conditions, I mean the thing works differently in IDENTICAL conditions. It's a computer - that shouldn't be possible.

I have created a test session with one train approaching the interlocking from the branch and another train arriving at the interlocking on the main headed for the branch. Reloading the exact same unaltered session yields three different outcomes. About 3 out of 5 it works as expected: the train on the main stops, the branch train crosses in front of it, clears the last lever and then the first train heads down the branch.

One out of 5 though the main line train thunders towards the interlocking at full speed and fails to throw the first lever till the very last second, changing a highball green to a red and the result is SPAD. Game over. The three out of five times it works the lever is thrown from 1/2 a mile away and the train eases to a stand as it should.

The other one out of five the branch train fails to throw the third lever required to cross in front of the stationary train. Both trains just sit there facing red signals, but the thing is that they intermittently throw the closest lever, which provokes a short split-second green, and they sneak forward an inch every time. If you wait long enough they both eventually sneak past the red sigs under those quick greens, so no SPAD and they creep up nose to nose in a cornfield meet 1/2 way between the red sigs. Game Over again.

There are two frustrations: Firstly, how in the heck do you trouble-shoot variable outcomes arriving from identical input? It ain't supposed to work that way! Secondly I set some new variation up, it works six times in a row, I think "Eureka - Fixed", send it to testers and receive a 'Not Fixed' reply. I run it again on my machine and it bombs three in a row. Again - how the heck do you trouble-shoot that?

Ok, it's NOT just me.... Thank god. (TS12 FWIW)

Andy --

I've had similar issues with AI.

I've found that leaving switches and signals alone and playing around with the location of track markers solves the problem.

Phil

LOL @ frogpipe!

Hi Phil - I know what you mean - nav via TM causes SPADs if the TM is close to a signal - the AI doesn't even 'see' the sig till it passes the TM. In this instance though there are NO track marks, no direction markers, no nothing! Just levers and signals! The train headed for the branch has Nav To Unloader, the one coming off the branch has Nav To Portal. That's it. The loaded train arrives first taking the shorter of the two possible approach tracks, the empty train has a perfectly clear and valid route around the stationary train and off to the Portal. It should work ten out of ten, not three outa five!

Oh - and FWIW TS10 44088

Dermmy said:

- how the heck do you trouble-shoot that?

Click to expand...

You don't, you become a content creator and forget about actually running Trainz ever again! Become one of us, one of us, one of uuuuuus....

Andy --

Another thought:

"One out of 5 though the main line train thunders towards the interlocking at full speed and fails to throw the first lever till the very last second, changing a highball green to a red and the result is SPAD. Game over. The three out of five times it works the lever is thrown from 1/2 a mile away and the train eases to a stand as it should."

If you are not using track markers with Drive To commands (where the AI will pause before registering the next command), place a speed restriction before the interlocking to bring the train down to a speed where it can stop before a SPAD.

I think I may have thought of something... Are both trains starting when the route loads?

My thinking is that each train is a new AI "thread" and the inconsistency may be that it starts these threads on a "first come first serve" basis. If so, the "simultaneous" starting may be the culprit. Doubtlessly, they don't start at the *exact* same time, but rather a few milliseconds apart, and the outcome is due to which one start first.

I'd try placing a "wait" command at the beginning of one of the trains list of commands, to force one to (hopefully) be truly first. Of course there's no guarantee, the wait may count, and you may still have "coin-toss" as to which train is Thread #1 and which is Thread #2.

philskene said:

Andy --

Another thought:

"One out of 5 though the main line train thunders towards the interlocking at full speed and fails to throw the first lever till the very last second, changing a highball green to a red and the result is SPAD. Game over. The three out of five times it works the lever is thrown from 1/2 a mile away and the train eases to a stand as it should."

If you are not using track markers with Drive To commands (where the AI will pause before registering the next command), place a speed restriction before the interlocking to bring the train down to a speed where it can stop before a SPAD.

Click to expand...

20 mph zone already, and the signal goes red literally as the loco passes it....

frogpipe said:

I think I may have thought of something... Are both trains starting when the route loads?

My thinking is that each train is a new AI "thread" and the inconsistency may be that it starts these threads on a "first come first serve" basis. If so, the "simultaneous" starting may be the culprit. Doubtlessly, they don't start at the *exact* same time, but rather a few milliseconds apart, and the outcome is due to which one start first.

I'd try placing a "wait" command at the beginning of one of the trains list of commands, to force one to (hopefully) be truly first. Of course there's no guarantee, the wait may count, and you may still have "coin-toss" as to which train is Thread #1 and which is Thread #2.

Click to expand...

I always have a 'wait' as the first command, and I always have the 'waits' a different length to spread that initial 'crunch'....

Hello

Dermy said:''The other one out of five the branch train fails to throw the third lever required to cross in front of the stationary train. Both trains just sit there facing red signals''

From my experience, in this situation put in additional signal (invisible) after the junction. In this way you make free drive for one of the both trains. Or put the additional signal after the signal you already have on one track before junction. Or use 'Wait for Xmin' for one train, so it will come later to the junction. Try it maybe this will help.

Andy -

Would you like to knock up a quick route with the junction layout you are using? No scenery, no textures - just the barebones track, portals and signals.

Mount it somewhere so we can download it and fiddle with it.

Phil

Not a bad idea Phil.

I have sort of resolved the issue though...

The two track approach was conceived as a main line and a passing siding. The approach is curved with the main line being the shorter route, so I had the track laid as a shiny main and a rusty siding. If there was only one AI train it automatically took the shorter route, modelled as the main. If a second train co-incided, it automatically took the siding resulting in a neat bit of proto-inspired AI running. No way though would the AI respect the crossovers and wye junction 1/2 way along the loop.

Last evening I made a very simple change. I added two direction markers, one at each end of the passing loop to enforce right-hand running. Suddenly the crossovers and the wye work. Every time. Always. Take the direction markers away and the train still approaches on the same track but the cross-overs/wye often-as-not don't work. Put the direction markers back and it works again. Nothing else is changed. Same signals, same levers, same trains, same driver commands, same everything.

If somebody can explain why the AI performs radically differently with the addition or removal of direction markers which result in the train using the same track anyway I will be eternally in their debt!

A test track in the form of a fully featured route will be along fairly shortly......

Interesting that the AI system seems then to anticipate "what would happen if?", albeit not very well, and then becomes indecisive as a result. I'm glad you solved the issue, but your question over all is still begging to be answered.

"If somebody can explain why the AI performs radically differently with the addition or removal of direction markers"

With them you take away the option of using the main for the consist from the unloader, without he'a got 3 tracks to choose from and the shortest as we know is the one he want's to use.
Try teasing the portal consist with a via trackmark or 2 after the interchange to pull it over to the track it would "normally" take.
Something else I've been running into lately, locos it seems with new sfx/fx scripts ( it's 1 of those) have trouble going via 1 trackmark on a route I use, the old "nothing fancy" locos blast through at line speed. It could be that it's near 3 junctions causing confusion.
Try other locos and see.