Skip to content
RedstoneDB

How builds are recognized

Each type of build has an input and output contract. RedstoneDB finds a build's inputs and outputs, then searches through the ways they could fit each type's truth table, trying lines in different roles and orders until one fits. You don't need any particular colours or signs: once RedstoneDB knows what each line does, it colours them for you.

Inputs and outputs

Outputs need to be lone blocks, with dust, a repeater, or a comparator on top to read. Any block works, wool, concrete, stone, whatever, as long as no other block like it touches it. Glass only counts stained a colour. A block under a repeater or comparator that powers another block isn't one: that's just wiring.

Dust on a block that no block like it touches.
Passes. Dust on a block that no block like it touches.
Two outputs of one block touching.
Fails. Two outputs of one block touching.

Inputs need a lever on the side of a solid block, a lamp too. Dust on top of the block or underneath it is fine. There has to be room for a repeater where the lever is, so a bus could drive it instead.

A lever on the side of a solid block, which drives one dust and a torch.
Passes. A lever on the side of a solid block, which drives one dust and a torch.
Where the lever was, a repeater on a block drives the input as the lever did.
Passes. Where the lever was, a repeater on a block drives the input as the lever did.
Dust on top of an input's block.
Passes. Dust on top of an input's block.
Dust under an input's block, which takes its power as dust beside it does.
Passes. Dust under an input's block, which takes its power as dust beside it does.

Control lines like a carry in or a write enable, can have a block behind the lever, since only a lever or button will ever drive them.

Buses need to be evenly spaced lines, straight or diagonal, or two lines with their bits alternating.

A bus in a straight line, evenly spaced.
Passes. A bus in a straight line, evenly spaced.
A diagonal bus, rising one block for each block across.
Passes. A diagonal bus, rising one block for each block across.
A bus of two lines, its bits alternating between them.
Passes. A bus of two lines, its bits alternating between them.
A bus spaced unevenly.
Fails. A bus spaced unevenly.

Stackability

  • RedstoneDB tries a few different bounding boxes and checks whether //rstacking them gives a working, wider build.
  • If the whole box doesn't work, it tries smaller ones, leaving out as few blocks as it can.
  • You can keep parts out of the stack, like a carry in, by putting them on an outer face.
  • Stackable builds also compete on the leaderboards at 8, 16, and 32 bits.

Per-category rules

  • Some builds have optional control lines and data inputs, like an adder's carry in or an incrementer's increment line.
  • Gates take A and B and give one output as wide. A torch on the output makes the inverse, so XOR and XNOR share a category, with a flag.
  • Multipliers take A and B, and at most one calculate button. No reset. A third input can be an addend, for A × B + C.
  • Counters take A, one clock button, and one write enable lever.
  • Hex adders take A and B a hex digit per block, a signal strength through dust on top, in place of levers. Every other category takes levers.
  • Thresholds find their own number: how many inputs it takes to turn them on.
  • Popcounts and binary-to-hex converters can give their answer as one output's signal strength.

Recognized so far: adders, hex adders, ALUs, multipliers, incrementers, decrementers, comparators, carry outs, absolute values, popcounts, thresholds, binary-to-hex converters, gates, inverters, decoders, barrel shifters, monostables, registers, buffers, counters, and shift registers.

A build that doesn't fit goes up as built, unverified, with a note on what's in the way. Upload a fixed version later and it's verified.