[Guide] Logic Gates: Order of Operations, Smoke and how to prevent it

Niranufoti

Plantera
Since there has seemingly been some confusion about when logic gates emit smoke, and more generally, about how they interact and when they interact the way they're supposed to, I want to clarify some things. Some of this has been said by other people in other places (shoutout to @Statue of Libroty), I was just the first to fact-check and compile all of it into a big post. This is meant essentially as a translation of Terraria's code into human language that anyone can refer to as needed, as well as a guide to solve the most common problems.
5yXTa2f.png
vSbXe2R.png
Order of Operations
Before we jump into things, I want to issue a huge "Thank you!"-scream for @Yoraiz0r, who was kind enough to answer my questions and confirm my findings. Without him, pretty much every sentence in this post would contain an "apparently", "it seems" or "as far as I can tell". You're the best!

Now, by "order of operations", I'm not talking about "Please email my dad a shark" mathematical operations, but about the growing complexity of Terraria's wiring. In the beginning, most devices were rather simple - dart traps, doors, etc. - with pumps being the most complex for relying on two devices working together. Then, more wire colors as well as teleporters were added, increasing the complexity. With 1.3.1, we now have logic gates - devices that themselves emit signals the tick they're activated, leading to an arbitrarily large number of steps within a single game tick.

In this post, I'll occasionally be using terminology from Terraria's code - I'll underline those words to make modders' lives easier.
vSbXe2R.png
OGtPemF.png
Tripping Wires
When a signal is emitted from a tile - a switch was hit, a pressure plate stepped on, a timer ticked; or for short: the wire is tripped - a number of things happen in succession:
  • The four wire colors - red, blue, green and yellow, in that order - are hit one after the other.
    • For each color, the signal travels through wires of that color, activating devices along the way - "simple" devices (traps, doors, lights, actuators) are triggered directly; pumps, teleporters and logic gate lamps are marked down to be handled seperately (non-faulty lamps are also toggled though).
    • Afterwards, pumps connected by that wire color are handled in pairs - the first inlet pump that was hit pumps to the first outlet pump, the second inlet to the second outlet etc.
  • When all four wire colors have finished, teleporters are handled, again in order of wire colors (red, blue, green, yellow). The activated teleporters are always the one that was hit first and the one that was hit last.
  • Lastly, the (unobtainable) pixel boxes and any logic gates are handled.
