Page 1 of 1
| Failure patterns 06/02/2015 at 06:53 #68919 | |
flabberdacks
636 posts |
Hi all, I know we've already had a bit of chat today about failures and this isn't meant to be more of the same. I had a few questions about the way the F3 options window affects failures. I've played SimSig for over 2 years now and have been picking up on a few things. 1) When the number of total failures allowed is set to 0, but the 'Train delay probability' slider is set to a nonzero value, does this include trains becoming delayed at areas inside the sim? - Is a train that reports faulty doors considered a 'failure'? - Does 'Train delay probability' affect trains in-sim if total failures allowed is 0, or is this slider just for trains that have not yet entered? 2) Is there logic in the code whereby if there is a bad failure blocking lines, the sim will generate another failure? Maybe this is just coincidence, but on numerous occasions I've had a train die at, say, Drayton Park in KX and just as I am planning mass diversions, another train will die on the Hertford line, and then another, and they all start moving again within a few minutes of each other. This has to just be a coincidence, right? 3) When the number of total failures is set to a low number, say 1, does the sim line up another failure immediately the first is fixed? Several sims I've played seem to get really excited about destroying me and will fail another track or another set of points within seconds of the technician's call. 4) Are points failures coded to recognise wear and tear on points, or is it truly random? For example, are a set of points which are rarely used more likely to fail the first time they are needed, especially during bad weather? (could this be added to the suggestion box if not?) 5) Are there 'severity categories' for the duration of failed trains? For example, if the 'Train delay probability' slider is set to a low value, I only ever get door problems or passenger assistance, but if the slider is set, say, above 50%, this will introduce the probability of a train requiring a fitter? Thanks! Log in to reply |
| Failure patterns 06/02/2015 at 08:43 #68922 | |
AndyG
1842 posts |
As far as I'm aware:- 1) Trains delays are completely separate from failures, which are TCs, signals and points; 2) Failures are completely random, the probabilities as set by the developer and slider positions based on: a) TCs every 1 in x changes of state; b) Signals 1 in y changes of state; c) Points 1 in z operations; although TCs may have random failures too (not 100% sure). 3) Once a failure is fixed, another can occur within the probabilities as above; 4) Points fail in regard to their usage, so frequently used ones are more likely to fail (as per 2c); 5) Delay reason messages are related to their duration, eg 'fitter' relates to longer delays. I can only help one person a day. Today's not your day. Tomorrow doesn't look too good either. Last edited: 06/02/2015 at 08:44 by AndyG Reason: typo Log in to reply The following user said thank you: flabberdacks |
| Failure patterns 06/02/2015 at 09:01 #68923 | |
|
flabberdacks
636 posts |
Wonderful, thankyou! " said: As far as I'm aware:-TCs can definitely fail randomly in addition to your answer above, had one just today in KX, throwing a stick back right in a driver's face. I assume the same could be said of individual lamp failures during a signal failure? Sometimes a failed signal will show all proceed aspects but the red will be out, or will only show a single yellow and be unlit for all other aspects (with the signal in rear clearing for the yellow only, then going back to stop for the unlit green - ACOA city until I figured out what was going on!). Log in to reply |
| Failure patterns 11/02/2015 at 14:12 #69108 | |
|
clive
2789 posts |
" said:As far as I'm aware:-Correct. Quote: The code makes a failure test: - as part of every signal aspect change - as part of every points movement - whenever a track circuit clears - every second with a probability of 1 in 10,000 for each track circuit. The failure test first checks that the maximum count hasn't been reached, then tests the failure probability for the entity type. If the random test succeeds, the entity fails. Quote: More precisely, new failures are totally independent of existing ones *except* that the maximum can't be exceeded. Failures are *not* "queued up" waiting for an existing one to be fixed. Quote: Correct, though the idea of rarely-used ones being more likely to fail is, um, an interesting one. Quote: Each delay cause ("police", "wrong food trolley", "door problems"  has a different minimum delay and delay range value. The delay is a random time in the range [minimum, minimum + range * slider], with the slider ranging from 0 to 1. That is, you can't get below the minimum but can alter the maximum.For example, if a particular message has minimum 4 minutes and range 6 minutes, then with the slider at the left the delay is always 4 minutes, with it at the right it's between 4 and 10, and with it centred it's between 4 and 7. Log in to reply The following user said thank you: AndyG |
| Failure patterns 11/02/2015 at 16:13 #69112 | |
|
John 23
176 posts |
The curious thing that I've noticed about failures is that they are frequently geographically paired. In that I mean, that if the number of permitted failures at a time is, say two, then two failures may be concurrent. When one is resolved, another occurs in close proximity. When the second one is resolved that area gets another failure shortly after. After a pairing like that, once the second fault is resolved, the pairing in that area ends and then starts elsewhere. Hope that makes sense! Log in to reply |
| Failure patterns 11/02/2015 at 16:48 #69113 | |
|
Jersey_Mike
250 posts |
Has anyone ever considered making scheduled failures? One use would be if something goes wrong in real life one could see if they could do better than the real signalmen.
Last edited: 11/02/2015 at 16:49 by Jersey_Mike Log in to reply |
| Failure patterns 11/02/2015 at 17:08 #69115 | |
|
clive
2789 posts |
" said:The curious thing that I've noticed about failures is that they are frequently geographically paired.There's absolutely nothing in the code to cause that. It's probably just the human ability to underestimate the frequency of coincidences. Log in to reply |
| Failure patterns 11/02/2015 at 17:20 #69118 | |
|
Danny252
1461 posts |
" said:It's probably just the human ability to underestimate the frequency of coincidences.Confirmation bias, to give it a name - you suspect some pattern exists, and so you tend to pay special attention to events that match that pattern. Last edited: 11/02/2015 at 17:20 by Danny252 Log in to reply |