AI signalling bugs post 13/09/2024 server side update

[DazT]

Location: Olszamowice
Server: EN1
Time: 1640hrs 14/09/2024 (Server time)

Train 41126 ran via track 4 despite not immediately following anything and nothing behind

(Orange box around the train number on my mapping system indicates a 60kph route was given)

Edited September 14 by DazT

[DazT]

Location: Korytow
Server: EN1
Time 17:38hrs 14/09/2024 (Server time)

Train 13133 put on Track 2 at Korytow AI instead of 1 or 3 meaning the only option is to run it left track to Szeligi. Not really a show-stopper of a move, but it meant 4130 has to go round it on Track 1, and then meant 1335 got restrictive signals waiting for 4130 to clear from Track 1

Edited September 14 by DazT

[DazT]

Location: Olszamowice
Server: EN1
Time: 20:26hrs 14/09/2024 (Server time)

Train 146047 closely following behind 1339 routed Track 1 to Track 4 at Olszamowice for no reason at all. I thought it was going to get 1439 past, but it didn't even bother doing that. (Which in itself would be a completely pointless move as we're all capable of doing 160!)

Edited September 14 by DazT

[DazT]

Location: Wloszczowa Polnoc
Server: EN1
Time: 20:40hrs 14/09/2024 (Server time)

146047 again, side tracked at WP on Track 3 and then sent left-track to Knapowka on Track 2. Surely if it was going to send me left-track, from Track 1 surely would have been better, rather than from Track 3??

The left-tracking was a poor move as it then delayed/stopped northbound 3138 at Knapowka and crossed 146047 back from Track 2 to Track 1 again.

Edited September 14 by DazT

[DazT]

Location: Idzikowice
Server: EN1
Time/Date: 1729hrs 25/09/2024 (Server time)

Service 16133 routed Track 1 to Track 5 to Track 1 at Idz, nothing ahead, nothing behind it apart from 1633 some 20kms back.

Edited September 25 by DazT

[Angelo]

It looks like the AI received some fixes:

[DazT]

17 minutes ago, Angelo said:

It looks like the AI received some fixes:

This thread has been created at the request of Kojonek to capture instances where the AI messes up after said update

Edited September 25 by DazT

[DazT]

Location: Sosnowiec Główny
Server: EN1
Time/Date: 0554 01/10/2024 (Server time)

AI at SG held 40609 on Track 1 to run an early 244029 round it via Track 7.

The expected behaviour would be for the AI to let 40609 depart right time and hold 244029 outside or by running 244029 onto Track 5 or 7 but not committing the exit route for it -or- to run 244029 via Track 4 (which is what most human dispatchers do so it's not having to cross over all lines at the south of the station and then blocking the main line if SPl doesn't give the signal)

There was absolutely no benefit or anything to gain in the AI doing this move and letting it continue early as the 244xxx trains are booked to sit for well over 30 minutes at Sosnowiec Południowy anyway. All it did was delay 40609 for absolutely no reason at all.

Edited October 1 by DazT

[Angelo]

Btw 244xxx should always run on track 4, because more often than not SPł won't be able to clear the signal right away and the train, standing at the home signal, will block all of SG.

[jeroezie]

It would be best, if theire was a way to get Spl to clear its entry signal, what the dispatcher at SG could see and afther that he clears the SG exit signal. But somehow that is difficult to explain to a player, let alone to program a bot to do this reliably.

[DazT]

Admittedly it's easier to do if SPl and SG is player controlled, but you need two decent players on both worth their salt. (ie. Know what they're doing)

SG player

