Cyclone

This bug has existed since the playtest. See attached video. Pathing Bug.mp4 It should be noted this can also happen at Sosnowiec Glowny, Psary, and any other station that has this type of branch line, or any single-directional line. It does NOT happen on regular types of lines (i.e. Katowice to SG to Bedzin). The issue is the arrow turning red after the train is pathed and not being able to reset the arrow. I tried to report this during the playtest, but the unneeded Line 62 to SG platforms and the inability to send trains the wrong way gave me a perfect testing bed for this bug. This can also happen if SP cancels a path to Dandowka, or if a future player-controlled Dandowka cancels a path or misroutes a train to SP. Why is this an issue? SP in the past would be unable to send trains. Now, if I did this going to Dandowka, Dandowka would no longer be able to send trains and I'd be sub signaling trains onto the single line to keep SG clear. We need a way to automatically reset the arrow to a grey state even with a train on the path, one of those override situations.

I selected Dandowka. My reasoning is based on brief chatter yesterday. It was publicly stated that Katowice might be coming sooner than later (I won't go into detail as it's not confirmed final). I later asked about DGZ and it's also apparently not going to be ready for a while. Barring a temporary computer system there, we won't get that yet. Further, that station works fine most of the time. We don't need to put that in human hands yet. Dandowka is located 2.5 km down the line from SP. The station box between the SP one and Dandowka is the freight box for the SP yard; I presume this will open up when shunting and other activities become a thing. Dandowka can control traffic to Kazimierz and help manage the two tracks there until a human arrives there (assuming one is meant to arrive there). This means that the area between Dandowka and DGW has less chance to have issues if both dispatchers are communicating on the radio and keeping an eye on the map. It might be possible to hold out on those in-between stations, moving on to the Line 156 connector at Bukowno (a route that eventually connects to Myslowice via 156, 133, and 134, which ends at the station and becomes Line 138 to Katowice). Therefore, my proposal is Dandowka and Bukowna, provide AI-only trains that cross that Myslowice route to provide dispatching material,, and while testing takes place in this area bring in Katowice for use if possible. The only possible glitch is people can sub signal a train down that track, so a temporary controlled red by the AI dispatcher beyond that point can just block it so players can't ride in incomplete sections if one sneaks onto the track. Only the AI trains would be accepted, and the player train eventually deleted to clear the way. (BTW, I have sent a train to Myslowice, so I know it's possible.) Once we have a human at the terminus, it makes sense to start opening up the Warsaw area, but I would advise drop two boxes at the same time so there is some immediate communication and no lack of human contact outside of the occasional passing train. I feel opening up all available stations in the Line 1 area is then a possible option, then work on Line 8 and Line 64 with Starzyny becoming human as well. Fill in the gaps on Line 4 periodically, and then fill in any missing stations. So Dandowka and Bukowna are my next two picks, with or without AI traffic to Myslowice.

Not only do I think we need one, but I've already created one I'd be more than happy to help set up if the Simrail team would like.

Just to be clear, I'm not commenting from the point of complaining. My original post thought this was a bug, and I have been advised this is apparently how it works. I don't get why this is how it works and I still can't process why a dispatcher isn't able to get a confirmation that it's clear from another driver before setting a green signal in this fashion, but apparently this is how it works and how my brain processes it is irrelevant. Naturally, I am all for providing as much accuracy as possible. Pro servers? To be fair, we don't have a large number of servers in regular use right now, and having to provide one server for each language - or, in some cases, continent - means there will be a large number of servers with very few players or unused. I think it's more important ATM to make sure there is a good mix of players on as many servers as possible. For instance, Australia, the UK, and North America tend to all speak English, so I'm not sure we need three separate servers for each of them to split up from each other. I get from a play standpoint why this might happen, but at the same time recognize that there are not a lot of trains now. If we're going to have multiple servers, they should IMO all be different times and different types of service patterns. In fact, having a regular pattern with more passenger during the day and freight services in the eight hours from 11 p.m. to 7 a.m. (with some mixed passenger at the start and end of the window) would be a good way to provide variety in the service patterns, but I figure this might wait until more freight tasks like the coupling and uncoupling of cars and siding use are added.

This is a computer game. Someone could set STOP by accident. I know I do it periodically when I try to set a route and wind up with only one arrow clicked, wondering why the signal has turned purple later, and sometimes a route manages to not execute because the Execute button didn't click. Things like this can happen, so having a signal not clear in this fashion is more of an annoyance than an IRL representation. Laying actual IRL reasoning may not always be relevant.

Just as a matter of note, when I turned on STOP on the set path, the signal showed as a regular red. It did not turn purple. I can however turn tracks purple and have learned recently that, barring a sub signal, trains cannot really be set on purple tracks (which I thought were locked into position, not locked from use). It means people setting up to avoid a closed track cannot lock a single point around it because trains will not be able to pass. I still believe in this case, the dispatcher would be able to authorize the signal clearing to green by using a DSTOP, so I assume this is an IRL computer limitation being imposed. And if that's how it's actually done, then great. It will however likely be repeatedly reported, and the question is whether it makes sense to provide the game utility over realism that indeed can appear to be a bug, as I presumed it might be. DSTOP clearing a signal to green used to work, and now it doesn't, so I presume this was changed since the playtest intentionally.

No, I have confirmed that a substitute signal also works. Are you indicating however that it is correct behaviour that the DSTOP command is meant to continue to show a red signal after it is executed? I would imagine it used to clear a train across multiple points beyond after a passenger stop where it is manually set to aid in the stopping of the train for its scheduled stop, not as a manner of blocking a train from entering an obstructed area. As such, I would think the DSTOP should be able to clear to a green signal, so please let me know if this is a mistake and how it is normally used.

Notice above that 24901 is not lined up correctly as the top train on this panel. How this happened: I was scrolling on the panel, and as I did so a train vanished, which made the scroll bar vanish. However, the train list did not line up correctly with a panel not needing a scroll bar. This was due to me inadvertently holding the mouse on the scroll bar while the train cleared my range. It corrects itself, naturally, when other trains come and go, including in this case 24901. So this is more of a visual bug.

In the above image, I have highlighted signal H2 for this discussion. However, note that I have tested other paths and the same error happens elsewhere, such as signal N1, so I believe this is a widespread spider (bug). I will start with how to reproduce this bug: Set a train path crossing two separate sections with a signal in the middle. Click the signal after the path is set and use STOP to turn it red. After the signal changes, click DSTOP and watch the signal stay red. You can get around this by using a substitute signal on the red signal that is stuck from doing this. After the path clears, you can set the path normally again and the signal will change green with a new route. The same applies if you cancel the route behind the stuck signal and set it after it clears; the signal again turns green. This is a bug exclusively with the DSTOP command not turning a cleared signal green if a path is already set.

SP is all but confirmed due to pictures and other things this week, and I even took video inside the building today. I believe it can be removed from the poll. The fact it was reported as "99% done" somewhere tells me it's likely next.

Agreed. When typing a note in the computer focus changes to the main chat. Why?

I think folks in the game reported you because they were delayed. The reporting system seems flawed to what the driver is experiencing and they do not always check the situation.

1410 followed by 1408 after teamwork freeing 1408 from a stuck situation on launch day. Great fun.

DG has no options. SG and BedIn are supposed to lay them over. My check is if a player is driving, and I ask what the player wants to do. If asking early departure or going through, I analyze and will still sometimes have a passenger train and have to slow them down. If clear, through you go.

Someone walk over from SG and see if a building is accessible?