[markus_GE]

During revising some old activities for OR (adjust AI rtaffic, as it got out of sync with OR´s new AI System compared to MSTS) I found a "defective" Signal in one of These acts.

How are These handled in OR? Does it recognize them at all? Or would it be better to remove them right away?

Cheers, Markus

[c36dash7]

markus_GE, on 09 September 2013 - 02:10 AM, said:

During revising some old activities for OR (adjust AI rtaffic, as it got out of sync with OR´s new AI System compared to MSTS) I found a "defective" Signal in one of These acts.How are These handled in OR? Does it recognize them at all? Or would it be better to remove them right away? Cheers, Markus

Feedback : While I am not qualified to offer suggestions from the OR perspective, I would caution about the following : Assuming that a signal, is considered "defective" .

I just completed last evening, fully signaling a Route project , and did run into a few scenarios, where I had "assumed" some signals were defective , and, as it turned out, those were not .

The SIM ( on my low-resources computer hardware), simply was "too slow" to get the signals to function as intended , as the train was simply "getting there" ( at a specific signal's location ), while the SIM had not fully completed the required processing / calculations, to "present" the proper signal ( light ) aspects.

This happened to me, especially with either higher poly trains, or trains going at faster speeds ( faster than 50 miles per hour , etc... ).

Attempting to either "repair" or even "tamper with", a signal on a Route that is not your own creation, can cause irrepaireable / permanent damage, to that Route.

While I would not recommend any specific solutions, I would say you should "ignore" occasional deficiencies with the SIM, as it not perfect , and focus on what actually "works great" .

Jean Brisson

[markus_GE]

I think I´ve got to sort out a misunderstanding: With defective I don´t mean Signal s that don´t work because of a bug, but signals that in-game are set to be dark, as it could be done in MSTS - like from a broken power wire, so that there´s no electricty that could light the Signal. Nothing to do with Buggy Signal scripts etc.

Cheers, Markus

[c36dash7]

markus_GE, on 09 September 2013 - 11:11 AM, said:

I think I´ve got to sort out a misunderstanding: With defective I don´t mean Signal s that don´t work because of a bug, but signals that in-game are set to be dark, as it could be done in MSTS - like from a broken power wire, so that there´s no electricty that could light the Signal. Nothing to do with Buggy Signal scripts etc.Cheers, Markus

Markus : Once again, not being qualified to provide an OR perspective on this, but to the best of what I have learned so far, and actually, from reputable sources, as far as signaling, No, it does not appear to my understanding, that you could deliberately set a signal ( in MSTS ... ), to display a dark aspect .

For your own curiosity, I should perhaps mention that , in real-life, the majority of North American railroads DO have their signals display as "dark" ( meaning "unlit" / no electrical power flowing to them ), not until a train is "detected" within one or a few miles , from the signal's location .

This is in order to save on "battery life" , and still hasn't changed for many areas, regardless if solar panels are now being used, to "supplement" the available ( battery ) power for the signals .

I am sure others who are qualified with ( MSTS ) signaling, can offer some help, with your question .

Jean Brisson

[markus_GE]

It´s nothing to do with MSTS signalling either - it´s a Feature of the Activity Editor that you can click any Signal and set the flag "broken Signal" as to make it unlit throughout the activity as if there was no power / a broken bulb / whatsoever - as it can be encountered in reality.

In Addition I´m now through this concerned activity - and no, it did not work as in MSTS, the Signal set dead from inside the activity was just normally showing aspects as it should if it was running OK.

Maybe something to add to the wish list?

Cheers, Markus

[roeter]

Signal failure as defined in MSTS is not implemented in OR.
Also, I think that the way signal failure is implemented in MSTS is very unrealistic.
Most signalling systems - and certainly those here in Western Europe - have fail-save systems such that if a signal fails (to broken powercable or broken light etc.), there is a feedback to the signalling system which reports the signal as failed. Such a signal is automatically regarded as in state 'STOP', and the aspect of other signals will be related to that.
So, what happens in MSTS - where you continually pass green signals untill there is suddenly a 'dark' signal - will never happen in reality. In real life, preceding signals will show restrictive aspects, and the driver will be passed a 'special notice', telling him of the failure and the appropriate measures he is to take, like reducing speed and run 'on sight'. If the signal protects a junction, it may well be that this junction can no longer be operated and traffic is cancelled, or sometimes hand-operated through the junction.
So, the way this was implemented in MSTS will not be copied to OR as it is not the proper way to handle signal failure. To implement the full procedure as detailed above would take quite some time and has no priority.

Regards,

Rob Roeterdink

[markus_GE]

Thanks for the detailed answer.

What you say about how it is handled in reality is very Close to what I thought should occur after having seen a few short Clips on YouTube on this.

Will just take that one out of this activity, doesn´t matter at all.

Cheers, Markus

[rdamurphy]

In North American railroading, fault tolerance is neither required, nor often implemented. It is quite possible, and likely, that you could pass a CLEAR signal and encounter a dark signal with a burned out green light, or broken lens, which would be white, rather than green. GCOR rules allow for this. The signal then becomes it's most restrictive indication, ie, STOP for an absolute, or STOP&PROCEED or RESTRICTING for a permissive.

So, what happens when the train can't stop?

The rules state when a signal requiring STOP is overrun, the crew must:

•Warn other trains at once by radio.
•Stop the train immediately.
•Provide flag protection immediately against possible conflicting movements, unless relieved by the train dispatcher or control operator.
•Report it to the train dispatcher.

A similar situation occurs when a train is stopped mid-block, say for a broken knuckle or a brake hose failure. After 45 minutes, that previous signal that was CLEAR no longer applies.

Signals with flashing indications always show a LESS restrictive indication when flashing. For instance, if a flasher fails, the light becomes solid, and instead of Advance Approach, it indicates Approach.

There is a certain "logic" to this. If you receive a CLEAR, theoretically, the next signal can't be more restrictive than APPROACH, so overrunning the failed signal isn't as dangerous as one might think.

However, at that point, the signal basically ties up the line, so the MOW truck with the replacement bulb/lens is going to be rolling as quickly as possible.

There are other circumstances, for instance in Colorado, we have two additional signals for slide fences, for rock and snow slides, and flash floods. Either one will set all of the signals to STOP and no train can move until the MOW department inspects the track, and confirms it's safe and clear.

BTW, flash floods aren't to be taken lightly. In Eden, Colorado, just north of Pueblo, on August 7, 1904, a flash flood knocked the front of a train off a bridge, and 97 people perished. One victim was found 22 miles downstream in the Arkansas River. Passenger cars were found from 1 to 4 miles away.

The name of the stream, was ironically, Dry Creek. I've been to the site, and normally, you could hop across the stream and never get your feet wet:

http://virtualglobet...view/?service=0

But, back on topic (Ahem), it doesn't make sense to implement the flag in OR simply because it doesn't make sense in Europe, or on other continents.

It's rather odd, how much of a hodgepodge, MSTS really is, when it comes to how they implemented different features.

Robert

[markus_GE]

That´s a lot to think about.

The logics of all you said are obvious and clear so far. What else would make sense?

Well, having no broken Signal would be the solution, but is neither prototypical, nor adherent to OR´s MSTS-compatibility-Motivation. Just the different Systems, as so often they already did, make it difficult - in Austria, for example, most Signal Aspects use two lights, so one broken bulb / lens would not make it a totally inalid aspects, but rather Show a different one. I don´t know how this is handled according to the rulebook, but it´s definitely another Thing to be considered.

Of course, the easiest (and most MSTS-prototypical) way would be to preliminarily (!) just implement it the way it´s in MSTS and maybe wait with the rest for OR 1.0 / final fully-MSTS-compatibe release in Terms of thinking about it. As far as I can see, all the different handling rules would require additional entries in the Definition files for the route, so it would better be approached at a state, where OR does Support it´s own routes too - for MSTS routes, however, the old MSTS-like handling would apply.

What do you think?

Cheers, Markus

[CGW121]

Leave it out. MSTS has a lot wrong with it why replicate those aspects as well? Part of the appeal of OR to me is its ability to move on from , and improve on MSTS. If you are going to do something do it right, or do not do it.