• Offering the 244xxx on early and not waiting until it's rolling into SG (By offering it early SPl can plan ahead for it, rather than being caught off-guard - if they're worth their salt, they'd of been looking at the EDR and SRTD (and even TPV) and would already be planning for it 20-30 minutes beforehand!)
• Use a route that doesn't clog up the whole of SG should SPl not immediately be able to give the slot. so via 4 being the least disruptive. (As there is no booked traffic the other way on that Line 62 chord, there isn't a reason why they can't give the slot/line lock straight away when asked, however, I've had players in the past refuse to give the line lock because they've got "other traffic", what other traffic?! Give the slot doesn't stop them running to and from Line 660!)
• Sending 'Train departed' before the 244xxx gets around 500 metres from its last proceed signal (So the driver isn't on the brake as if it's gone Track 5/7 or 4 it'll be doing 40 anyway)

SPl player

• Giving the slot (line lock) early
• Dropping the barriers and giving the signal as soon as SG sends 'Train departed' and not waiting until the first track circuit shows occupied, if they're waiting for that it's already too late, the train has already passed SG's last signal on a restrictive aspect and approaching SPl's first signal at red.
• Recessing the 244xxx on Track 4 at Spl and not being clever and just launching it towards Dandowka unless there is an obvious workable gap to actually run it

How you'd ever get AI to simulate all that is beyond me, but there should be a better way than SPl waiting until the very last minute before clearing SPl1_W signal!

Then of course, there's the 244xxx itself, if player controlled you actually need a driver that knows how to drive and one that won't dawdle! (Know you routes, know your train!)

Edited October 2 by DazT

[DazT]

Location: Idzikowice
Server: EN1
Time/Date: 0434hrs 02/10/2024 (Server time)

AI at Idz routed train 61102 (1) via Track 4 non-stop despite the only train following being early 6102 (2) which is booked to follow 61102 all the way to Strzałki anyway.



04:40, Noticed that the AI then sent 61102 from Track 4 to Track 1 (left track to Strzałki), so surely if it knew it was going to do this Track 2 to Track 1 south of Idz or Track 2 to Track 1 north of Idz would have been a better move, via Track 4 is just ludicrous!  (Personally I'd of just train it Track 2 all the way, but that's just me!)

Edited October 2 by DazT

[DazT]

Location: Psary
Server: EN1
Time/Date: 1635hrs 04/10/2024

4130 waiting for 42128 to clear (on 3), but then rather than waiting and running 4130 via Track 2 the AI decides to run it via Track 6. 

And then because the AI had made 4130 late (despite only being 1 late approaching Psary), it then decided to run early 3130 making 4130 even later.

Edited October 4 by DazT

[DazT]

Location: SG R52
Server: EN1
Time/Date: 0551hrs 05/10/2024

SG AI holding 42930 despite being booked over the single line first towards SPl

In turn it also held 40609 (assumed for 24109, but see 0601hrs edit)

Both 42930 and 40609 are both booked before 24109 at SG R52

With regards to Line 660, if both trains are on-time (which I was at the time!), then the AI should be running the trains in booked timetable order over the single line. The AI had nothing to gain holding 42930 as 24109 is booked a ph at SPl anyway! More than enough time for 42940 to travel over the single line and arrive at SPl

0601 hrs edit: The AI after holding 40609 for 10+ minutes then decided to run it - ahead of 24109! So 40909 encountered delay for absolutely no reason at all, which in turn now delays 24109 and delaying (me!) even further on 42930. I went from being on-time to being 14 late over R52 Jcn.

Edited October 5 by DazT

[DazT]

Location: Łazy Łc
Server: EN1
Time/Date: 1720hrs 14/10/2024

Łazy Łc AI decided to run 40633 via Track 3 (Line 160) due to closely following 146039, meaning that 40366 could not complete its booked ph calls at the intermediate stations.

The AI should have either asked for the train to run on Track 2 or Track 4, or simply waited for Track 1 to become available.

Edited October 14 by DazT

[DazT]

Location: Będzin
Server: EN1
Time/Date: 16:45hrs 26/10/2024

Będzin AI held 40631 for 14127 despite 40631 being right time and 14127 also being right time with 14127 booked to follow 40631 all the way to Katowice.

NB. This pretty much happens every single hour that these two trains run 406xx (odd number) and 141xx (odd number).  Either 406xx needs to run earlier, or 14127 needs to leave DG as few minutes later -or- the AI at Będzin just needs to be told to stop being silly!

[DazT]

Location: Będzin
Server: EN1
Time/Date: 13:38 hrs 27/10/2024 (Server time) - 12:38hrs UTC 27/10/2024 (Real time)

Będzin AI ran 1423 Track 1 to Track 4 back to Track 1 for absolutely no reason at all, following nothing ahead, and nothing was behind apart from 40625 back at DG.

1423 was further delayed whilst the AI was running 649068 from Track 2 to Track 6

Edited October 27 by DazT
Date correction

[DazT]

Location: Łazy
Server: EN1
Time/Date: 23:49hrs 02/11/2024

Łazy Łb AI held on time 40694 for 42144 for no reason, this also delayed southbound 40147, which in turn also delayed 441067 and also 73139 that was stuck behind 40147. 4 trains in total delayed.

42144 is booked behind 40694 to Zawiercie so there was no reason/need for the AI to hold 40694.

Edited November 2 by DazT

[jeroezie]

I spotted the Lazy LB Ai making dump decisions today, when handling 406xx when it arrived before an 14xx train.

First train 1417 was routed via Lazy LB track 3 and then track 3 from LB to Lazy LC in order to 'overtake' train 40619, which was held at Lazy LB track 1. Later a similar thing happened to train 40621 and 1419. 40621 was held at Lazy LB track 1, 1419 was send via Lazy Lb track 3, then track 3 from LB to Lazy LC, where it continued via the slow cargo trains track number 3 to DGZ (instead of main line track 1).

19-11-2024, 1417 around 10:15 and 1419 around 11:16 in game time.

[DazT]

Location: Between Sosnowiec Południowy and pzs R52 (Line 660)
Server: EN1
Time/Date: 10:51hrs 01/12/2024

This appears to happen every hour when both SPł and SG are AI. Because the 241xx service usually passes early through Dandowka (because when the line speed on Line 171 was raised between Dorota and Juliusz from 30 to 100 kph the timings were never altered)

Because 241xx is running early, SPł then goes on to request the WBL for Track 2 (Line 660) to SG far too early. This then causes 429xx to sit on the main line at R52 Jcn awaiting a path over Line 660, even though 241xx isn't booked to depart SPl until XX:01 and 429xx is actually booked over Line 660 first, booked to arrive at SPł at XX:55.

With 429xx sat on the main line, this then delays 406xx (even numbered) behind it which if AI driven will then do 20kph to sit behind 429xx, making this train also late. This then causes the 406xx to lose it's path in the Bedzin area because it's late and the AI there will more often than not hold the 406xx thinking it's late (even though the 406xx could actually be right time by DG!) for 411xx.

All from one mistake by the SPł/SG AI's

11:21 edit - And Bedzin has gone on to do exactly what I wrote above,  holding (now) late 40670 for 41118.

Edited December 1 by DazT

[Atheramaja]

finally master dazt up this case. this case side effect september update. every frkin' hour when SG/SPL AI this scenario happen. Before september update this scenario never happen (unless anomaly happen). kinda insane they said september update fix AI behaviors but here we are on thread about new case AI behaviors post-september update. 💀

Sometime even worse if TLK 24xxx kielce via LK62 already got delayed cuz AI kozlow priority Intercity 13xxx. That domino effect make AI SG/SPL hold REG 429xx at red signal until TLK 24xxx Via LK64 & TLK 24xxx via CMK got first priority leave SPL instead REG 429xx. 💀

Edited December 2 by Atheramaja

[DazT]

Think the only way of solving the SPl/SG thing is for the AI to actually hold off until the last second AND also follow what the timetable says. So even though 429xx has a lower priority if you believe this priority train nonsense, is for the AI to ignore that and actually just run them over the single line (if both ontime) in timetable order!

I've seen it a few times where a high priority train has only gained it priority by running early so then goes on to cause carnage elsewhere EVEN THOUGH it's not actually the next booked train over a particular line if reading the timetable to the letter!

 

Edited December 2 by DazT

[DazT]

Location: Psary (Line 570)
Server: EN1
Time/Date: 13:15hrs 10/12/2024

So there was a little traffic jam caused by a player on Psary who then left and dropped back to AI control.

But the AI needs tweaking so that no trains are let loose from Psary towards Starzyny if there is no where for a train to go.

So in the example below, 13121 should have been held back at Psary because it had nowhere to go because 1323 is in the section ahead. This needlessly then delayed 3122 even more (caused by said player) and also delaying 31122 behind that at Sprowa.

Edited December 10 by DazT