Much about the issues listed in this guide is already known. However, most of that information is nebulous at best and is disseminated across the internet and any kind of consolidated knowledge base is severely lacking. My hope in creating this guide is to not only increase awareness and stimulate discussion of these bugs but also to create a central and comprehensive reference for other SpaceChem enthusiasts to use.

Most recent update: Nov. 5, 2013
The functionality described in this guide was tested/confirmed with SpaceChem version 1012.

In this guide, notably in the "How it Works" sections, I'll do my best to explain what is (in my opinion) the most probable explanation for why these bugs exist and how the internals of SpaceChem work based on my knowledge of computer science and the in-game experiments that I've run. Since I don't actually have access to the source code for the game, none of this is 100% certain, and I may be incorrect. That being said, it shouldn't prevent you from understanding enough to successfully and consistently recreate these bugs on your own.

If you already have a solid grasp of the game, you can skip this section.

Discussing bugs and how to exploit them in a solution is an advanced topic. You should obviously already have a solid understanding of the basic concepts of SpaceChem, how to play the game, what waldos are, what all the commands do, etc. There are a few other things that are not directly discussed in game, but are very important nonetheless to understand how these bugs work.

Before continuing make sure you understand these things:

Waldo Priority
When two waldos hit a command in the same cycle, red executes its command first, followed by blue.

Bonder Priority
Imagine that each bonding pad in a reactor is given a number from 1 to 8 (or however many bonders there are). This number is the bonder priority, and it defines what order in which bonds are created and broken. So lets assume that the higher the number, the higher the priority. When a waldo hits a bond command, SpaceChem will start with the highest priority bonder and attempt to bond with other bonding pads placed immediately to the right and below the initial one.
As a side note, it seems the current way of thinking is that a bonder will attempt to bond with all lower priority bonders before moving on to the next one. This is not true. I thought the same thing at first, in fact, but you can run simple experiments that contradict this assumption. I won't go into detail here, because it doesn't really matter. All you need to know is that bonder priority exists and can and will affect how a group of bonders will affect both the topology of the molecules being bonded and their selection priority, which is explained below.

Not a bug, but an important property of molecules that affects the outcome of other tricks/bugs.

When multiple molecules are potential targets of a single-cycle action, the one with highest priority will be chosen. This priority is generally defined by the order in which the molecule was input or referenced by a "modifying" command (bond, fuse, split, swap).

You can see this for yourself by conducting a very simple experiment.

1. Create a new production puzzle with two inputs. Or use a pre-existing one, if you prefer.
2. Pipe one input into the alpha input of a reactor, and the other into the beta input.
3. In the reactor, input both alpha and beta molecules and drop them on the same output zone.
4. Hit an output command for the zone the molecules are resting on, and note the order in which the molecules exit the reactor.

When a command is hit that targets a single molecule, SpaceChem will select the highest priority molecule that satisfies all the requirements of the command. For example, the requirements for an output command would be that the molecule is not held by any waldo and all constituent atoms are within the corresponding output zone. All molecules are given a priority from the moment they enter a reactor. In the above experiment, molecules are output in the same order they were input. So at the very least, we know they are prioritized by creation date. But there's a bit more to it. Any command that could potentially alter a molecule in some way will "reset" its priority, making it the lowest priority molecule in the reactor. Put another way, selection priority is a way of denoting, "least recently modified." Non-modifying commands, such as grab/drop and rotate, do not alter this priority.

This, then, begs the question: if I deconstruct a larger molecule, such as with a fission, swap, or a de-bond, which of the pieces is created first (and thus has the higher priority)? Let's start with de-bonding. First, it depends on the de-bond order of molecules - bonder pads will break individual bonds according to that pad's bonder priority. As soon as a broken bond breaks a molecule into two separate pieces, those pieces will have priority based on their position in the bond that was just broken: for horizontal bonds, the molecule attached to the left-most atom in the bond has higher priority. For vertical bonds, it's the molecule attached to the top-most atom.

Fission and swaps are a bit more abstruse (and in all honesty, you can skip this paragraph if you want). Since both can potentially break bonds, it's possible to create a slew of new molecules whose priority can vary depending on the topology of the atom being deconstructed. For the most part, the order for fission is left-top-middle-down-right (middle being the initial atom that was split) and swaps is left-right-top-down-middle. Again, it can vary, and I'm not interested in delving into the nitty-gritty details. AND, just to add a layer of complexity on the whole thing, the swapped atoms also have their priority reset, even if they originally had no bonds at all; both priorities are lower than the fragments they leave behind, and the swapped molecules are prioritized depending on which quantum tunnel they were initially over.


