moblet1

I just discovered that the same issue occurs at Zawierce towards Myszków & GW.

Since the last update there is a problem with the block occupancy lights at OP towards Pilichowice. The configuration there is unique in that there are two blocks per tile. These lights previously worked correctly, but since the update only the left side light in each tile illuminates. The right side lights do not illuminate, so trains keep disappearing and reappearing as they traverse the section. This occurs in both directions.

One reason why Sosnowiec Południowy gets jammed, and then jams the mainline, is because the AI will route cargo train 2440xx onto one of the station platform tracks instead of track 4. 2440xx has a 30 minute pt stop at SP, and often runs early, so it is normally held at SP for some time, where its occupancy of a platform makes it impossible for stopping trains to meet at SP. Under the current timetable a meet of stopping trains is scheduled once per hour, during the scheduled pt stop of 2440xx, so if 2440xx is routed to a platform then it is almost certain to cause trouble.

DGHK will sometimes send a train to DGZ on the left track (track 1). When a train is arriving on track 1 it is impossible to set the entrance signal Y to green. I have to use Sz, and then I cannot confirm train arrival and DGHK AI will not release the lock on track 1, so I cannot send any trains on track 1 for the rest of the session. When sending trains to DGHK on track 2, I cannot set exit signals U101, U102, U103 or U105 to green, I can only use Sz.

I just had the same problem at DGZ. Lazy Lc AI requested to send a train on track 4 but I was unable to release the line lock. (The train was sent on track 1 instead.)

At Lazy La, AI from neighbouring boxes sometimes asks to send trains on the left mainline track, or asks to send trains on their usual track if the mainline track direction has been reversed. I have not been able to release the line locks on tracks 1 & 2, there is no response from the "release line lock" button.

Have encountered this issue in the past and it happened again yesterday. It applies to both passing tracks. When a train that has been stopped departs from a passing track, I cannot update the EDR because the train is "too far away", even when the rear of the train has not passed the signal box.

I've reversed a cargo train from Koziol to DGW, entered DGW, been switched to the correct track, and then driven out again towards Koziol, using a Sz to enter DGW set by a human dispatcher at DGW. (This was done because a previous dispatcher had sent the train to Koziol on the left track, creating a conflict at Koziol that the AI couldn't resolve.)

Just had an occasion where Lazy La had reserved the incoming cargo track 168 for a train, but the train was later cancelled (player driving the train derailed due to speeding). The line lock remained in place. Later, Lazy La requested to send the next train, which I accepted, but the AI acted as if it did not have permission to send the train and held it at the Lazy La yards. I couldn't find a way to cancel the line lock so logged out of the station. The AI resolved the issue and the stopped train was able to proceed.

Screenshot attached

Occurred just prior to time of writing. AI sent 41122 from Z to GW on track 1, even though track 1 was set in the opposite direction. Train travelled at 20km/h. I joined GW, there was another human player at Z. We set track 2 in the GW -> Z direction to send a fast train but were then unable to change it again. Screenshot of my available options when trying to release the interlock. After the server restart track settings returned to normal.

UPDATE: Deadlock was resolved by the following procedure... - Messaging Starzyny, cancelling 412014 - Refusing Starzyny's request to send 412014 (reason: no unoccupied tracks) - Requesting to send a train to Starzyny, which was accepted

Occurring at time of writing. Starzyny will accept nothing other than track possession to send 412014 to Psary, but is not sending the train.

Have seen this too, and also between Sprowa and Starzyny.

A repeat of this situation occurred between Gora Wlodowska and Zawierce immediately after the server restart 14 hours ago. The AI sent a cargo train from GW to Z on the left track at the restart. By coincidence I was soon driving it. A human dispatcher was at Z. I anticipated that the line lock might not be released and, once I was off the mainline, waited at Z for the dispatcher to confirm the release. The AI would not let the human dispatcher restore the normal line direction so I went to GW to override it. I waited for a train to occupy the line and then left GW, which was stable thereafter.