A little demonstration of how the order of wire colors can be used with teleporters has been supplied by @ZeroGravitas:
Here, the teleporters are activated in pairs from left to right each tick, carrying the player all the way to the right on the first pulse and one teleporter to the left on subsequent pulses.
OGtPemF.png
pZXdNI6.png
Logic Gates
Simply speaking, if there are logic gates involved, the game alternates between two steps: Hitting wires and checking logic gates.
  • For each lamp that was hit, the corresponding logic gate is evaluated (if there are faulty lamps involved, that's handled differently).
    If the gate is supposed to pulse, but already has, a puff of smoke is emitted.
  • Then, for each gate that changed state (or faulty gate that's supposed to pulse), if that gate hasn't pulsed during this iteration, it does so now (tripping its output wires, cf. above).
    Checking logic gates will be skipped in that case to keep things more orderly.
  • This is repeated as long as the tripped wires hit more logic gate lamps.
Take note of how I wrote "iteration" instead of "tick". This is because after fully finishing, the list of gates that can't pulse anymore is cleared, so if multiple switches are activated on the same tick (e.g. with traps and teal pressure pads), they are treated completely independently, even capable of triggering the same logic gate multiple times during a single tick.
pZXdNI6.png
e8Fdi1J.png
Smoke and missing pulses
As stated above, smoke occurs when a gate is supposed to pulse multiple times during a single iteration. This is to prevent freezing the game with an infinite loop by hooking a wire up to one of its inputs. While this limitation can be used for simple reset mechanisms, it causes collateral damage in the form of robbing us of pulses we would have needed, especially when working with devices such as lights, doors or actuators that have two states - if the gate switches on and off again, but sends only one pulse, the door is opened, but not closed again - if a logic gate lamp is used instead of a door, this can possibly cause quite a mess.
The only case where this problem can occur is if a single switch (or other signal source) activates multiple chains of logic gates that lead together again somewhere down the road. Because of the way the gates are processed, it is possible that different signals reach a single gate at different times - in the same tick, but after a different number of steps.
In order to solve this problem, one has to make sure that all possible signals reach a specific gate at the same time. To achieve this, signals can be delayed by any number of calculation steps using any gate with just a single input (a diode). Toggling this input will toggle the whole gate, so the signal will pass through unscathed, except it's delayed by one step of calculation. As an additional bonus, the wire color can be changed as needed.
e8Fdi1J.png
5yXTa2f.png
That's all for now; I hope it's helpful. I plan on updating and expanding this with more information as time goes on and new features are added, as well as possibly going into more detail with full information for engineers and modders alike (unless the team complains about me using identifiers from their code). If you have any feedback, questions or feel like there's something I should add to this or word differently or whatever, just tell me.
 
Last edited:
You're welcome!
In general, if you have any theoretical questions that might be answered by poking around in the source, you can just ask me here (or just tag me).
 
Thanks for this - it's very useful!

I have particular interest in this, given what I just built and posted recently:

The only case where this problem can occur is if a single switch (or other signal source) activates multiple chains of logic gates that lead together again somewhere down the road. Because of the way the gates are processed, it is possible that different signals reach a single gate at different times - in the same tick, but after a different number of steps.
In order to solve this problem, one has to make sure that all possible signals reach a specific gate at the same time. To achieve this, signals can be delayed by any number of calculation steps using any gate with just a single input (a diode). Toggling this input will toggle the whole gate, so the signal will pass through unscathed, except it's delayed by one step of calculation. As an additional bonus, the wire color can be changed as needed.

The build in question is here:

http://forums.terraria.org/index.ph...e-decimal-display-with-a-single-keypad.44028/

I ran into the exact same problem you described: an AND gate would receive a signal from a transistor on the left to shut it off, and another signal from a transistor on the right to turn it on. This would happen if two of the same digit were input consecutively. Instead of generating two pulses, one would be lost in a puff of smoke, breaking the system. My solution was to use a hoik track to send the signals to the transistors in intervals. This isn't an issue for the build since the "slowness" of the hoik track is masked by the speed of the inputs by a human hand, but from what you say I should be able to recover that lost input and hook up the transistors with just a single wire.
 
I ran into the exact same problem you described: an AND gate would receive a signal from a transistor on the left to shut it off, and another signal from a transistor on the right to turn it on. This would happen if two of the same digit were input consecutively. Instead of generating two pulses, one would be lost in a puff of smoke, breaking the system. My solution was to use a hoik track to send the signals to the transistors in intervals. This isn't an issue for the build since the "slowness" of the hoik track is masked by the speed of the inputs by a human hand, but from what you say I should be able to recover that lost input and hook up the transistors with just a single wire.
I think if the transistors were all triggered in the exact same step, it should work, as the gates inbetween won't switch at all - the lamps will turn off and on again between two CheckLogicGates steps.
This won't solve the clear function though, but you could still have that happen within one tick by using four seperate pressure plates triggered at the same tick - they'll be seen as completely seperate.

EDIT: Or just add an additional transistor per row per column, so that there's always one for "clear" and one for "copy to the left". Inputting a new digit activates both of them, the clear switch just the clearers.
 
Last edited:
I used the information I learned from this awesome thread to start my own thread on a 4-bit Full adder I created using logic gates. The original one I designed on the day of the update that brought the logic gates was having the steam effect, but after reading this I was able to get rid of the steam effect and make the 4 bit version of it.
 
Oh how the Order of Activation is screwy with my Warp Room build...

Pressure Plate > Red Wire Wire > Faulty Lamp > Logic Gate > Blue Wire > Green Wire > Yellow Wire > Teleporter...

All in one Tick.

If it wasn't for OoA on Wires by color, it'd never work right though. XD
Your information here and in my topic was and will continue to be invaluable.
 
Oh how the Order of Activation is screwy with my Warp Room build...

Pressure Plate > Red Wire Wire > Faulty Lamp > Logic Gate > Blue Wire > Green Wire > Yellow Wire > Teleporter...

All in one Tick.

If it wasn't for OoA on Wires by color, it'd never work right though. XD
Your information here and in my topic was and will continue to be invaluable.
Well, knowing your enemy is half the battle. When chaining multiple teleporters (or pumps, for that matter), you can easily harness the power of different wire colors in order to save logic gates (or actual delaying devices).

That said, I'm always glad to help :)
 
First of all, thank you(both) for this information, it is invaluable. But I do have few questions(and a plea for help?).
Is it correct that when lamps are being 'tripped', logic gates below them are queued for evaluation in the order that they were tripped(based on wire length and wire priority)? I've done some tests and it seemed correct, but then I made some changes to my testing rig trying to test if weighted pressure plates acted like an interrupt or a queued event and it changed the behavior in repeatable, but yet unexplained(well, at least I haven't been able to explain it) way.

Attachments 1 and 2(ones without a weighted pressure plate) are how I tested evaluation order. It predictably and reliably teleports you from top teleporter down, and then to the right, no matter which switch was used.

But then if you add a weighted pressure plate like in attachment 3(or in a middle tile of middle teleporter), and from what I can see, it's not connected to any wires, rig's behavior changes in an interesting way.

Lower switch now causes backteleportation(I've previously found same(or only similar?) effect in http://forums.terraria.org/index.ph...ailed-info-and-links.43742/page-4#post-984379) to the top teleporter. Lower teleporters are activated based on the torches, but I'm not inside teleportation zone anymore when that happens.

Now this is where it gets interesting. The upper switch teleports me to the middle, but lower teleporters are also activated, based on torches. But since there are no teleportation particles there(which are there even when I backteleport), it leads me to believe that evaluation order was changed, and they get activated while I'm still on the top teleporter.

Why this is happening, with an unconnected weighted pressure plate, and why does a direct activation with a switch differ from an activation through a logic gate?
 

Attachments

  • Capture 2016-05-30 18_48_55.png
    Capture 2016-05-30 18_48_55.png
    10.7 KB · Views: 388
  • Capture 2016-05-30 18_49_03.png
    Capture 2016-05-30 18_49_03.png
    11.9 KB · Views: 358
  • Capture 2016-05-30 18_49_33.png
    Capture 2016-05-30 18_49_33.png
    11.9 KB · Views: 337
Last edited:
Why this is happening, with an unconnected weighted pressure plate, and why does a direct activation with a switch differ from an activation through a logic gate?
I haven't yet been able to figure out where weighted pressure plates are handled, but since they are apparently activated right after teleporting, this should be a rather good theory.
Fact: Triggering a weighted pressure plate prevents player teleportation for one iteration. The value controlling this is reset at the the end of the method evaluating all logic gates (the blue paragraph above). However, when triggering the weighted pressure plate (by being teleported away), the logic gate method is already running. When the weighted pressure plate is activated, that is detected, so the main body of the method isn't actually run, thus the value preventing player teleportation isn't reset, thus the player can't be teleported, even though the pressure plate was in no way wired up to anything.
I hope this makes sense.
 
Fact: Triggering a weighted pressure plate prevents player teleportation for one iteration. The value controlling this is reset at the the end of the method evaluating all logic gates (the blue paragraph above). However, when triggering the weighted pressure plate (by being teleported away), the logic gate method is already running. When the weighted pressure plate is activated, that is detected, so the main body of the method isn't actually run, thus the value preventing player teleportation isn't reset, thus the player can't be teleported, even though the pressure plate was in no way wired up to anything.
I hope this makes sense.
I can't say that I understand it completely, but if I assume it to be true, I can make enough leaps of logic to make that work in my head. I'll need to make some tests and thinking, but this might be enough information.
Thank you
 
Back
Top Bottom