In this example, Boron enters the reactor first and thus is the first atom output, despite the fact that the Oxygen was the first object placed in the output zone. This also disproves the assumption that molecules are output in a top-down, left-right order.

• A molecule's priority is reset (set to the lowest priority in the reactor) whenever it undergoes any kind of alteration whatsoever, such as increasing a single bond to a double bond or vice versa. Swapped atoms will be reset as well.
  
• The order in which molecules are drawn on the screen seems to be related to selection priority... but I haven't quite figured out how. The general rule of thumb is the higher priority molecules are drawn first and therefore appear underneath other molecules, but I've also observed the inverse on occasion. It's not a very practical factoid in any case, so I haven't really looked into it too deeply.

The main idea behind this mechanism is that it acts like a queue[en.wikipedia.org]. For those of you less familiar with computer science, this is essentially a line, like, say, waiting in line for the movies. Queues are "first in, first out" structures, meaning you enter the back of the queue but leave from the front. In the context of SpaceChem, molecules do the same thing, although instead of taking a molecule straight from the front of the queue, we also check to see if it satisfies the requirements of the command, as stated earlier. If it does, we remove it, do whatever alteration we need to do, then place it in the back end of the queue. This effectively keeps the list sorted by the order in which it was modified.

As for the crazy orderings that occur when larger molecules are deconstructed, e.g., during a swap, I haven't seen any pattern that would indicate there is any kind of special mechanism behind it that would make the functionality nice and consistent... it wouldn't surprise me if it was just hard-coded that way.

AKA "Fusion-Input" "Fission-Output"

In the right situation you can get away with overlapping atoms so long as you resolve the conflict before SpaceChem attempts to detect collisions. In rarer cases you can avoid collisions altogether, just by being in the right spot.

There are two variants of this bug.

Variant A: In-Out
1. Move an atom or molecule over an square on the grid where we will potentially collide with another object. This future collision could be from an incoming input or fission product.
2. Have red trigger the command that would cause the collision: either an input or split command.
3. In the same cycle, have blue trigger a command that would remove one of the colliding objects from harm's way, such as an output or fusion command.

Note: it doesn't matter if either waldo is holding on to any of the atoms/molecules or not.

Variant B: Rotate-Out
1. Place a atom or molecule on the output zone.
2. Have one waldo (either color waldo will work) grab on to a different molecule that is at least 4 atoms long in one direction.
3. Have the waldo that is holding the 4+ long molecule rotate so that at the end of the rotate, an atom in the output zone will collide with one of the atoms in the rotating molecule. This collision must hit at atom in the rotating molecule that is at least 3 atoms away from the center of rotation.
4. At the immediate end of the rotate, have the other waldo hit an output command.

The outcome is that atoms will momentarily overlap during the cycle, but then a command is hit that resolves this conflict in some way so they aren't overlapping anymore. The reactor doesn't crash, even though there is technically a collision at some point during the run. The obvious implication of this is that collision detection runs only after the commands of both waldos have been processed.

But it gets better! Remember that for the rotate trick, the atom stick must be at least 4 atoms long. Why is this? The answer is that collision detection is calculated precisely 5 times each cycle! This means there is a collision check at the end of the cycle and at 4 additional times while the cycle is running. If the atom collides with our stick too closely to the pivot point (i.e., the waldo performing the rotate) it will detect a collision during one of the inter-cycle collision checks. If it's far enough away from the pivot point, the only detectable collision occurs at the end of the cycle, and by this time the output command has already been executed. See the "How it Works" section below for more details.


How cheaters fuse Helium and diatomic Hydrogen into Lithium Hydride.

Demonstation begins at 4:48, ends at 5:12.
A more pragmatic example: the rotate-out trick used in a puzzle during the 2012 SpaceChem tournament.
Video courtesy of GuavaMoment.

• This bug also plays a large role in particle smashing, but I've decided to keep them separate as particle smashing has additional bonder nuances of its own.
  
• The fusion-input trick with Hydrogen and Helium shown above works because of molecule selection priority discussed earlier - the left-most Hydrogen and Helium are both in position to fuse into the right-most Hydrogen, but the Helium is selected due to the fact that its selection priority is higher.
  
• To generalize my last point, selection priority can affect any outcome where two atoms are overlapping. If both atoms are eligible as a parameter for some command, such as fusion, than the atom with highest selection priority will be chosen.
  
