SimSig:House Rules

Voice chat etiquette and protocol

Technical setup

Please ensure that all that Discord is transmitting is the beautiful sound of your voice when you're intending to speak to the channel.

Play with the voice-activation settings, or set a push-to-talk key, to keep out background noise, keyboard noise, etc. If necessary, use headphones to stop other people's talk from activating your mic - it's helpful if only the person who's talking has their name lit up in the Discord overlay.

When joining the session, it is advisable to rename your Discord nickname to your sim and workstation then your name in brackets, e.g. "KXC Palace (Claire)". If doing this, you must remember to update your Discord name if you change panels part way through a session, and when you leave the session, or it is over, that you return your username to what it was beforehand, as to keep the Discord server neat and tidy - it can get very confusing when someone has their name set to a panel they worked two weeks ago starts sending messages!

Pay attention to specific instructions on how to use ROC correctly as it continues to evolve. Please read the Railway Operating Centre Manual Page before beginning.

Keywords and phraseology

Begin your message with the name of the panel whose attention you want to get. Then state your identity (the name of the panel you're calling from), so the listeners know who you are without needing to swivel their eyeballs all the way over to Discord or its overlay. Then the subject of your message, such as a train, line, and/or location. Finally any additional detail you think might be useful

For example, you're sending a train out of Kings Cross, and you've just read its timetable and have the relevant details in your mind. The Finsbury signaller hasn't set a route for it yet, and if they don't take action soon, the driver will see the Double Yellows of Confusion, and reach for the Brake Lever of Delay:

• "Finsbury, Cross, 1S69 approaching on Down Slow (the main point of your message), scheduled for Platform 5 then Fast to Potters Bar (the possibly useful extra detail)."

If however the next signaller has already set a route for the train you can assume they've seen it coming and you don't need to say anything.

If you can see confusion and delay about to unfold in front of you while everyone else is politely taking it in turns to provide the channel with uninterrupted natter, start your message with Break, break. Its meaning is "I have an urgent message and need to cut in now, shush for a moment and listen, else there'll be Double Yellows of Confusion, Brake Lever of Delay, etc…", but it's a bit briefer. For example:

• "Break, break: Hitchin, Welwyn, 1S69 approaching."

Communicating with Control

Let the channel know before you call Control. Make sure neighbouring signallers know you're aware of any approaching trains, or ask them to set routes within your area if they see a need while you're out of the channel. You should also inform neighbouring signallers of the reason why you are causing control, if it is going to cause them a problem, and if a line is blocked due to a technical fault, to not send any trains into the failure to avoid them from getting trapped.

Control must be informed of any incident which has the possibility to cause delays to any train, including any technical fault, or a train which has stopped at a station and will be delayed at that station. You must also inform control of what impact this might have on other train running on nearby lines, so that control are aware and are able to take action to attempt to minimise delays to other services. Control must also be aware of any train running delay in excess of ten minutes, especially if it is a train which is contained within the session, either through a chain or as a result of rules in the timetable.

When you phone control to report an incident, you should try to give as much information as possible to the controller. For a signalling fault, you should give the nature of the fault (track circuit failure, signal failure, etc), what positions remain operable (no reverse detection, only a green aspect, etc), the precise location of the fault including the signal which has the fault, or is protecting the fault, and the first train which is to be affected by the fault. For an incident involving a train, you should give details of what train it is, where the train is and the nature of the fault. You should always tell the controller what impact it will have on train running, and whether any diversionary routes are available.

Be ready to write down detailed instructions from Control - on physical paper, Notepad, or a SimSig sticky note. Control is busy and it's very embarrassing to call back five minutes later to ask "was I meant to delay this train's departure along with the three you definitely mentioned".

When the call ends, let the channel know you're back, and pass on relevant information from Control. Even if it's not relevant information it's probably interesting.

Reminders (the signalling kind)

Be generous with using Reminders (on signals and controls in your own area) to embody decisions made by yourself, other signallers, and Control. For instance, if there's a train ready to start in one of your stations but Control has told you to keep it there, collar the departure signal. By doing this, Control can tell that you're applying their instructions, and also the other signallers on the panel can see it's sat in the bay with the TRTS light flashing because you've overlooked it but because of some good reason. If a route is shut, collar the signals leading into the route, and remove the reminders when you're told the route is available again.

When to Communicate

You should stay in constant communication with your colleagues. Neighbouring signallers need to know about what exactly is going on on your panel, even if it does not directly affect them, including notification of any signalling problems, as delays have the capability of spreading very quickly even onto unaffected lines. Signallers should have a good idea of what is occurring anywhere in any chain, especially with any failures, in case it has the capability to cause delays further across sims.

Signallers must also communicate clearly and frequently with controllers. Controllers must be made aware of any fault or failure of the signalling system as the signaller becomes aware of the situation - however in some instances it may be pertinent to inform neighbouring signallers of the failure and any immediate action which needs to be taken with regards to approaching trains, to ensure trains are not trapped by a failure before the controller is made aware, however the controller must be made aware as soon as practicable.

Controllers should also be made aware of any issues which affect train running which are not infrastructure related. This includes, but is not limited to, trains being delayed at stations, and trains entering the area late. Any train running delay of around ten minutes or more must be communicated to control at the earliest possible point, to allow for service recovery to be undertaken. Delays to trains can quickly spiral and start affecting more services, and a ten minute delay can end up causing a delay of over an hour further down the line. Similarly, any early running trains should be held in a loop or on a slower line where practicable to do so, unless it has been agreed with neighbouring signallers that the train can run early, to avoid any delays to services which are running to time.

You should also make sure to communicate with the controller should you begin to become overloaded or overworked whilst on a panel, as a signaller remaining overworked can cause additional, avoidable delays, and affect other signallers in a multiplayer chain. A controller will always be able to help ease the workload, whether by assisting themselves or finding an extra body to lend a helping hand to get train movements to a neater, more desirable state.