coasterguy321

I haven't seen anyone suggest that the park is to blame. I have seen two people state explicitly that the patron that went into the danger zone is entirely at fault. It's not insane to suggest that the park could do with more direct communication of their loose article policy (by ride operators, signs at ride entrances/throughout the queue, etc.). I personally disagree, but that is a reasonable idea, and is certainly very far from blaming the park. The fact of the matter is that Cedar Fair is a large corporation, and large corporations have to look at every angle. The questions that will be asked internally are along the lines of: "Is the communication of our policies direct enough?" "Are our policies themselves adequate?" "Is there anything that we are not doing that we can do to prevent this from occurring again?" Personally, I think that the answers are yes, yes, and not much. However, suggesting otherwise does not make someone a "moron" or a "f**king idiot." We should be able to discuss these things without that sort of ridicule. Even if someone were to suggest that the guest were not at fault, it's just an opinion, and we should be responding with a pointed retort, not some cheap insults. Condolences to those involved.

100% human error. This is the only conceivable scenario considering the amount of safety systems and redundancies that are involved in modern ride control systems: (Assume train 1 = train dispatched first, train 2 = train dispatched next) Assumptions: Ride control system allows train 2 to be dispatched (to lift, let's call it Block A) before train 1 has cleared the block immediately following lift (let's call this Block B). This dispatch is allowed because it is assumed that train 1 will clear Block B (reach the next brake or lift) in time for train 2 to be allowed to continue into the block. If train 1 has not cleared Block B by the time that train 2 reaches a certain point on the lift, the lift stops and is not allowed to restart until that block is clear. (The lift may automatically restart when the block is clear, or the operators may need to manually restart the lift; which of these is the case varies from ride to ride) Alton Towers incident In this incident, we can deduce the following: There are reports that the loaded train (train 2) was sitting idle on the lift for a while (I think I read 5 minutes somewhere). We also know from the collision that there was a train (train 1) that became stuck in a valley in the next block (which we called Block B). Putting 2 and 2 together, we can assume that the ride's safety systems acted as designed and stopped the lift, holding train 2 in Block A until Block B cleared. Now, these complex control systems don't just "forget" which blocks are occupied. A power failure or "system reset", as someone in this thread suggested, of a modern ride control system would result in all of the ride's blocks being set, not the opposite. Otherwise the unthinkable would occur if a ride were to lose and regain power in a short amount of time. Blocks are also not accidentally cleared by anomalies, such as a bird flying in front of a photoeye. Safety-critical control systems are designed to fail to a safe state, and they are very redundant. For example, a bird flying in front of a photoeye may result in an additional block being set, not in a block being cleared. There are all sorts of sensors and components that can have a say in whether or not a block is occupied: proximity sensors, photoeyes, brakes, and even motors. If even the smallest anomaly is detected with any of them, the block will be set, just to be safe. "We don't know what caused X, but it could be a train. We'd rather assume that it is a train than assume otherwise and cause a collision." This is what causes "ghost trains." With that in mind, let's go back to the above scenario. A ride technician responds to a breakdown, and sees that train 2 has been sitting on the lift (in Block A) for 5 minutes or so. He looks at the logs and sees that the control system is holding it there because Block B is still occupied, meaning by extension that Block B has been occupied for at least 5 minutes. A valley certainly is far from a normal occurrence, so it was not likely anywhere near the front of his mind. Additionally, judging from the picture, it appears that this ride is low-capacity, which means that it likely runs at least 4 or 5 trains at all times. It seems very likely that one could easily mis-judge the number of units on the track, pair that with the fact that a free-running block has been occupied for at least 5 minutes, and assume that some anomaly has resulted in a ghost train (as mentioned above). (In reality, however, we now know that Block B actually still is occupied.) The technician in this situation then likely cleared Block B, allowing train 2 to continue, where it then collided with train 1. The technician should have at least verified visually that there was not a train in the block that he was clearing, but he really should not have been clearing a block with a loaded unit on the course, anyway. (Doing so is actually in violation of an ANSI standard.) However, clearing a block without even verifying that it was indeed clear would certainly be the most horrendous portion of this violation. I hope that didn't come off as rambling, but I'm trying to make the point that modern control systems--especially safety-critical ones--are redundant, fail to a safe state, and were not the cause of this accident. This is simply the only reasonable chain of events that could've led to this collision. "Glitches" don't cause this. "Bad design" doesn't cause this. Human error does.