Telecommunications are the means by which all communication through headsets are managed. Without these computers, all crewmen would be forced to rely on Station-Bounced Radios and Station Intercoms, which do not rely on these machines.
The Telecommunications network is one of the most over-complicated systems in SS13, and while it can seem daunting at first, such is the same for things such as Atmospherics.
This guide will teach you how to be one of the few heroes the station needs in all events relating to an outage.
Though if there's an outage and you can't be bothered to give a fuck about the theory and just want to fix it, view the section on how to fix it here.
Contents 1 Control Room 2 Signals 3 The Machines 4 Normal Signal Flow 4.1 Bare-Bones Edition 4.2 Full Edition 5 Telecommunications Storage 6 Maintenance Guide 6.1 Server exclusive 6.2 Linking 7 FIX IT 7.1 It got partially blown up, not all machines are missing! 7.2 All the machines are gone. 7.3 Machines appear to be intact and on, but there's still silence. 7.3.1 NTSL Script Fuckery 7.3.2 Machine configuration 7.4 Machines are off 7.5 Garbled Radio Messages 7.6 Laggy Radio Messages
Control Room
Note the five computers. The machines doing all the work generate absolute tons of heat. This heat gets cooled, and as a result the main chamber always stays at a nice and comfortable 80 Kelvin. Humans obviously cannot survive in such temperatures, so there are computers in the control room that allow you to, well, control the machines without putting on one of the NASA Voidsuits.
To make it possible for the computers to find them, the machines have a Network setting. This setting must match the setting on the relevant computers. They also have an ID tag to allow easier distinguishing. The default network name is tcommsat, ID dependent on the machine in question, but newly constructed machines will have both of these settings default to NULL. Note that the network and ID of a machine are irrelevant to signal routing, the machines will function fine with them scrambled assuming everything else is in order.
The functions of the computers are as following:
Computer comm serv.gif Telecommunications server monitoring console: A computer used by authorized individuals to read the record of radio messages transmitted on any channel. Computer generic.gif Telecommunications traffic control console: The most used computer. This computer allows authorized individuals to input NTSL Scripts, which can manipulate messages as they are received to output as something else. Computer comm monitor.gif Telecommunications network monitor: Allows one to check how the machines in the Telecommunications Chamber are linked to one another. Useful for learning about networks, but used little in practice. GACComp.png Temperature Monitor: This is a polymorphous tank monitor computer that is by default linked to the gas sensor in the Telecommunications Chamber. It is used to determine if the chamber is properly cooled. Telecom equipment should be stored at below 40C (313.15K). Computer comm logs.gif Message Monitor: Links up to any Messaging Servers. Allows the user to view all PDA message records and send System Administrator messages if they have the Monitor Decryption Key, which is held by the Research Director. Signals When you speak into a headset, the message is wrapped in a “signal”. Every Sreceiver.gif Subspace Receiver on the Z-level can then capture this signal and relay it to other machines. A machine can both receive signals from other machines, and relay signals (with or without modifications) to other machines. Machines are smart and will choose where to send their signals, however to send a signal a machine must be linked. See the maintenance guide on how to set up links below. Links are always two-way. On top of linking, a machine also has a list of frequencies to filter from. It will not be able to work with signals with a frequency not on this list. (this is how those 8 servers in the telecommunications chamber are separated.)
The Machines Telecommunications has 9 machines in total, about half of which are necessary for basic system functions. See the maintenance guide down below for instructions on how to use them.
Sreceiver.gif Subspace receiver: Captures signals sent by the crew's headsets and radios. Without this the system can't hear you screaming about that ling. Required Bus.gif Bus: Routes the signals between some of the machines. Essential for a functional network, as the Processor cannot talk to the Receiver and Broadcaster without it. Required Pro.gif Processor: De-codes the signals received. While the network can technically live without it, it's useless because without this the messages will be complete gibberish and the network will suffer severe slowdown. Required Broad.gif Subspace broadcaster: Sends the signals received to all the headsets and radios on the station. How can a system function without mouth? Required Hub.gif Hub: Does additional routing to allow signals to use the Relays on the other Z-levels. While not required for on-station functions, without this the asteroid won't be able to join the conversation. Relay.gif Relay: Extends the range of the signals passing through any connected Hubs to the Z-level this Relay is on. Again, not required as long as you ignore the miners on the asteroid. Note: the two relays in the Telecommunications Chamber do absolutely nothing and can be ignored, as broadcasters always have range in their own Z-level. Server.gif Server: Records and executes NTSL Scripts on messages relayed from the Processor Unit, also controls the names and colours of the frequencies as they appear to people. The least necessary of them all and only used for malice most of the time. Messaging server.gif Messaging Server: Manages text messages for PDA devices, purely through “real space”. Does not affect radio, but the sole requirement for PDA functionality. Blackbox.gif Black Box: A device that supposedly “records” all messages. Nobody knows what it does and it might as well have no function. It's the weird dude in the corner at a party that doesn't do anything and nobody recognizes. On a pragmatic level, only one of each of these machines is required. This often provokes questioning into why most maps splits up filtering across many different machines. By having multiple servers, one is able to apply different scripts for different channels (such as a game script solely the common channel). The rest is a matter of avoiding vulnerability: by spreading out frequencies across four different buses and two sets of relays/broadcasters/receivers, the machinery has a higher chance of surviving sabotage.
Also note that the signals always attempt to take the most “complex” route. This means that if you have a Server connected solely to a Bus, the Bus will send its signals to the Server, but the Server is unable to relay them to a Hub or Broadcaster, and all signals going past that Bus will be lost.
Normal Signal Flow
Telecommunications Signal Flow Diagram, Click to Enlarge. Bare-Bones Edition This is the minimum needed for a signal to be routed correctly and clearly. The default setup is slightly more advanced and can be seen below, but if you need to fix the radio because somebody blew up Telecommunications, this is all you need.
Headset.png Somebody talks into the radio with a Radio headset. Sreceiver.gif A Subspace receiver catches the signal and relays it to a Bus. Bus.gif A Bus relays the signal to a Processor. Pro.gif The Processor De-codes the signal and makes it not-gibberish, then sends it back to the Bus. Bus.gif A Bus relays the signal to a Subspace Broadcaster. Yes this can totally be the same Bus. Broad.gif The Subspace broadcaster shoots the signal out in the wind for the headsets to catch. Headset.png And finally everybody with a Radio headset hears the message loud and clear. Full Edition This is the routing of the signal on the default setup of all maps.
Headset.png Somebody talks into the radio with a Radio headset. Sreceiver.gif A Subspace receiver catches the signal and relays it to the Hub. Hub.gif The Hub relays the signal to a Bus. Bus.gif A Bus relays the signal to a Processor. Pro.gif The Processor De-codes the signal and makes it not-gibberish, then sends it back to the Bus. Bus.gif A Bus relays the signal to a Server. Yes this can be the same Bus stop asking! Server.gif A Server logs the message, executes NTSL Scripts on it and sends it back to the Hub, assuming the script didn't block the signal. Hub.gif The Hub connects with any Relay.gif Relays to extend the signal range to other Z-levels such as the asteroid, then passes it onto the Subspace broadcaster. Broad.gif The Subspace Broadcaster shoots the signal out in the wind for the headsets to catch. Headset.png And finally everybody with a Radio headset hears the message loud and clear. Telecommunications Storage
Boxstation's Storage Room When telecommunications are used, the machines generate heat. This means that during longer shifts, the chamber can potentially heat up to the point of un-usability. This room is the major force to combat that, and is also equipped with the tools you need for maintenance.
Red Nitrogen Tanks control the air-flow for the room. This is how the room re-fills if it loses pressure, such as to a bomb or malicious panic siphon. Dark Blue CO2 Tanks help regulate temperature. The bottom two tanks are cooled by refrigerator and transfer their heat via heat exchange pipes to cool the room. The top tank is used for warming the airlock back up so that the control room isn't blasted with cold air when returning from maintenance. Power Storage Unit or SMES works as a battery for telecommunications. This ensures that the chamber and control room do not run out of power, and can be set up to charge off the station. It has enough charge to last far longer than any shift will run. Components are used for the rebuilding of broken machines. Consult the Guide to Advanced Construction. Insulated Gloves and NASA Voidsuit (in the red closet) are used for maintenance in the cold, unsafe telecommunications chamber. The latter also comes with a jetpack for historical reasons. Space Heaters are available in case you accidentally fill the control room with cold air by breaking the glass or forcing both airlocks. Maintenance Guide
The multitool menu. This part of the guide focuses on how to use the machinery, not to be applied if you just need to fix it.
To open a menu on a machine, hit it with a multitool. This will open the menu shown on the right. The menu has a lot of knobs and whistles so let's go over it nice and slowly.
Note: some machines may have additional options. Should be self explanatory in that case.
Status Display: after doing an action, at the very top there will be a temporary text confirming what you did. Integrity: Ranging from zero to one hundred, determines the severity of the damage to the machine. Under normal circumstances it should always be at 100%. To restore a machine's integrity a filled soldering iron has to be used on it, after opening the maintenance panel with a screwdriver. Alternatively, if the machine was destroyed and only a circuit board is left behind, it's still possible to restore its integrity with the soldering iron. Power Status: Master power switch for the machine. If it's off it's off. Identification String: The ID for this machine. Again, purely for organizational and cosmetic purposes. Network: Network name for this machine. Used to allow computers to access this. Prefabrication: A value you cannot change. It is TRUE if the machine has a default config from round-start (AKA, you didn't build it from scratch). Linked Network Entities: A list of objects that are “linked” to this machine. Linking allows machines to relay signals between each other. The entries are made of the following elements: An arbitrary memory address for fluff. Name of the machine. ID of the machine. A button to break the link. Filtering Frequencies: A whitelist of frequencies. If this is empty (NONE), all frequencies are allowed. Used with frequency names on servers to identify names with frequencies, if a certain frequency is leaked or compromised, change this. Multitool Buffer: The menu to link machines together. Server exclusive Frequency Names: The name and colour associated with the filtering frequencies for this server, in the same order. Can be changed to anything with the right access, allowing that red security channel to show up as a pink HONK. Linking To link two machines, add the first machine to your multitool buffer with the [Add Machine] button. Hit the other machine with your multitool and hit [Link]. You can [Flush] the multitool buffer once you're done to empty it.
FIX IT Something's fucky with comms, a herd of people has already formed by the door of the control room, and somebody just opened the windoors while somebody was disabling the turrets, and now everybody is taser'd. This is your one-stop-shop for how to fix the radio in case of an outage, any outage.
The first step to fixing a problem, is figuring out the problem, and then going through some very basic steps.
It got partially blown up, not all machines are missing! The Telecommunications room has a lot of duplicate machines, most of which only manage 2 channels each. If say, half of the room got blown up, all you would need to do is to remove signal filtering on the other side and the machines can take over.
Because of the “redundancy” in the default network, getting everything to work properly is quite a bit of a pain (god forbid resetting the frequency filters on the common channel), especially if you don't actually understand it. For this reason you're probably better off turning everything OFF, then resetting only the basic machines you'll need, and then turning only those ON.
You either read the theoretical wall of text above, or you just want to fix it. Either way, the only machines strictly needed are the following:
Sreceiver.gif Subspace receiver Bus.gif Bus Pro.gif Processor Broad.gif Subspace broadcaster Hub.gif Hub If you don't want to neglect the miners on the asteroid, else this isn't needed either. If any of these machines are missing, you'll need to build them from scratch.
Turn all machines off, except one of each of the above. Then reset all the frequencies and links on each of those. Oh but make sure to keep the Hub's link to the Relays on other Z-levels.
Then redo the linking with the “Linking” section of the From Scratch guide, as if you have fresh machines you just built.
All the machines are gone. See From Scratch.
Machines appear to be intact and on, but there's still silence. There's 2 potential causes here. Either somebody made an NTSL script that blocks all messages, or somebody fucked with the configuration of the machinery.
NTSL Script Fuckery This also applies if somebody made a script that screws with radio messages in general, such as replacing words.
Go to the Computer generic.gif Telecommunications traffic control console in the Control Room. Log in. Go through every server in the entry. If there are no listed servers after hitting [Scan], make sure the network is set to tcommsat. If it still doesn't show anything, somebody sabotaged the network configuration of the physical servers. Go in and reset their names to tcommsat then come back. Make sure Signal Execution is set to Never. This should prevent scripts from messing with the signal.
Machine configuration The machines are there and on, but it's still silent. There's no scripts screwing with the messages. Somebody messed with the configuration of the machines.
'You have two options here:
Try to figure out what got sabotaged, where everyting is broken, the hard way. You need to actually understand the huge wall of text above. Especially the signal routing. Fix it properly. There's no more help on this subject other than the wall of text above. Just get it done and over with and just follow It got partially blown up, not all machines are missing!. Reset everything and revert to a “minimal” setup. Machines are off Does the area have power? Check the APC. Is the machine disabled? Make sure it's on in the multitool menu. If the menu says it's on, but it very clearly isn't:
A communications blackout may have EMP'd the machine. The crew does not always get notified of this, but the AI does. Wait it out. The machines may have overheated. When the chamber gets sufficiently hot, the machines' integrity starts to decrease. This will slow down their function and might corrupt the data flowing through them, until the integrity reaches zero, at which point the machine just stops working. See the Maintenance Guide above to fix this. Make sure to fix cooling if this is the case so the machines don't overheat again in 4 minutes. Garbled Radio Messages This probably means the Pro.gif Processor is messed with, re-link the Processor to their relevant Bus and it should be resolved. If not, see NTSL Script Fuckery. Laggy Radio Messages Caused by severe damage to the machinery in the chamber. Probably from overheating. See the Maintenance Guide above to fix this.
Easy Guide to Fixing Telecomms The radio stopped working all of a sudden? Or did someone just blow up the tcomms again? Here's a quick checklist-guide to see what's wrong and how to fix it:
Has it been partly blown up? Ensure that the room APC has power. See which of these machine/machines are missing/blown up: Receiver, Bus, Processor, Broadcaster. Reset one of each machines, which are still functional, with a multitool (unlink and remove all frequencies). Go to Can We Fix It, build the missing machines and link them by following instructions. (For example, if everything except the SMES, APC, Receiver and Bus has been destroyed, you still need a Processor and a Broadcaster. Reset the Receiver and Bus, construct Processor and Broadcaster, link them to the Bus and voíla.) Completely blown to shit or stolen and thrown into the singulo? Go to Can We Fix It and follow instructions. Everything intact but machines are off (no pretty flashing lights on the machines)? Was there a Central Command Update for something like “Ionospheric anomalies detected. Temporary telec#MCi46:5.;@63-BZZZZT”, if so, wait a few minutes and equipment will come back online automatically. Note that this can happen without sending you any kind of warning, so just wait 5 minutes if nothing else works to see if the machines come back alive on their own. Check APC: Main breaker and equipment should be on. If not, turn them back on. Check equipment with a multitool and see if Power is set to on? If no, turn back on. Equipment is on, but still nothing heard through radio? Check Telecommunication Hub with a multitool. Network name set to tcommsat? If no, set it back to tcommsat and… Go down the Telecommunication Hub's menu until you see MULTITOOL BUFFER. Click [Add Machine], the Hub's info is now inside your multitool's memory. Use multitool on a Subspace Receiver (for example, you will have to do this for every machine anyway). Scroll down the menu and click [Link] to link the machine back to the Hub. Repeat this for every machine (except smes, blackbox recorder, messaging server and computers outside). Check other devices that they have power on and correct network name. Go to Telecommunications Traffic Control Console. Log in. Scan for servers. Click on a server. And see that Signal Execution is set to [NEVER], so that there's no malicious NTSL script blocking information. Go back to main menu and repeat steps for all servers. Quick Guide to Telecommunications If you just want to know how to fix everything incredibly easy, skip to the image.
The room:
Full of supercooled gas. Don't breathe it, don't stand in it without internals. It has its own SMES and APC. If the APC is destroyed, replace it immediately. If the APC has power temporarily cut, look at the PDA server; if its light is red, the APC probably has a remote signaller in it, because killing APC power turns off the PDA messaging server indefinitely.
The tools All machines are accessed and controlled by a multitool. One is in telecomms at the round start. To link machines, you add a machine to the multitool buffer then use the multitool on the machine to link to and hit [Link] at the bottom. Most telecomms machines will also have FILTERS to determine which frequencies are sent through which pieces of machinery. Additionally, each machine has an IDENTIFICATION STRING, which is just its unique name, and a NETWORK, defaulted to tcommsat, which allows it to link to machines on the same network name only. IF YOU CHANGE THE NETWORK NAME IT'LL UNLINK EVERYTHING. CHANGING THE HUB'S NETWORK NAME IS A COMMON METHOD OF GHETTO SABOTAGE. WATCH FOR IT.
The machines Subspace Receiver: Intakes radio signals Subspace Broadcaster: Sends radio signals Bus Mainframe: Regulates radio signals Processor: Decodes radio signals Servers: Log radio signals, execute NTSL scripts. Hub: Takes in radio signals and sends them to appropriate machines. Relay: Connected to a Hub on another Z-level. Allows radio signals on its Z level to be run through the telecomms infrastructure of its linked hub. Standard Structure Each step is sent through the HUB typically
Station Bounced Radio.png Signal goes from headset/intercom/etc Sreceiver.gif to a RECEIVER Bus.gif Signal is sent to the appropriate BUS MAINFRAME Pro.gif Signal is sent to the bus's corresponding PROCESSOR. Note that THE PROCESSOR AND BUS MUST BE DIRECTLY CONNECTED Bus.gif Signal is returned to the BUS MAINFRAME Server.gif Signal is logged at the SERVER and has scripts applied Broad.gif Signal is sent to the BROADCASTER Headset.png Signal is sent to all appropriate radio devices
Parts that are not optional:
Subspace Receiver Subspace Broadcaster Bus Mainframe
Parts that are functionally non-optional:
Processor. Why? You get this otherwise:
/;vr; [145.9] says, “*ok at a;<th$>/e >$s>*v p*is#$*& otng tr#nsl%/”
Selene Avery says, “Look at all these massive penises not being translated.”
P [Engineering] yells, “;oly>$anna*>*&*&%$e The above is a link of Receiver to Bus to Broadcaster. Can We Fix It? NOW TO IGNORE EVERYTHING ABOVE AND TELL YOU HOW TO FIX TELECOMMS INCREDIBLY EASILY NO MATTER WHAT'S DONE TO IT. Tools you need: Screwdriver tool.png Screwdriver Wrench.png Wrench Wirecutters.png Wirecutters Crowbar.png Crowbar Total list of items you need (NOTE: most of these items can be found in the Technical Storage, but not enough to build everything from scratch, if you're doing exactly that, we suggest deconstructing any telecommunication-machines that are left over from the explosion or whatever, if that's not an option, go bug R&D to make you items): 1x Circuit board.png Subspace Receiver Board, 1x Circuit board.png Bus Mainframe Board, 1x Circuit board.png Processor Unit Board, 1x Circuit board.png Subspace Broadcaster Board 1x CableCoils.png Cable Coil 9x Micro Manipulator.png Micro Manipulators (only 4 in Tech Storage!) 1x Scanning Module.png Scanning Module (none in Tech Storage!) 3x Micro-laser.png High-Power Micro Laser 4x Hyperwave filter.png Hyperwave Filter 3x Subspace ansible.png Subspace Ansible 1x Ansible crystal.png Ansible Crystal 1x Subspace Analyzer.png Subspace Wavelength Analyzer 1x Subspace amplifier.png Subspace Amplifier Machines you need to build: Sreceiver.gif Subspace Receiver Bus.gif Bus Mainframe Pro.gif Processor Unit Broad.gif Subspace Broadcaster These can be done in any room/hallway with a powered APC, including a bombed-out telecomms room or anywhere else. After building: Clear ANY frequency filters on the machines. Grab the Bus Mainframe and put it on your multitool buffer (down on the list, click “Multitool Buffer”) Link it to the Broadcaster, Processor, and Receiver (click “Add Machine”). That's it. You're done. It'll process all telecomms signals with no lag, no static, no loss of functionality. A More Elaborate Guide to Telecommunications The Central Compartment A basic example of a telecommunication central compartment. All essential machines, including a monitoring and logging computer, are present. A functional telecommunication central compartment (otherwise known as the “Server Room”) contains several machines, each with its own isolated function. These machines make up a usually independent telecommunication network, with a pre-specified array of frequencies to process. Optionally, monitoring computers may be used to keep track of telecommunication activity and network integrity. It is important to notice that the machines, most dominantly the Processor Units, generate a significant amount of heat. The central compartment is generally kept at a very low temperature to prevent the damage of the hardware infrastructure, so maintenance is usually not done without proper protective equipment. A central communications compartment is not necessary for a functional telecommunications network. In fact, it may be more efficient to separate the network into sub-nets. Nanotrasen Tech Department, however, strongly suggests the centralization of the machinery for easier maintenance and bookkeeping. While a strong central compartment may be easier to maintain, it is also easier to sabotage or blow up. The only thing worse than explosive concussion damage and massive atmospheric de-stabilization is a downed communication grid. A central compartment should be well-fortified and stable, and fortunately for the crew, Nanotrasen cannot pinch for pennies in this department. The station will either receive a robust Communications Satellite or inner-station Server Room. The Machines There are 5 different kinds of machines essential for a healthy telecommunication network. Without one or the other, the entire system would cease to function or would not function optimally. All telecommunication machines idle until they receive a signal, and all the machines are built with Hyperwave Filtering modules that allow for the scanning of signal's frequency regardless of intensity. This means each machine can selectively choose which signals to pay attention to, if there are any specified frequencies to tune into. Sreceiver.gif Subspace Receivers Subspace Receivers are essential to a subspace telecommunication network. They have a long-term subspace window open at all times, and create the subspace-equivalent of a gravity well in its warped version of space-time. FTL signals traveling in subspace are going too “fast” to be sucked into the gravity well, but a carbon copy of the signal is produced whenever a signal passes through the pocket. This signal is then converted into a real radio wave by the Subspace Receiver and passed onto all immediately-linked machines. In a typical scenario only Bus Mainframes would receive the signal. Relay.gif Telecommunication Relays Telecommunication Relays are very essential creating a full network. They allow the network to expand by being able to send signals past Z levels. Meaning that when saying something in the radio, after the message is processed the HUB will locate all linked relays and add their Z level information to the signal data, which will then broadcast on the level when it reaches the broadcaster. It works by charging atoms for an almost faster than light signal. It then gets broadcasted to the hub, the only machine that can receive these almost-light speed signals and then sends them ideally to a Bus Mainframe. Hub.gif Telecommunication Hub Telecommunication Hub is the main junction for the network. It is connected to many relays that are scattered along space, waiting to receive and send information to buses and relays. It uses a high level technology of circuits to send information as efficiently and as fast as possible. A simple visual synopsis of a basic radio telecommunication network. It shows the “route” a subspace transmission travels before it reaches its end destination(s). Bus Mainframes Bus Mainframes regulate and handle the transfer of massive quantities of data at near instantaneous speeds. They are not essential to a network, but are required to keep data transfer instant. They usually transfer data back and forth between servers and processor units. If a Bus Mainframe is missing, network output may be unreliable or slow. Processor Units Processor Units decrypt, clean and stretch hyper-compressed radio signals. Radio signals are sent into subspace using a preset encryption hash but random seed, which makes the process of encrypting and sending very light but unpacking and decrypting heavy due to the weird nature of subspace. Processor Units can instantly make signals readable by other machines. They are not essential to a subspace network but if one is missing, network output may not be understandable. Telecommunication Servers Telecommunication Servers log network statistics and signal traffic for easy maintenance. Each server represents a “channel” in the Nanotrasen default settings. They can listen in to multiple channels, however. For each signal that is sent to a server, a database entry is created and the signal's information is stored. The servers also help by sorting the order in which signals are transferred to subspace broadcasters, which is vital for instantaneous signal transferring. Additionally, Telecommunication Servers are capable of running user-written scripts through use of a Telecommunications Traffic Monitor. When a signal passes through a server (and the server is set to automatically execute code), the interpreter halts the signal until the code has finished executing, then releases the signal. During this time, the server's script interpreter can modify the signal's contents or flag it as a rejected signal, which will cause broadcasters to ignore it. Subspace Broadcasters Subspace Broadcasters are impressive pieces of hardware that are capable of opening large enough subspace windows to transfer de-compressed data bursts, in encoded radio waves, through. They are necessary for any network that is expected to output information back to receiving radio devices. They operate by directing high-powered lasers into a small subspace window and fluctuating the amplitude of radio waves through subspace, allowing the large data packets easier entering and exiting of subspace. =====Maintenance Guide===== Telecommunications machines are flexible and can adapt to structure changes, and they are otherwise immortal to mundane errors and crashes. However, in the event of a catastrophe such as an explosion, singularity, or anything of the like the default warranty becomes void and the machines will probably be destroyed or totaled. If one or more machines are destroyed, chances are the entire communication grid or at least part of it will be down. While intercoms and station bounced radios are capable of limited non-subspace communication it is most definitely not reliable. It should be maximum priority to get those machines up again. If you suspect the machines aren't working properly (or at all), you should identify the cause first. Probably the most common issue is an exploded central compartment. Repair any structural damage and assess the machines. If they're still on (flashing/blinking lights, etc) then they are relatively functional. If there's been some atmospheric depressurization you're going to want to pump supercooled air into room; the machines need cold gas to survive or they will not be able to diffuse their heat into the environment, and will overheat. If the machines have been overheated, you can fix them by simply reconstructing them. To do this, first unfasten the exterior bolts with a screwdriver. Next, dislodge the plating with a wrench. Next, remove the internal cables with some wirecutters. After that, you can use a crowbar to remove the internal components and circuit board. From there, you can either deconstruct the empty frame or simply rebuild it. If the machines have been completely destroyed, you're going to want to build more. You're going to have to bug R&D for some really high-tier circuit boards and stock parts, or salvage some parts from other toasted telecomm machines. Keep in mind, you don't have to reconstruct ALL the machines. At the very minimum you need 1 receiver, 1 processor, 1 server, and 1 broadcaster. You might have to manually reconnect to relays if they are destroyed, this involves a long walk. =====Telecommunication Polymorphism===== The machines can be retrofitted manually to work with other machines that normally would not be very common or wise. In the case of an emergency, however, it can be a life-saver. You can use a multitool to interface with telecommunication machines, which will allow you to modify some of the machines' properties. You can also link together machines with this interface, which is possibly the most important function. In order to link two machines, access one of them with your multitool. Select [Add Machine] at the bottom of the window to store this machine in the buffer of the multitool. Now access the other machine with the same multitool. The machine previously buffered should still be in the buffer of the multitool. Select [Link] to add the machine currently buffered to the list of machine links of the machine currently accessed. This will establish a link between these two machines. (Note that it is possible to link a machine to itself; this is both harmless and pointless.) ====Subspace Receivers==== You can link Subspace Receivers to Processor Units if you are unable to link to a functional bus mainframe. This can and will create substantial network lag, because Bus Mainframes are needed for rapid information transferring and advanced port configurations. ====Bus Mainframes==== You can link Bus Mainframes to Subspace Broadcasters if you are unable to link to a functional server. This will not have much of an effect besides a very miniscule performance decrease. If you do not link to a Processor Unit, signals' readability will suffer substantially. It will also make it impossible to directly link to broadcasters. ====Processor Units==== You can link Processor Units to Telecommunication Servers if you are unable to link to Bus Mainframes. This will naturally have a significant performance cost. ====Telecommunication Relay==== Relays must be connected to a HUB in order to add information to the signal about the Z level it is in, the Z-level above it, and the Z-level below it. It will broadcast in these levels. It cannot be linked to any other machine usefully. ====Telecommunication Hub==== This machine is essential when creating relays that allow you to send the same signal to multiple broadcasters on different space levels. It is ordinarily connected to Relays, Servers and Buses. When it receives information from Relays it sends it to all linked Buses. If it receives information from a machine that isn't a Relay, it assumes it's ready-to-transmit data and then sends it to all linked Relays. This data is ideally received from Servers but Buses and Processors can send this information too. ====Telecommunication Servers==== These cannot really be linked to anything else other than a broadcaster. They are only needed to store logs and maintain sane bookkeeping. ====Subspace Broadcasters==== These are ESSENTIAL if you want an output. There is nothing you can do with these in terms of polymorphism. =====Departmental Frequencies===== If you're going to be messing with telecomms, you're going to want to know the right frequencies for each channel. You could look at the servers to tell which is which (if they still exist), or you could look here: * 145.9: Common Frequency * 135.9: Security * 135.7: Engineering * 135.5: Medical * 135.3: Command * 135.1: Science * 134.7: Operations * 134.5: ERT =====Cutting Comms===== Look at you! You're an antag and you found the Telecomms Area. Well you want to gain an advantage so why don't you take those pesky comms out. Here are some straightforward ways to do so, plus the effects of your actions. * Destroy the sub-space broadcaster. Those screams will be uttered, But not heard. * Deconstruct the processor. This makes the radio blast gibberish that nobody can comprehend. * Deconstruct the server and it's bus. Depending on which ones you knock out you can disable most of the command channels and such. Add Filtered Frequencies to the Hub in order to only allow people to speak on those frequencies. You can do this on any machine and department channels will also suffer from not being able to pass the filter.