• If you look at the first example where we use fusion to create Lithium Hydride, you'll notice that the blue waldo changes which atom that it's holding from the Helium to the Hydrogen underneath. This is because SpaceChem waldos recalculate what they are holding at the end of the fusion command. This is necessary in the event of a vanilla fusion or fission command, where the atom a waldo is holding can change. We will see a more interesting application of this in the Max Bonds bug.

So I made the claim that collision detection occurs 5 times per cycle. How do I know this? Take at look at the following diagram:


This picture details the results of an experiment that went like this: I created an 8-long atom stick, the longest you can create that fits in the reactor both horizontally and vertically, and I rotated it. I also placed a single atom on a square that would collide with the atom stick during its rotation. The filled-in squares on the diagram mark the outcomes of this test for all possible locations assuming that the stick starts in a horizontal position and is rotating clockwise around a pivot point in the lower right-hand corner (second square from the far right). The light green squares will work ONLY if you output before the end of the cycle, and the dark green squares are squares where you can place a single atom and no collisions are detected whatsoever, even if you don't output. (!) I've drawn red lines where the stick would be situated at each collision check.* Naturally, the spaces that overlap with these lines cause a reaction error, but the ones in between slip past unnoticed. Try this experiment for yourself - it's quite funny.

You could argue that this isn't a bug at all, but a rather a design decision made by the programmers. Performing collision detection can be computationally expensive because you have to compare the boundaries of every element with every other one in the reactor**, so instead it's reasonable to only do a small number of collision checks each cycle to prevent the game from slowing down too much. More importantly, even if we assumed infinite processing power, this way is more consistent than doing it once every frame, since the time between frames can vary based on playback speed and even external factors such as CPU speed. Still, most of the squares on the board are covered even with 5 checks total, and it's unlikely you'll have molecules giant enough for this to be a major problem in a typical puzzle.

* Yes, I know there are six lines instead of five. The horizontal line at the bottom would represent the 5th collision check at the end of the previous cycle.

** In the worst case, at least. It's possible to do better if you use a trick like binary space partitioning or quad trees, but that's beyond the scope of this article.

AKA "Input-Bond"

Note: This bug makes heavy use of selection priority and overlapping atoms, described in the sections above. If you don't understand how those concepts work, go read those sections now.

An extension of the delayed collision check seen in the above section. Particle smashing allows you to collide two molecules together and then bond them, forming a new molecule and annihilating one of the atoms in each pair of overlapping atoms.

