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.

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

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!

When the EN76 runs as a double set, only one set is shown on the TMS screen Server: N/A Build: EAB 21/04/2024 14:12

Certainly looks the same scenario, I originally spotted it on Bedzin back in February, but it's only took another 8 months for me to get around to faulting the others (one being Grodzisk) after working out what the common factor is between them all.

I've already reported a similar fault already But I think I've found the pattern as this also happens at Grodzisk. If a player disconnects from either Grodzisk or Bedzin and a route is already set for a train towards a controlled signal (red/white post) controlling the entrance to an ABS section where the signal is ahead of the point work, if that player disconnects the signals protecting the ABS section will return to red for no reason at all for about 30 seconds to a minute and will then reclear. From what I can see this affects the following signals Bedzin B_C B_D Grodzisk Gr_P1 Gr_P2 Gr_P3 Gr_P4 I suspect this will also affect Signal KZ_J2 at Zawodzie, as this is also a controlled signal reading into an ABS section, although I've not tried it, but it fits the pattern/scenario of the other four mentioned above.

Hacking the AI signalling to your advantage. Example at Tunel for 429xx stopping trains routed erroneously set by AI signalling towards the siding If the AI at Tunel when coming off line 62 shows you the siding rather than the platform because the AI has got a little ahead of itself with route setting, you can stop just beyond the signal protecting the junction (you have to take the signal given and stop about an engine/coach length past the signal.) You'll know it's a wrong route as you'll get yellow over yellow (40) which is for the siding, rather than yellow over yellow, over yellow strip (60) which is for the platform, so you need to pay attention! Check external map to see if the train in front has gone from the platform line (which is normally the reason why it put you towards the siding because the platform line was occupied, even though you're booked to stop!) Set the train back behind the signal, it will have now returned to danger (red), wait until the AI resets the route and you'll be given the platform route (if it's free/unoccupied of course) This works other locations I've tried where I didn't agree with the route the AI gave (40 routes, Sz routes, silly routes where the route given at the time isn't the "normal" route for the location concerned, usually because you've caught up with something in front or the AI is just being silly. My advice though is to use this hack sparingly, and ideally you need to keep a portion of the train approach side of the signal so nothing can come up behind you at line speed and potentially crash into you if you clear the whole signal section!

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.

When travelling between Sędziszów and Kozłów there is out of use post Gniewiecin (254.285). I am aware since the last build that this location is out of use, but the timetable display still shows it as a location, the result is the timetable pop-up in the cab never updates when you pass it, and when you (in this example) reach Sędziszów it shows a break in the display. (It however shows no break and Gniewiecin before) Looking at the end of scenario summary Gniewiecin is missing Either the train pop-up timetable should report passing Gniewiecin, even though it's out of use (as before, before the last update), or it needs removing from the pop-up timetable altogether. I've only tested/seen this in the Kozłów towards Sędziszów direction, it might do it the when travelling the other way, but I've not checked it at the time of writing. Server: N/A Build: EAB 21/04/2024 14:12

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.

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.

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!)

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!)

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.

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