Occurring at time of writing. I noticed that Szeligi was jammed with trains heading for Warsaw. Entered the station and both lines from Korytow were set as incoming. Korytow refused to accept requests for trains or to change the interlock. I was unable to resolve this alone by moving between the stations. A driver who was stuck left their train and entered Korytow station and we were able to return track 2 to normal. As soon as Korytow was returned to AI, the track 2 interlock was released and Korytow requested a track direction change. Korytow made no request to send a train. I then tried releasing the interlock and requesting a direction change on track 1, then moving to Korytow. When I got to Korytow there was no direction assigned to track 1 and Szeligi AI asked to send a train, which I accepted. The direction on track 2 then automatically corrected itself and the train was sent on track 2. I was able to restore the correct direction of track 1. AI operation then remained normal and stable. I cannot rule out that a human player did something to destabilise the AI in the first instance. A dispatcher that I have previously seen performing unnecessary irregular operations, and who I've previously suspected of switching track directions with the AI and confusing it, was online in EN1, and occupying a station in the upper part of the map, when I first noticed the problem.

Trying to divide accountability in the case of one particular type of dispatcher error is premature, unless a case is being made that dispatchers have no responsibilities and should have zero accountability. The question being asked here is whether and how to hold dispatchers accountable for their errors, and the division of accountability for failing to send a stopping train to a platform only becomes relevant to SimRail if and when a decision is made to introduce an accountability system for dispatchers. The way I look at dispatching is that it's a responsibility towards the performance of a system. If a driver has to stop their train because I've made a mistake, I haven't only disrupted that driver, I've disrupted a system. The driver might still make their required stop but my error has delayed them, and this could have consequences for the system and the people in it that I can't see from my little room overlooking my little patch of track. I'm not arguing that we all need to be perfect. It's just a game, most of us are amateurs, and we all make mistakes, but IMO allowing chronically incompetent or disruptive dispatching will kill the public multiplayer experience. Time will tell whether this becomes a major issue.

Occurring at time of writing. Server EN1. Trains are not clearing from the Czarnca branch line and are stacking up. AI is unable to route trains to the branch line and the mainline gets blocked. Humans can issue a substitute signal but eventually the line will be full. A player is at Psary seeking to derail incoming trains destined for Czarnca.

As a driver approaching a station, would you know that you've been switched to a track without a platform, and with enough time to stop and inform the dispatcher? It's absolutely the dispatcher's responsibility to ensure that a train with a scheduled passenger stop is routed via a platform. As for evaluation, as drivers we cannot fully see the big picture and have to trust the decisions of dispatchers, but there are times when it's very obvious that the dispatcher is incompetent or messing with us, such as the OP's example. We can see our own train's timetable for the next few stations so we know when a dispatcher is deviating from it, and we can see other traffic via the tracking pages on 3rd-party websites, so it's not difficult to know when a dispatcher has, for example, stopped us in a passing track for no reason and made us and following traffic late.

I can see that in the long term we are going to need some kind of reputation system. Apart from the issue of players attempting to dispatch above their competence level, hours of experience dispatching is not a measure of suitability for cooperative play. We currently have a dispatcher who plays very frequently and must have many hours of experience who will divert and stop a player train in a passing track to make them and following player trains late, for no apparent reason other than his own entertainment.

When the AI gets jammed human players jump in and out of stations and trains trying to untangle it. But if we cannot access the station that for whatever reason is refusing to release trains then we (1) cannot solve the problem quickly and efficiently, and (2) may spend a lot of time and effort and still not be able to solve it. I'm new to the game but in my short time here Sosnowiec Dańdówka hasn't been seriously problematic until this latest timetable. But, once caused, the jam wasn't fixable from Juliusz or any other accessible station.

From an in-game troubleshooting perspective Sosnowiec Dańdówka should be a priority. Right now EN1 is clogged at Sosnowiec Dańdówka and there is nothing we can do about it.