Change background image
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

They Should Be Removed: a Guide to Integrated Circuits (With Pictures)

Discussion in 'Tutorials & Information' started by BEAN, May 14, 2021.

  1. BEAN

    BEAN Bartender

    So you want to learn the most busted system in the game but don't want to dig through several different wikis, codebases, and deleted code from those codebases to piece together the scraps of how this weird shit works. You were too weak, and this has brought you to me.

    This system is not for the faint of heart; any halfway impressive circuit schematic will take you literal hours to assemble, especially as you start out. Each and every one is a labor of love, birthed by painstaking effort and banging your head against unintuitive, buggy bullshit until you become enlightened to the truth. Once you learn circuitry, it will ruin you for lesser systems. Beating your mortal enemy to death with your bare hands will leave you flaccid. "I could have done that better with circuits," you'll think. When you shoot a gun, you'll wish you were shooting five, simultaneously, without even aiming because the circuits could have done that for you. When you play security, you'll realize you could have just built a better officer. Every time you have to click to interact with a plant in hydroponics, you'll be blinded by rage. Your circuits could have done that work for you. You could be working on circuits right now.

    Eventually, you'll find yourself cold and alone in misc research, with nothing to keep you warm but your printer and a .txt full of schematics. But that's okay. That's fine.

    You don't need other people.
    Your circuits can do anything.

    Welcome to integrated circuitry, the most degenerate art known to spaceman. After many nerfs, the system is still gamebreakingly powerful, and its existence is ultimately unhealthy for game balance. The sheer versatility of it, however, enables a lot of Cool Shit (tm). My personal opinion is that it should be removed, and it probably will be when one of you fucks start printing terminator drones to valid hunt every single round. Hopefully they ban you instead. Until then, circuit responsibly. Let's begin.

    First, you need a circuit printer. Load it with STEEL. Do fabrications until you can get the circuit printer upgrade disk, and the circuit printer clone disk. If you play robotics and you have science slaves, ask them for the disk and just wait. The printer is nigh-unusable without the upgrade disk, and the upgrade disk only exists to force scientists to do their chores. Upgrade your printer, and you're ready. Use it in-hand to open up the menu:

    Take a minute to browse your options. Pay special attention to the REAGENT, OUTPUT, and MANIPULATION menus. For the most part, these are your gateway to the outside world. The other stuff controls the logic that enables these parts to function. Here's how it goes:

    You print an assembly. Its size determines how much metal it costs, as well as how large it is and how much it can hold. You print a bunch of parts, and insert them into the assembly until it can execute your design. Then you wire it all together with the circuit wirer, and insert static values with the circuit debugger. You save the schematic with your circuit analyzer. These three tools are found next to every printer spawn, but you can make more for free under the tools menu. There's also a paint tool that lets you recolor your assemblies, but no one cares about that.

    Circuit design is all about efficiency. You want to use the smallest assembly possible for your purposes, and you want to use the space it gives you as efficiently as possible. This isn't something you have to worry about as you learn the basics, but do keep it mind.

    When you examine an assembly or part, a window will pop up. For the assembly, it's a list of all the parts inside it, in the order it was inserted. Clicking on a part will take you to the part. Examining the part will show you something like this:


    This is a small memory circuit. The big red text is mine. No-one actually uses this particular part, since memory chips and constants are better. We're going to use it as a demonstration piece since it has multiple inputs and outputs. Hold your circuit wirer, because it's time to link things up. By the way, put it in an assembly or it won't work. Assembly needs a battery or it won't work.

    The blue text at the top handles data.
    Blue shit can only link to blue shit.
    The blue shit on the left is your input.
    Left shit can only link to right shit.
    The blue shit on the right is your output.
    Right shit can only link to left shit.

    The red text at the bottom handles activity.
    Red shit can only link to red shit.
    The red shit at the top is labeled pulse in.
    Pulse ins can only be linked to pulse outs.
    The red shit at the bottom is labeled pulse out.
    Pulse outs can only be linked to pulse ins.


    Let's say you take your wirer. You click Input 1, on the top left. Then you click output 1, on the top right. This is linking an input with an output. You can click it the other way around, top right and then top left, and it'll do the same exact thing. The order you link in doesn't matter, and likewise for pulse in/outs. The text up top is repetitive for emphasis because you're going to ignore it and link input 1 to input 2, and then get confused as to why it doesn't work.

    When the mem circuit receives a pulse, it performs the task that it'd been coded to do. This is usually pretty obvious once you understand how things work, but for the mem circuit it takes the input and pushes it to corresponding output.

    This means anything written in input 1 will be written to output 1. Output 1 will then push whatever's written in it through all attached links. If you use your debugger to write a '1' to input 1, then use your debugger to pulse the SET pin, it will write 1 to the output. Then the output will be pushed to whatever it's linked to, which happens to be its own input. What happens here is:

    You write '1' to input 1 -> pulse set in -> Input 1 writes '1' to output 1 -> output 1 is linked to input 1, so output 1 writes '1' to input 1. Input 1 already had a 1 in it, which means nothing changes.

    Great! Now use your wiring tool in hand to turn it red. Look at input or output 1. Click it, and then click the opposite. This breaks the link. You can also click the text left of the little @ underneath, since it's a shortcut. This becomes very relevant when wiring between parts instead of wiring the same part, since it means you don't have to flip back pages just to break a link.

    Let's try doing some shit that works. Your mem circuit should now have no links. Link output 1 to input *2.* Write the letter 'a' to input 1 with your debugger.

    You should have one link. Input 1 is 'a'. Everything else should be null except for the '1' in output 1 if you followed along earlier. Swap to your debugger, and click the pulse in.

    If you did not fuck it up, input 1, input 2, output 1, and output 2 should all read 'a' now. This is how circuit logic works one hundred percent of the time (unless the admins turn it off).

    There's just one more area to cover in terms of logic, and that's types. You see the <ANY> to the left of your inputs and outputs? That's the type. Let's look at a color converter.

    When this thing receives a pulse, it will take those three numbers on the left there, and turn it into a <COLOR> on the right. You can link the output to an advanced light to get colored flashlights. If you take your debugger, set it to STRING, and write in something like 'RED' and click the output, you'll notice it won't write. This is because your debugger can only be used to write numbers, strings, and <REF>s. Remember how I said earlier how blue shit can only link to blue shit? And how left blue shit can only link to right blue shit, and vice versa? <TYPE>s can only write to identical <TYPE>s. We're not writing Python here, people.

    That's it, though. That's circuit logic in a nutshell. Make sure everything matches, and you're going to have a good time.

    Here's the code for a shitty color flashlight. The light is green. Open your printer, click 'load program' and paste this in. Then click the print assembly button right next to it. If you did not fuck this up, you should receive one (1) shitty flashlight. Press it again to receive a second one.

    {"assembly":{"type":"type-a electronic assembly"},"components":[{"type":"button"},{"type":"hsv to hexadecimal","inputs":[[1,0,100],[2,0,255],[3,0,127]]},{"type":"advanced light","inputs":[[1,0,"#2A7F00"],[2,0,2]]}],"wires":[[[1,"A",1],[2,"A",1]],[[2,"O",1],[3,"I",1]],[[2,"A",2],[3,"A",1]]]}

    When you examine it or use it in hand, a second window with "button: Press" on it should pop up. If you click the blue 'Press,' the piece of shit should light up. If it doesn't then you forgot the batteries, dumbass. Take a look at the logic inside.

    The button is linked to the HSV to hexadecimal converter (Numbers to color). The inputs for the HSV are random numbers I pulled out of my ass and dumped in with the debugger. The HSV's output writes to the advanced light's color input, and when it receives a pulse it passes that pulse on down to the advanced light's 'toggle light' input. This turns the flashlight on and off.

    Coders already extracted the fun from the advanced light's brightness value, so as long as it's not 0 it doesn't really do anything. We used to be able to make cool big flashlights, but someone decided this was overpowered. Now it's a piece of shit.

    Since the HSV's values are static, it essentially serves only as a conduit for passing the button's pulse down to the light. Try adding and linking some numpads that allow you to dynamically modify the HSV's values so you can go from a green flashlight to like, a red one or some shit.

    Let's cover the assembly menus and we'll call it for this post.

    If you click the [ # ] you can change the part's order in the list. If you click the R, it will let you rename the part. If I renamed the button to 'shit,' then when you used it in hand you wouldn't see a button: Press. You'd see a Shit: Press. The S would be capitalized since it autocapitalizes. The [-] removes the part. The part itself on the far right opens up the part so you can wire and write into it.

    And the [Rename] at the top lets you rename your whole assembly.

    That's it for this post. It's a lot of baby handholding shit but it's all you need to know to start experimenting and succeed on your own. Understanding the logic is the most important thing.

    Possible future posts if people are interested / I feel like writing:
    Circuit idiosyncracies the weird shit going on with saving and printing * Done, see next post.
    Command flow, tidiness
    Interesting parts and functions of those parts
    Drone and circuit showcase
    Circuit ethics
    Antag shenanigans
    Lists: how do they work?
    Reagents, or 'what the fuck is push ref and why does nothing work?'
    The removed interactor circuit, and changes I'd like to see
    Last edited: May 15, 2021
    YodaDoge and Juxtaposed like this.
  2. BEAN

    BEAN Bartender

    Part 2, kids.

    Today we're going to cover circuit idiosyncrasies. This will be written at a higher level, as I'm going to assume you've read and understood the above post. We're going to be taking a more in-depth look at the system and at things that should work but don't. Most of these things are not documented anywhere, and you only run into them through trial and error.

    * Filter circuit pins are reversed, so when it finds something, it pulses 'not found' and when it finds something it pulses 'found.' Wire accordingly.
    * Thrower circuits fall one tile short when throwing at a diagonal. You have to manually build a compensatory system (If relatively, X > 0 and Y > 0 then that means we're throwing to the northeast, so an adder circuit increases X and Y by +1. If X > 1 and Y < 0 then we're throwing southeast, so an adder increases X by 1 and decreases Y by 1 etc). A diagonal-functional thrower requires an unholy shit-ton of logic gating.
    * Text to speech circuits shit themselves when they see apostrophes. If you want something to broadcast to everyone in the area, a large screen is the superior choice. It has a shorter activation delay and lower costs all around, too.
    * Camera circuits don't save properly, so you have to turn them on yourself every time. Use a constant set to 1 and your choice of a starter to push it. Cam circuits need to be turned on and off to update the name. Multiple cam circuits sharing the same name will shit the bed.
    * If the circuit load on the server increases past a certain point, a killswitch activates that makes it so no circuits work for the rest of the round. I'm not sure if this is an admin manually shutting us down, a coded failsafe, or the circuit controller crashing from the load. I managed to get this to happen when I built a swarm of automated drones that followed me.
    * The belt clip assembly lets you wear it on your belt. The PDA assembly lets you wear it in your PDA slot as well as your belt.
    * The augment assembly is both an augment and a GUN, which means you can activate gun circuits and throwers with it in-hand.
    * Augments can only be properly installed in the hands, but if your circuit is fully voice activated or something, it doesn't necessarily need to be properly installed...
    * Basic pathfinder is what most drones use. The advanced one is for massive, pre-set routes. It """works,""" but it's an unreliable piece of shit and I think all fields have to be filled before it'll work.
    * Gun circuits spawn projectiles on the tile they should be shooting into. If you're standing next to someone and fire, the laser will spawn on top of them and move into the next tile of your chosen trajectory. This means you cannot shoot anyone from point-blank, but your projectiles can jump through walls. You can build some cool traps this way, but we'd all be happier if someone fixed this shit.
    * Power transmission circuits exclude guns. This is not documented anywhere, but it is hardcoded. You can't charge guns with power transmission circuits. Can charge batons though. Shit sucks.
    * The ranged sensor is the only circuit that can process things it can't directly see. You can use it with a camera.
    * Smokers require a minimum of 10u reagents to make smoke. I don't think this is documented.
    * Previously, advanced signalers saved the codes properly but failed to work unless you re-input them, either manually or with a constant. This might have actually been fixed, but all my circuits have the failsafe built in so I haven't bothered to check. Just know if your signaler is eating shit you probably have to reinput the codes.
    * Many things that should work simultaneously do not. For example, you can only have two throwers throw over a .1s period. The others jam and fail. Likewise, only one gun may fire during a .1s period. This is not documented anywhere. It means you can't have a sick shotgun laser.
    * Circuit projectiles work off the old accuracy system, where you lose roughly 15% to-hit per tile and there's a full like, 30% chance to automiss no matter what.
    * Push ref. We're going to have a special section for push ref right here.

    Many reagent circuits have an incoming pin called 'push ref.' What this does is cause the 'self ref' output to write. A <REF> is a reference to an object in the game. If you use your debugger and select REF, and then click yourself, you'll be able to copy and write a reference to yourself. REFs do not work between rounds, so you have to build in a system that can re-acquire the refs you want or settle for tagging things with your debugger like a hack.

    Suppose you try to use a reagent funnel. What if you have multiple reagent storages in the same assembly? The funnel doesn't know where it should push the liquids. Therefore, you have to push a reference of the part you want the fluids to travel to into the funnel's target ref input so it knows where the juice goes.

    This seems cumbersome at first, but gives you unparalleled power. For example, you can use a single pump to move things between multiple beakers as long as you push the right refs and gate things in a clever way. This saves a massive amount of space, which can be better spent on other things, like more juice tanks.

    Saving and loading circuits:
    When you save/load a circuit, parts and their links are loaded in from first to last.
    Let's say you have a button. This button's output is linked to a constant, and then a screen. When you push the button, it pulses the constant, and then the screen.

    However, if the constant is, say, part 1 and the screen is part 2 and the button is part 3, or maybe if the constant is part 1, and the button is 2, and the screen is 3, this royally fucks up the loading order. When you load, things might get gnarly, with the button pulsing the screen before the constant. Part order matters. Be vigilant, save often, and print-and-test to make sure it works after you save. If you have something like a microphone and someone says the wrong character (Probably something like ' " [ ]), it can also fuck the loading process.
    Last edited: May 15, 2021
  3. BEAN

    BEAN Bartender

    Howdy, kids. Part 3 here. I forgot about the game and I don't feel like playing, so there will be no pictures this time.

    Let's talk about complex projects, good development habits, and how to identify broken shit so you can fix it. We'll use a drone as an example. We're not going over a step-by-step on how to make one exactly. Drones are mobile murder platforms, and by far the most complex circuits to develop. They are the pinnacle of circuitry, so figuring out how to build a good one is an exercise best left to the reader.

    Don't make a drone as your first project. Even if you pull it off, it will be complete garbage. Drones can be divided into subsystems, which you will inadvertently develop on your own as you experiment with simpler contraptions. The design for the gun you made can be copied and mapped in, direct input converted to remote input. The fundamentals of that remote communicator you made for radio-free chatting with explo will find a handy home in your drone. It has to be stripped down a little, of course. You couldn't fit that extra gun if it weren't.

    Everything you build will eventually be of use for mounting on a drone. As you experiment, you'll find more efficient ways to build things. Then you can fit more guns. It's a beautiful process.

    Let's look at the design process.

    A drone is a two-part creature. You need a remote, and then you need the drone itself. To communicate, the controller needs a signaler. A signaler needs information to send. The info needs an interface to send it with. More intuitively, you need buttons to control your drone and make it do shit.

    From this, you gather that you need buttons, you need data, and you need a signaler. If you're new, you may even want two signalers, or three, or four. This means you'll likely need to endure the shame of moving your assembly size up from a small to a medium. It is possible to run a drone off a single signaler, and all of mine have been single-signaler from the start-- multi-sigs kept bugging out when I'd just started, so I had to adapt.

    For now, just focus on making your designs work. Necessity is the mother of invention. You'll figure out a way to cram more guns in when you're good and ready.

    You want your drone to shit lasers, to move around, talk to people and receive their messages. You want a lot of stuff, but hold your horses. This is a fundamental rule to any large project: work on one feature at a time. Let's say you want your drone to move first. You don't get interested in having it transmit messages halfway through and stick a bunch of parts in. You work exclusively on getting that remote to send information to your drone that will cause it to move, and nothing else. Circuit logic is linear. If you think in circles, you will go in circles.

    To get a drone to move, you want a remote sensor, which picks up a reference to anything you click on while the remote is in hand. You want to transmit that ref to the drone, but the signaler only sends text, not refs. Then you look at converters: a reference encoder turns a ref into text. A decoder turns appropriate text back into a ref. Remote sensor finds a ref, passes it onto the encoder, which encodes and passes it to the signaler, which sends to the drone's signaler. The drone signaler passes the text to a ref decoder, which turns the code into a ref and passes it onto your BASIC pathfinder circuit, not the advanced buggy piece of shit one, which passes the corresponding output direction into your locomotion circuit.

    With that done, you click with your remote and your drone moves a single tile towards its destination. Success. It doesn't work the way we want it to, though. We want it to move to its destination with one click, not move forward a tile with one click. What's the problem?

    The locomotion circuit only receives one pulse, so it only works once, so it only moves once. We get a ticker under the time menu, which pulses constantly once turned on. We link it to the locomotion circuit, since it just needs more pulses to move, right?

    Your drone takes off. It moves in the direction of the target, and at first it looks like a success. Then it keeps moving, and moving, and moving until it collides and deadlocks itself into a corner. You check the locomotion circuit. It's receiving directions from the pathfinder, so that works. It's moving, so it's receiving pulses. Then there must be something wrong with the directions: the pathfinder only pulses once, so it outputs one direction and your drone keeps trying to move towards that one direction, forever. Woops.

    We unwire the ticker from the locomotion circuit and wire it into the pathfinder. Now every .1 seconds, the pathfinder calculates the next direction to the reference you sent, passes it on to the locomotion, and the locomotion moves in that direction. However, you discover that when you click someone, your drone constantly runs in circles around them. Why is that?

    After some fiddling, you switch the 'ignore obstacles' pin on your pathfinder to true. Now the drone passes right under people. Cool. Problem solved. That's the debug process: when something doesn't work, identify where the break is. Think about each of the parts in the chain and what those parts do. Look at them, and see if their inputs or outputs are incorrect if you can't guess. If you can identify which part doesn't work, that's where your error is. If you haven't been testing frequently, a chain may have more than one error. Fix it in the order of emergence. Very often it's something stupid, like trying to pass a string that says "1" into a number pin.

    From here you try to add a light switch, and you link it to the same signaler. When you send the light command, you notice it sometimes shits out your drone movement. This is because it's passing a non-ref into your ref decoder, which processes into a null direction for your movement chain. You could ignore it. It's easy enough since it's just a lightswitch. Your drone only halts if you try to flip the lights while it's moving, and who does that?

    Sometimes jank is the most efficient route. Bug fixes cost space and complexity. If it doesn't hurt, why waste space fixing it? This is one of those times where it actually will hurt, though. As you add more commands, your inability to separate them will absolutely fuck up everything. So now you have a choice: you can improve your control schema, or you can add more signalers.

    There's no shame in using two signalers, folks. The only shame is settling for them. If you settle, your drone will always be 8 complexity shittier than mine, and I'll never let you live it down. It'll actually be a lot worse than just 8, since if you settled it means you suck.

    Just focus on making it work first. Elegant design comes as you try other parts, like demuxes and tables. As you discover the possibilities of new parts, you'll naturally just think, 'Oh, I could have done it like this and it would have been so much less shitty.'

    And that's the primer on complex design.

    For those interested in drone design, prefixing a code via concatenator and then using the string splitter means each signal can come with a code as well as a message. The code can be used to determine what gets pulsed. Single-signaler drone. Use with tables and pulse demuxes for maximum efficiency.
    YodaDoge likes this.