On the topic of AI performance...

[Wikkus]

...I have a bit of a problem.

I've noted that a number of our esteemed associates use portals as a destination for AI and that this is generally acknowledged to be "A Good Thing™" as once the AI unit despawns, it's no longer a load on the system. Great. No issues there at all.

No, the thing is that the AI defaults to 75% performance for any given line-speed which is no good if you want, for example, an HST or Pendolino to go batting past your 95mph DMU service at 125mph because the HST will only ever get to 93-and-a-bit mph.

So, a workaround I commonly see is to use a "stop at destinations" instruction at the portal and to set the performance percentage at said instruction to 97% for example and the corresponding speed to 125mph. In theory, this avoids the above-mentioned problem and should see the same train doing 120+mph as the AI has a "target" speed for its transition into the portal which ought to be achievable in most circumstances given a realistic distance (and bear in mind that AI accelerates like a rocket anyway...) to get up to speed.

However, this seems not to work in 95% of cases on my machine and instead causes a "can't find destination" error which, in turn causes a hod-load of other problems for other AI services, usually related to the failure of the first service causing subsequent services to be incapable of pathing.

A case in point is (and apologies for singling you out, Rich) many of the AP scenarios for NYM (or the original NY route) especially where using the "Doncaster" portal to dispose of AI going South via York; in pretty much every case, the scenario won't work for me unless I remove any "stop at destinations" instructions for the Doncaster portal; as soon as I remove them, it tends to clear the blockage, but then of course the AI can be slow to clear.

Doncaster is just one example and generally speaking removing said instructions are not an issue as the line speed is pretty low there anyway, however, doing the same thing on Ox-Pad where it's common to want to use the Westerly "Swindon" portal to have high speed trains rocket through Didcot, it slows them down considerably.

Anyone else get this? Anyone else find a workaround?

Cheers, Rik.

[malkymackay]

Rik, from the scenarios I've been working on, it would seem that something has changed in the dispatcher at some point. I had an Up AI freight service that was routed to dissapear at the Ferryhill portal on the default N-Y. It was working fine until I went to amend the player service recently. It wouldn't even start to move & just sat at it's starting position at Durham. No failed path in the Timetable view, so I was a bit stumped, as it was just a simple run straight to the portal with no intermediate instructions & with the default 75% performance. Got it to behave by stopping it before the portal at Ferryhill sidings. Strangely I have a HST that is due to run into that portal & it works with a 'go via' instruction & 99% performance

[Kromaatikse]

AI trains don't need a "Final Destination" instruction. Just use the Stop At on the portal (no need to set the target speed either) and all should be well.

[pendolinobasher]

AI trains don't need a "Final Destination" instruction. Just use the Stop At on the portal (no need to set the target speed either) and all should be well.

Oh i never knew that i have been putting final destination on all my AI all though the name tags on my AI on my latest WIP are poor to say the least so it sounds like another minor alteration is required Im enjoying all this extra work its keeping these little hands busy

[220389]

AI trains don't need a "Final Destination" instruction. Just use the Stop At on the portal (no need to set the target speed either) and all should be well.

I never knew that, but thank you for informing

Chris

[malkymackay]

Well there you go, another bit of knowledge. I had always given AI heading for portals a Final Destination, as that's how the RW manual does it.

[phat2003uk]

I've always been advised that it's important to have a final destination and certainly from what I remember in the early days of scenario creation, putting a final destination on a train that didn't have one usually cured an error or crawling AI train.

[malkymackay]

Richard, I just gave it a test on a clone of Newcastle-York with portals for the Up Doncaster, Leeds & Normanton lines at Chaloners Whin. It worked fine. I paid attention to what the signals preceding the portals did when the AI vanished & they returned to green, as though nothing had ever passed. Will look into this further later on.

[Wikkus]

Many thanks for the input guys; really glad it provoked some thought and I too learned a little something.

I've spent the afternoon playing around with some old scenarios that I started to work on but abandoned because I could not get the AI to behave properly and so far, so good. Many thanks Kromaatikse for the tip.

Still got a persistent problem with AI doors remaining open on some services (default Mk2s only it seems...) but I can work around that.

Cheers, Rik.

[Kromaatikse]

At some point it has got changed - now giving an AI train both a Stop At and a Final Destination to the same place (especially a portal) is just inviting trouble. This actually came to my attention when a lot of default and AP scenarios alike stopped working suddenly.

The reason is that the Dispatcher forgets that the portal can fully absorb the train, and just thinks that it will Stop At a very short track marker. Then it tries to route from just beyond that point to the Final Destination - which, on typically unidirectional track just beside buffers, *will* fail.

The technique still works for track markers long enough to contain the entire train, because then the Dispatcher can cope with the train remaining still. It also sometimes sort-of works at portals when the Dispatcher can find some way of satisfying it's rather strange routing criteria - which sometimes involves shunting the train back and forth on another line, possibly interfering with other trains.

So the new status quo is: the player *must* have a Final Destination, which should be immediately preceded by another instruction in the same location (so the player can come to a graceful stop). AI trains should *not* be given a Final Destination, and certainly not one in the same location as the immediately preceding instruction.

[Kariban]

Hm, that might solve a few of my issues. I've been using pre-portal markers and actually stopping at them, which is ok for the things I've been setting up.

Also thanks to the small scale of monitors, I tend to use more like 120% for HSTs... same as scale modelling, the smaller the model the slower realistic speed seems.