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?

I have changed my vote to Dandowka. This is far away from many player points and is important for routing to two single track areas. That said, DGZ is a sensible addition. DGZ is a connection to DGW, so that is a thing. Having a human on SP also gives ideas for handling the AI scripting.

I can take on the task of creating a skeleton server and would be happy to ensure devs get the ability to speak everywhere needed while ensuring Discord norms are followed.

I have learned something today. 😄 I always thought the entire number was the determining factor. So this was new information, and I appreciate the better understanding. Though where a single track can become permanently blocked, I think priority should basically be thrown out the window in favour of "keep services moving". 🤣

The single line is operated exactly the same as an alternate line is operated by AIs in the north. I walked into Pilichowice to find two tracks entering from another station. The AI at the prior station had asked, and the other AI accepted, an absolutely unnecessary direction change. Since the SP platforms are NOT within the single line, the AI does not have the capacity to understand that the single line is not able to be freely swapped like this. If a human SP dispatcher knows there is a train in 1, the player can say hey, I'm not accepting your next train and I'm in fact keeping the junction against you until this train clears. The AI, based on experience in Line 4, will just freely accept it and send the second train in. My concern is that the line may not be operating in the way 660 does. Is it permanently set like Track 1 and 2 in the north? Or does the arrow flash and go off after each train clears, and one cannot send the next train until that clearance is achieved? If the latter, it should be possible for even an AI to say hey, there's a train at Platform 1, I'm leaving you in the single line until I can clear this train, and once it's clear, you come in and therefore Dandowka cannot send me the next train until I'm good and ready. There is then the logic question of the "more important service". It will be more inclined to accept any train numbered 241xx or 246xx over sending a train to Dandowka because the lower number increases priority. With every train a 42xxx from Katowice to Line 62, it literally means every single train from Dandowka is more important. This is a complication. Because then you have a train waiting in 2 for "more important traffic", another train blocking Track 2 on Line 1, and very unhappy passengers.

Setting the junction in the computer is technically asking permission. The AI accepts it. So if an AI asks, and an AI accepts...

Finally out of approval purgatory. And now I'm learning that apparently the problem has been the AI assuming there are no station tracks on each station after Kazimierz did the exact same thing from DGW. Funny that players were blamed initially. Going to put out another suggestion within a suggestion. Stop blaming us for broken things. In fact, given this is early access, we SHOULD be trying to break things so the final build can be as good as it can be. The fact that we're finding these things is a huge benefit for the final build. Don't blame players for problems in how the AI operates, and be appreciative when we locate these errors so they can be corrected. In fact, don't blame players at all in public comments until it's fully investigated. Players tend to know what they're talking about; they're the ones playing it. It seems this will be fixed and we can finally move forward, but I will still say that finishing the loop around to DGZ at the end of a month is probably a good way to go as DGZ itself doesn't have any AI problems, with only the occasional train not moving at a green causing issues resolved by a player hopping in and moving it. Additionally, finishing this loop now also gives a chance to test traffic from Mystowice in the event we loop around via Line 156 to get back to Line 62; we just need two more interlockings on the way to unlocking Mystowice according to the map, and one new station in Jaworzno Sczcakowa, and maybe more junction interlockings along the path that can stay AI for now..

Ah, so it was added post-playtest. It's just kind of odd that the default button is the same one used for typing in other text boxes. Forget the jumping, just having other typing interrupted means that Space is not the best option for a keybind for that one. 😀 The problem becomes that, for this reason, NO key is safe for this. Put Z as a default, and you can have a private phone chat "It's boring in here right now, someone order me a piz" and then "za." goes into the public chat. So having a button for chat is really a useless thing in dispatcher mode. It should ONLY be a thing when driving a train, I would argue. Not as a dispatcher. I say disable it in dispatcher mode.

The funny thing is this didn't happen during the playtest. Once. It only started happening in the Early Access. So something changed.

I can see a good excuse for linking to a full train's info in the computer. You're servicing train 15555, let's bring up the info for it and have a nice conversation. I greeted a player train this morning by saying, "I hope you and your passengers are having a pleasant ride from Warsaw".

Too soon for Sosnowiec Kazimierz and Stawiska. My view is that Sosnowiec Dańdówka and Sosnowiec Południowy are together more important than Dąbrowa Górnicza Ząbkowice at this moment. Adding people trying to learn the new box is going to cause more problems than adding the Line 62 boxes will solve. We do need DGZ eventually, but let's solve the problems occurring on 62. At least the AI will now use a siding at SP to help prevent things from blocking up!