1. Create a situation where you have a temporary overlap of atoms, any number is fine, of two or more molecules (see the section on collision detection if you don't understand how to do this). This is commonly done using an input, but can also be done with a rotate.
2. The two molecules must be located over at least one pair of bonding pads that will bond an atom in the first molecule to an atom in the second.
3. In the same cycle (before the game has a chance to attempt collision detection), hit a bond+ command.

There are a bunch of caveats that can cause this to fail, but if everything goes smoothly, the two molecules will bond themselves together with one of the original molecules overriding both the atoms and bonds of the other molecule with its own. The question is then, which molecule smashes over the other? The answer lies simply in the bonders themselves. If the two bonders are horizontal, the molecule attached to the atom on the left-most bonder will get smashed, and the molecule attached to the atom on the right-most bonder will come out on top. For vertical bonds, the upper atom's molecule will get smashed, overwritten by the lower. Another important detail is that the bond that combines the two molecules together occurs AFTER the molecules have been smashed, so if the surviving atoms hit the bond limit and fail to bond, the reactor will crash.


A textbook example of particle smashing. Since the Carbon molecule is the target of the bottom part of the bond, it overrides and smashes the Nitrogen atoms. Notice that the triple bond in the Nitrogen molecule is smashed as well and is overwritten with the single bond from the Carbon molecule.

These two examples demonstrate the fact that the bond occurs after the smash and that the left-most Oxygen from the first molecule is used for selection, not bonding. If the Oxygens bonded first, then we would expect both examples to smash successfully. Instead, in the right-hand example, the bond fails because the Carbon atom smashes over the Oxygen and already has its maximum of 4 bonds.

• Again, when we are bonding one of the atoms that is overlapping, we use selection priority to decide which molecule will be the target of our bond command. After selecting our molecules for both bonders, if the molecules are the same, we simply increase the bond (if we can) and no smash will occur. However, if we have the two different molecules, the atoms and bonds of both molecules are combined into a single molecule before we attempt to bond. This is the "smash" in particle smashing.
  
• A concrete example of the above point. Looking at the first example in the "In Action" section above, notice the importance of selection priority; if the Carbon molecule had higher priority, it would select two of its own Carbon atoms and do the bond without touching the Nitrogens, preventing a smash and crashing the reactor. In our case however, even though we use the Nitrogen atom to select the Nitrogen molecule for the bond, that atom is smashed and replaced with Carbon due to the fact that the Carbon is a member of the lower bonding pad. The Carbon atoms, since they survived the smash, are then bonded.
  
• As you might imagine, a smash only occurs if there is an overlap of atoms or bonds. Any non-overlapping atoms or bonds in either molecule will remain intact.

As far as I can tell, the basic flow of events is as follows:

Note that steps 3-6 is essentially a code block that is run for every bond when the bond command is hit. Also, the order of steps 5.a and 5.b doesn't matter, but both must be completed before step 6.

This chain of events seems to fit with the functionality I've seen in-game, and hopefully adequately explains all the caveats and quirks of this particular bug.

One last thing: had SpaceChem been written in a language like C++, this could potentially result in a memory leak, which would crash the program if it ran too long. SpaceChem is written in C#, so all the smashed and forgotten atoms and bonds are eventually garbage-collected, saving the game from an untimely demise. Phew!

AKA: "Bond-Rotate" "Bond-Sync"

In the right circumstances, it's possible to cause some weird behavior if you bond with one waldo while the other stalls for one or more cycles. By "weird" I mean molecule teleportation, telekinesis, and rotate/translate combo-maneuvers.

1. Both waldos must be holding on to something. If they are holding on to separate objects, the bond command in the next step must bond them together to form a single molecule.
2. The red waldo hits a command that would stall it's movement in some way; namely, a sync, input, output, or rotate command.
3. In the same cycle, blue hits a bond plus command. At least one bond attempt somewhere in the reactor must exceed it's bond limit and fail to bond. Also, this failed bond must be the LAST (i.e., lowest priority) bond attempted.

There are two major outcomes to this event. First is if red hits a sync, input, or output command. In this case, red will remain stalled but also in the "grabbed" state, thinking it is still holding on to the molecule. Blue, on the other hand, will also still be holding the molecule, but it free to move along it's track, dragging the molecule with it. The important thing to note is that as long as red is still stalled, this will not cause a reaction error. It's possible to drag the molecule completely out of red's grasp; however, once red starts to move again, it still thinks it is holding on to the molecule and will move it as you might expect - only now it will move it "telekinetically" without actually touching any of the atoms within.

The second case is when red hits a rotate command. Here, the molecule will rotate around the atom red was originally holding but it will also translate one space in the direction blue is moving. The effect is a bit startling. As soon as the rotate begins, the molecule will teleport one or two spaces off its current position and then perform the rotate/translate combination in one smooth motion. Why does it teleport like that? Basically, it's due to the order in which transformations are applied - a translation followed by a rotation does not necessarily yield the same result as a rotation followed by a translation. In this case, the initial position (the position after the teleport) is basically where the molecule would need to be if it were to do the translate first, then pivot around the red waldo (See the "How it Works" section below for more details).


By combining a translate and a rotate into a single action, we can move the Hydrogen atom from the input to the output in the upper-right hand corner one cycle faster than would otherwise be possible.

• The bond command is subject to bonder priority. Specifically, the "max bonds" failure must not just occur, it must be the last bond that is attempted. If the final bond succeeds, the reactor will crash.
  
• This one is actually really cool. The bond that fails does NOT have to be part of the molecule red/blue is holding! It just has to be the last bond attempted.
  
• Once red's stall/rotate is complete, if both waldos are still holding the molecule they must again adhere to the rules of the reactor: if they move in opposing directions, the reactor will crash.
  
• If a waldo has a telekinetic hold on the molecule (that is, it thinks it is holding it but no atom in the molecule is underneath the waldo) and you attempt to alter the atom in any way, such as fusion/fission, bond/de-bond - even if the bond fails and the molecule remains unchanged - the waldo will correct itself and automatically drop the molecule. Some things, like a failure to split, will not cause it to drop.
  
• Adding to the last point: If BOTH waldos have a telekinetic hold on a molecule, BOTH waldos will drop the molecule if it is altered.
  
• During a bond-rotate, I mentioned the molecule will teleport a couple spaces. When this occurs, it's still possible to overstep the reactor boundaries. If you do this, the reactor will crash.

The exact details are currently unknown. My best guess is that in the SpaceChem code, the bond command undergoes a series of checks that determines if the command is valid - such as if-elseif block - and if the last bond fails with a "max bond" it skips the code that checks for opposing movement. I should stress this is a rather primitive and overly-simplified guess - I suspect there is a more complicated mechanism in the code that is essentially mimicking this behavior.

Theory - something like this:

As for the teleport at the beginning of the bond-rotate, this is what I think is going on: the game calculates the final position for where all waldos/molecules would ultimately land at the end of the currently executing cycle, and to get a smooth animation leading up to that point, each frame we apply an inverse transformation to this final position to get the inter-cycle position, which is the one we see on the screen.**
In our case, we are applying two different transformations in a single cycle, a translate and a rotate, and remember that the order in which we perform these transformations matters. Again, we first calculate the final position by performing a rotate and then a translate. Now, to get the inter-cycle position, we do the inverse. These inverse transformations should be applied in the reverse order (so the final position is a rotate followed by translate, then the inter-frame position should be inverse translate followed by inverse rotate), but instead, the transformations are applied in the same order, rotate then translate, for both calculations. Thus, we suddenly arrive at a different starting point, which we see as the teleportation quirk. Since molecules normally are not supposed to have translations and rotations in the same cycle, and the only time they do is in this very specific corner-case, it's understandable how this would go unnoticed.


An demonstration of how transformation (T = translate, R = rotate) order can affect the final position of the molecule. SpaceChem applies all transformations in the same order, which ultimately produces the teleport glitch.

** To illustrate what I mean, take the following example: imagine we have a waldo on the board in the lower left-hand corner at the beginning of cycle 1. Let's call this position (0,0). Now say we are moving a long the track to the right, so each cycle we translate one to the right to get (1,0) for cycle 2, (2,0) for cycle 3, (3,0) for cycle 4, etc. To animate this we apply an inverse translate to the end position (1,0). So to animate forward from cycle 1 at (0,0) to cycle 2 at (1,0), the transition would like like this:
(1-1,0) => (1-.9,0) => (1-.8,0) => (1-.7,0) => etc.
which is equivalent to:
(0,0) => (.1,0) => (.2,0) => (.3,0) => etc.

"Random" inputs are always perfectly balanced every 12 inputs.

Not a bug, but a convenient property of the pseudo-random inputs in SpaceChem that can be used to your advantage.

Inputs are balanced automatically! Isn't that nice.

What this means is that if you have a random input that has a probability of, say, 50%, you are guaranteed to see exactly 50% within a set of 12 (so 6 in this case). Why is this useful? Balancing inputs like this eliminates the possibility of encountering fringe cases where you get too many or too little of a particular input, meaning you can determine the necessary length of pipes and create low-reactor solutions knowing that you won't run out of reactor space (The puzzle Reppe Chemistry from the 2013 SpaceChem tournament is a perfect example of this).

Demonstration begins at 12:15, ends at 13:55.
A demonstration and description of this property used in WildM's 2013 SpaceChem tournament. The goal here is to create a complex molecule from random inputs in a single reactor... without sensors.
Video courtesy of WildM.

• In fact, all of SpaceChem's random input percentages are multiples of 1/12.
  
• This property is true regardless of hardware or software platform.

This property is almost assuredly built into the game on purpose, and is not a function of the default random number generator (RNG) on various platforms. Controlling for 12 is useful from a developer and game design perspective for a variety of reasons. First of all, 12 is a rather nice, round number as it is divisible by 2, 3, and 4, allowing for a wide array of common and familiar percentage values. Also, as mentioned before, it eliminates the possibility of unruly inputs where, for example, an excess of a particular molecule could back up in a pipe and halt the solution. It also prevents the rare case where a nasty set of inputs actually makes the solution very difficult or even impossible to solve. It's also important, however, for another reason. Since a RNG may differ from machine to machine (unless the application includes a custom one (SpaceChem doesn't, as far as I can tell)) AND since players are submitting scores online and competing with friends, the scores need to be comparable in some way. Input balancing ensures that, at least for solutions that expect a specific input, scores are similar enough that the RNG won't screw you over big time.

I really have to thank all the people in the 2013 SpaceChem tournament for this - at the start of the tournament, I was completely naive to any and all of these tricks/bugs. So this guide almost certainly wouldn't exist if it weren't for that.

A quick shout-out and thanks to GuavaMoment and WildM, since I'm referencing their videos in this guide.

Another shout-out to cearn, whose mission viewer[www.coranac.com] was instrumental in finding some of these quirks, particularly the balanced inputs.

Thanks to ToughThought for thoroughly reading through and finding and notifying me of errors that would have otherwise gone unnoticed.

And of course a big thanks to the creators of SpaceChem!
http://www.zachtronicsindustries.com/