DSTOP Signal Clearance Bug

[Cyclone]

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:

1. Set a train path crossing two separate sections with a signal in the middle.
2. Click the signal after the path is set and use STOP to turn it red.
3. 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.

 

[uetam]

The OSTOP command alone will not restore green signal to the semaphore if you have previously used the STOPcommand.
To restore green signal, you must clear the previous route with the ZD command and set new one.

[Cyclone]

17 minutes ago, uetam said:

The OSTOP command alone will not restore green signal to the semaphore if you have previously used the STOPcommand.
To restore green signal, you must clear the previous route with the ZD command and set new one.

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.

[lund456]

STOP has two functions:

1. The way you demonstrate it. A green signal can be set to Stop relatively easily.

2. Lock a signal to not show anything other than Stop. If you use the STOP command on a signal that is showing red, it will on the dispatcher screen indicate purple. This means it is locked.

OSTOP has one function:

Simply to unlock the signal from showing Stop. You can say it is the opposite of the function described above as number 2.

 

[Schyrsivochter]

Locking a signal is primarily a mechanism to remind the dispatcher not to use the signal. If, for instance, a signal is known to be faulty and unable to show correct ‘proceed’ aspects, dispatchers should route trains through other tracks instead, rather than through the ‘correct’ track using substitute signals or written orders – running with lower capacity and/or lower speed is preferable to running with less safety.

[Cyclone]

5 hours ago, lund456 said:

STOP has two functions:

1. The way you demonstrate it. A green signal can be set to Stop relatively easily.

2. Lock a signal to not show anything other than Stop. If you use the STOP command on a signal that is showing red, it will on the dispatcher screen indicate purple. This means it is locked.

OSTOP has one function:

Simply to unlock the signal from showing Stop. You can say it is the opposite of the function described above as number 2.

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.

[lund456]

When the signal is showing red/Stop, the STOP command will have the locking function and the signal will turn purple. If the signal is showing green, it will only set the signal to Stop.

It is also a question of safety. If a signal has been placed to Stop manually, it shouldn't be possible simply to set it back to green with the press of a button. It could be because of an emergency of some sort.

I really cannot think of any reason at all, where you want to place a signal to red just to set it back to green. Neither for my own personal logic sense, or from a safety wise perspective

[Cyclone]

On 2/2/2023 at 5:02 PM, lund456 said:

When the signal is showing red/Stop, the STOP command will have the locking function and the signal will turn purple. If the signal is showing green, it will only set the signal to Stop.

It is also a question of safety. If a signal has been placed to Stop manually, it shouldn't be possible simply to set it back to green with the press of a button. It could be because of an emergency of some sort.

I really cannot think of any reason at all, where you want to place a signal to red just to set it back to green. Neither for my own personal logic sense, or from a safety wise perspective

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.

Edited February 4, 2023 by Cyclone

[lund456]

I hate to use the "simulation" argument, but here I feel it is quite relevant to say. It is a fact that this computer game is branded as a simulation. I am pretty certain that the Simrail team takes pride in delivering a product that is realistic and true-to-life, both technically and visually.

My personal opinion is, that it would be a shame if it is required amend a bunch of functions, just to suit the ones that have a habit of pressing certain buttons by accident. By that ruining the experience for those expecting an accurate representation of a signalling interlocking. The only result of this, is compromising the goal of having a realistic simulation.

We have already seen the Simrail team do this with certain functions. For an example setting a signal in the wrong direction, which will immediately remove the route. In these cases, the alternative would be to have an even worse situation that cannot be solved in any sensible way every time, because the technical foundation is not quite there yet. I am sure the developers aim to find a solution to this in the future.

However when it comes to functions that work as intended, and don't work out to the users favour because they didn't know how it worked, then tough luck. The user should bite the bullet and take that minor inconvenience, as long as it's a problem that can be easily solved. Otherwise we will end in a situation where each button does something differently each week, because someone started to click a new button by accident. We can also start building new junctions at all stations that don't actually exist in the real life, because a new player in Gora Wlodowska sent a train into the wrong track, so it had to go on the left track to Zawiercie. Where is the limit?

Instead, I believe we should have focus on teaching players how to use the interlocking correctly, and make it easier for them to find out what happens when you press the big red button, and how to reverse your actions. We have a handbook right now, which doesn't exactly explain all features, for an example the one mentioned in this thread. But in order to not overwhelm any new players, it should be quick and easy to find details about each function in the current interlocking, and how to use it.

That is how to keep it realistic, and fun at the same time.

 

[hyzwar]

15 minut temu, lund456 napisał(a):

That is how to keep it realistic, and fun at the same time.

pro servers will be be set in "hard" mode // no UI, with maneuvers included, etc.

Edited February 4, 2023 by hyzwar

[Deadlost]

Even though I find most dispatcher stations intimidating(except for the northern ones 😄 ) One aspect of this sim is learning new stuff, like signals, rules of the road and track layouts.
Most of the stuff written above is way beyond my dispatching skillset at the moment, I want to learn it eventually. One strong point of any simulation is to be able to read the real documentation of things and sim working in the same way as long as possible. 

But there is allways a balance... Finding it can be tricky sometimes 🙂  

[Cyclone]

6 hours ago, lund456 said:

I hate to use the "simulation" argument, but here I feel it is quite relevant to say. It is a fact that this computer game is branded as a simulation. I am pretty certain that the Simrail team takes pride in delivering a product that is realistic and true-to-life, both technically and visually.

My personal opinion is, that it would be a shame if it is required amend a bunch of functions, just to suit the ones that have a habit of pressing certain buttons by accident. By that ruining the experience for those expecting an accurate representation of a signalling interlocking. The only result of this, is compromising the goal of having a realistic simulation.

We have already seen the Simrail team do this with certain functions. For an example setting a signal in the wrong direction, which will immediately remove the route. In these cases, the alternative would be to have an even worse situation that cannot be solved in any sensible way every time, because the technical foundation is not quite there yet. I am sure the developers aim to find a solution to this in the future.

However when it comes to functions that work as intended, and don't work out to the users favour because they didn't know how it worked, then tough luck. The user should bite the bullet and take that minor inconvenience, as long as it's a problem that can be easily solved. Otherwise we will end in a situation where each button does something differently each week, because someone started to click a new button by accident. We can also start building new junctions at all stations that don't actually exist in the real life, because a new player in Gora Wlodowska sent a train into the wrong track, so it had to go on the left track to Zawiercie. Where is the limit?

Instead, I believe we should have focus on teaching players how to use the interlocking correctly, and make it easier for them to find out what happens when you press the big red button, and how to reverse your actions. We have a handbook right now, which doesn't exactly explain all features, for an example the one mentioned in this thread. But in order to not overwhelm any new players, it should be quick and easy to find details about each function in the current interlocking, and how to use it.

That is how to keep it realistic, and fun at the same time.

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.

6 hours ago, hyzwar said:

pro servers will be be set in "hard" mode // no UI, with maneuvers included, etc.

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.