Description: markdown enabled; shift+enter when done.
Fill this in with stuff.
If you have a logic gate selected in the field above, clicking on this will convert it to this kind of logic gate.
Dragging this button into the field above will create a new logic gate of this type.
You also create logic gates by putting your mouse cursor where you want the new gate to be and pressing 'a' (and), 'A' (nand), 'o' (or), 'O' (nor), 'x' (xor) or 'X' (xnor).
Stop/pause the simulation. 'g' is the keyboard shortcut to start the simulator, 's' pauses it.
Advance the simulation by one tick. 'n' is the keyboard shortcut.
Not active unless the simulation is paused!
"Inputs" represents switches, buttons, and sensors in the game.
If you have an input selected in the field above, clicking on this (or pressing space) will toggle the input on/off.
Dragging this button into the field above will create a new input. You can also create an input by putting your mouse at the place where you want it and pressing 'i'.
Inputs can be toggled by Ctrl+Clicking on them.
A 9-tick timer - currently that's the only kind of timer supported.
Dragging this into the field above will create a new timer. You can also create a timer by putting your mouse at the place where you want it and pressing 't'.
Delete the selected input, timer, or logic gate. (DEL or BACKSPACE are keyboard shortcuts.)
Simulate what happens when reload the game or game chunk. '4' is the keyboard shortcut.
"Paint" the selected logic gate or input. In the game, this causes the current state to be the state that it will reload with. 'p' is the keyboard shortcut.
Note that any alteration to a control (e.g. making a connection, changing its logic type, etc) will update the saved state, just as it does in the game.
Simulates putting the build on a lift - all states are wiped.
The keyboard shortcut is 'l'.
Simulates taking the build off of a lift - this causes the current state of the circuit to become the saved state.
Reloading will cause it to return to this state.
The keyboard shortcut is SHIFT+L.
Create a sharable link to the current design and copy it to your clipboard.
Note that really big designs might not be sharable like this because of URL length restrictions.
Load a previously saved JSON copy of a design from a file on your machine.
Save a JSON copy of a design to a file on your machine.
Load a blueprint from the game into the session. This will wipe your current design!
Saves the design as a blueprint that can be read by Scrap Mechanic.
Description: markdown enabled; shift+enter when done.
Videos:
There's a context menu that allows you to tweak each control and change the number of ticks in a timer.
The foreground and background colors are like what they are in the game - a white foreground on a light blue background indicates that the gate or input is currently "On" and a black foreground on a grey background means "Off".
The color of the arrows shows the state of the source of the connection at last tick. This will only really matter when the simulation is paused, as only then are you likely to be in a place where, say, both of the inputs to an "And" gate are true and yet the and gate itself is not true. This is because computation of state is not instantaneous. Every "tick" (1/40th of a second in the game), the state of each logic gate is evaluated. An easy way to think about it is to divide each "tick" into two - one step where you figure out what all the new values should be based on the current values, and in the next half of the tick copy that computed value into the real value of the gate. To help visualize that, the arrows are drawn with different colors - a dark blue arrow means that, when the tick started, the source of the connection was true and a teal colored arrow means it was false. So, for example, you can toggle an input and you'll notice that none of the connected gates changes at all and neither do the connection colors. But after you advance the simulation by one tick, you'll see your change start to impact your circuit.
Finally, on switches and logic gates, you'll see a triangle in the upper right corner that's either filled in or not. This reflects the Saved State.
It seems logical that if you exited and reloaded scrap mechanic, your creation would be as you left it, but the reality is very subtly different for switches and logic gates. They will return to the condition they were in when any of these events happen to the logic gate or switch:
This may seem hard to believe, so you should verify it for yourself: (This may be worth doing, as future versions of the game might fix this!)
It's only logic gates and switches that suffer from this problem! Timers, pistons, controllers and all those things are not. So if, instead of using a light in the above, you used a piston, you'd enter to find the piston extending or retracting to match the saved state of the switch.
Timers are like pistons - their complete state is saved on exit. So, if you have a system where there's a timer in a loop with logic gates, you'll often see gaps or blips of signal in your circuit because the logic gates loaded in with their load-state and then, after one tick, go to their computed state.
In creative mode, this can be a hassle if you're world-building because as soon as you open the world all of your memory bits will suddenly revert to their saved states on login. In Survival, the fact that all states get saved when you exit the scene means that the only kinds of things that are likely to suffer are timer+logic-gate loop circuits.
The simulator provides a number of controls that are simulate the effect of the game's saved state rules.
The spray-can button lets you simulate the effect of using the paint gun on a switch or a logic gate. To use it, select a logic gate or a switch (by clicking on it, note the change in the color of the border), then click on the spray can button or press 'p'.
The 'Lift' button simulates putting the build on a lift - it wipes all logic gates timers and sets all inputs to off.
The off-lift button simulates taking the build off of the lift; it causes the current state of all inputs and logic gates to become its saved state. Note! This has the same effect as leaving the scene in survival mode! (That is, moving out of render distance causes the build to be saved before you leave so that it can be restored as it was when you left it.)
The Up/Down button simulates exiting the game and coming back - causing the state of all logic gates and inputs to be set to their "saved" state. Note that right after you do this, the color-coding on the arrows becomes nonsense, as the calculation for the current state came from the saved state, not the gate and inputs.
The debugger starts in the paused state - mainly to cut down on distractions while you're doing your build. Once you're ready to test, you can either launch the debugger with the 'Play' button or run it a tick at a time. In the game, each "tick" is 1/40th of a second, but the simulator runs much slower than that to help you visualize what's going on.
You can change inputs by ctrl+clicking on them or by selecting them and pressing space. Note that input changes are recorded - so you can replay the same series of inputs by pressing the "reload" button (up/down arrows) or the '4' key. Hovering over the control shows you what's been recorded.
The best way to save and share your work is with the "link" button - that will encode your model into a URL... Possibly a really large one.
The disk button creates a file that you can re-load. It acts like a download - the file will be called 'logicgatesim.json' (or some munged version of that, depending on your browser). You can re-load a file with the folder button.
As you work, the simulator will auto-save your circuit to a cookie, but you really shouldn't count on this, since cookies get wiped pretty often and there's a limit to how big a model can be saved in the 4k allotted to a cookie. (Yeah, this could be made better for many browsers by using multiple cookies, but it hasn't been done yet.)
If you want to make comments about the particular use of a thing in the circuit, you can do that by right-clicking on the control to bring up the context menu and clicking the 'Edit Description' button. This allows you to write a markdown comment for the control that shows up when you hover over the thing.
It's possible to create a build in the simulator and then pull it into the game and to import the logic from an in-game blueprint into the simulator. It uses Scrap Mechanic's "Blueprint" mechanism to do this so, alas, it's a creative-mode only thing until that blessed day when blueprints are available in survival. Here's what you'll do to export a diagram you've set up in the simulator:
%appdata%\Axolot Games\Scrap Mechanic\User
User_
-- open that.Blueprints
-- open that.blueprint.json
is really, really small (<=1kb) - open description.json
in a text editor to be sure you're in the right place."blueprint*.json"
file that just got created.blueprint.json
file that's already there, so you might need to delete and rename to make that happen.Notes and limitation of warranty:
Importing a build from the game is similar but in reverse:
%appdata%\Axolot Games\Scrap Mechanic\User
User_
-- open that.Blueprints
-- open that.The resulting import will almost certainly need some re-arrangement (shift-click to drag). The layout is fully driven by the x-y position in the build, so if you have logic gates and such stacked on top of each other, they'll be a mess in the final layout too. It also doesn't have any representations for motors or other target devices, and it will filter out trivial logic gate systems. For example, a pair of buttons leading to an xor gate leading to a controller will not be imported.
a, o, x - If a logic gate is selected, these will convert it to an 'and', 'or', or 'xor' gate. If no logic gate is selected, a new logic gate of that type will be created at the current mouse location. Holding down "Shift" converts these into their not-versions -- e.g. putting your cursor in an empty spot of the field, clicking, and pressing shift+o will create a Nor gate at that position.
i - Add an input at the current mouse position.
t - Add a timer at the current mouse position.
<DEL> - Delete the selected input, logic gate or timer.
g - Start the simulator.
s - Pause the simulator.
4 - Reloads the simulation (like exiting and reloading the game). Think alt-f4.
p - "Paints" the selected logic gate or input - making its current state the saved state.
l - Simulates putting the build on a lift - it wipes all logic gates timers and sets all inputs to off.
shift+l - Simulates taking the build off of the lift or leaving the scene in survival mode. It causes the current state of all inputs and logic gates to become its saved state.
n - Run the simulator for a single tick (not enabled when the simulator is running).
<space> - Toggle the selected input.
This illustrates an implementation of an old friend, the SR Flip-Flop.
You may have seen videos of people wiring up these things and not having any strangeness, and yet when you make one of these it sometimes flashes wildly after you wire it up. It always flashes wildly if you put it on the lift. With the simulator, you can watch and see why - e.g. if you erase all the connection and then reconnect the gates clockwise (with the flow of the signal) everything goes great. But if you wire the connections counter to the flow of the signal, you can see that it starts in that wobbly state.
You can also observe that clicking one of the buttons (ctrl+click on one of the inputs - then ctrl+click again after 3+ ticks have passed), puts it into a state. Taking it off the lift marks that as the "saved" state, and reloading sets it back to that state.
You might have noticed that sometimes when you click the button on one of these things in the game that it'll cause the logic gates to start flashing wildly. The trick to doing it in the game is clicking really fast on the button. The simulator makes reproducing this issue simple: just start the debugger running, stabilize the circuit by turning one of the inputs on and off (after 3 ticks), then pause the debugger, turn on an input, advance one tick, turn the input off, and watch what happens. You can see that the crucial thing that needs to happen to prevent this is to have the signal from the input still be there when the signal makes it through the three-hops of the circuit.
By adding a few and-gates in a sequence, it's easy to extend the pulse-length to prevent mayhem when you click the button for a SR-flip-flop quickly. To see it work, stop the debugger, ctrl+click one of the buttons, single-step, then click the single-step button a couple of times to see it work.
This is a simple timer circuit that demonstrates the problems you can have in both creative mode and survival mode that come about because of the saved state rules. If you put a creation like this on the lift and then immediately take it off again, the two NAND gates get their saved state set to true. If you exit the game (or, in the simulator, press the reload button, key '4') then you'll notice that nothing bad happens so long as you do it when the gates are true! If you do it when the gates are false, you'll see a little glitch form on the timer data.
You can see the origin of the glitch if you pause the simulator when the logic gates are off, then click the reload button. Right away you see the gates turn on to match their saved state. When you single step again, you can see the gates flip back to their proper state because they take data from the timers again and flip back to off. Still, you can see the damage is done as the glitch flows through the timer.
This circuit implements a sledgehammer solution to the problem of glitches in timer feedback circuits. The circuit has several components. Note that some of the components in this circuit have "Descriptions" that you can see by hovering over the component.
The timer circuit itself is in the upper-left. It has two timers and one logic gate to flip it on and off. Obviously we need a minimum of three things to make an on/off timer like this, and if we had two logic gates in a row, it'd leave the door open to 2-tick-long glitches, and the glitch-detector logic we have is only good for 1-tick glitches.
The part of the circuit immediately below the timer is the glitch detector. It uses two and-gates in a daisy chain to make it so that we can simultaneously compare the current tick with the ticks one and two ticks ago. The XOR gates will only both be true if n-0 and n-1 are different from each other and n-1 and n-2 are also different from each other.
If we do have a glitch signal from the AND gate, that goes into a 2-tick pulse extender and it gets sent to a SR-flip-flop that halts the clock. The extended glitch signal also gets sent to a long timer, which goes to the other end of the SR flip-flop, releasing the timer circuit.
This circuit represents a creative-mode-only solution to the problem of memory bits losing their value on reload. To get it to work, you have to put it on the lift, flick the switch on, set or reset the flip-flop, let time pass for things to settle, take it off the lift, flick the top switch off and paint it.
As you might be able to guess, it works by exploiting the saved-state effect. It basically knows the real value of the switch from the timer (because that gets fully saved) and knows that it's in a restart mode and thus sets or resets the switch accordingly.
It's not practical in Survival mode because as soon as you walk away from the area where the device is located, the full current state will be saved, nullifying the shenanigans we pulled earlier where we got the save state of some of the components to be the opposite of what they would be like in normal play. In survival mode, as soon as the part is unloaded (because you walked away from the area), the saved states get set to the current state of the circuit, so the part of the circuit that detects login would not work.
In order to get a login-detector going in Survival, you'd have to create an unstable circuit, that forces the glitch scenario above in the timer circuits. It could be done (probably) but if you're aware of the issue, you can just avoid logging out at sensitive times for your builds.