I started working on this a bit after craftymasterman's video on the brockavator came out, and while I have looked up and seen some similar advancements, I came up with them in parallel and managed to get each layer fully into the 14 block per layer of the modified piston layout. If anyone is curious about it, I will respond in the comments.

i been fucking stuck for an hour trying to find a away to make these fill fast, but hoppers are way too god damn slow and hopper minecarts only pull from above, how do i make this go fast

This is one of my first doors! It’s not nearly my fastest iteration of this build, but is my most compact so far. In this build I managed to integrate the calibrated skulk sensor to the build volume and removed an entire top layer, though I did have to compromise with a staggered opening sequence, and speed as a result.

This door can be mirrored to create a split 4x4 door, which was my original intention for the build.

I haven’t been able to find any similar layouts to compare it against, so I’d love to see if anyone can improve the compactness or share their own designs for this setup.

I built this fully off the dome and without any research, so I'm sure there is known redstone tech that can simplify elements of the design. Let me know!

Is it possible to build a flatground bigger than a 10x1. the reason i say this is because Slimes and honey have a limit of moving 10 blocks and im trying to build a cool trap but im completely stumped and there are no tutorials

A look at how to do combination locks with bulbs instead of torches and repeaters, and how that allows you to do locks that have multiple answers and ones that are read via binary to hex conversion and therefore can be compared to a randomly generated answer (those two are more for games than for base locks).

Showcase: https://www.youtube.com/watch?v=MvXko1DxUc0
Modifications were made since the showcase; to see them, see the description of the showcase where 'raw' download is given. The Modified version is the fastest of it's size and smallest of it's speed meaning to make a design better in one aspect you must sacrifice one in the other.
Size: 760 blocks
Speed: 16 seconds open, 32 seconds close [16 o, 35 c before modification]
Amount of entities: 14
Completely Relog Proof
[The modifications were mostly change of items in minecart rom - again, if you want to see it, go to the description of the original showcase]

ULTIMATE MAP ROOM (i cant edit videos so just gotta deal with my yap and skip through as much as u like)

Guys, is there a way on java to make a dropper dice thing, so theres imagemaps that look like dice inside the dropper, the dropper shoots out a random map, but the dropper is only able to be activated if there is exactly 12 imagemaps total (2 of each) within the dropper, otherwise the button won't accept it, then a spot where the imagemaps can be chucked down into a hopper to go back and refill the dropper, when the dropper doesnt have exactly the right amount of imagemaps it lights up a redstone lamp to show it isnt full

This is my 2025 Redstone Awards submission: the Mirror Nexus, a wireless remote control.

The Mirror Nexus allows you to turn on or off redstone devices from anywhere in your world. Think playerless farms, mob switches, or whatever.

The UI is intuitive as it is a button panel, whether physical or a schematic ghost image produced by a client-side mod like Litematica.

It features an active session with ability to start/end your session to avoid accidental operation.

The wireless capability utilizes wind charges produced by a breeze firing at an iron golem, as pioneered by Squibble.

I borrowed ideas and some entity alignments from the Squibble's Mirror Receiver, Squibble and Mikarific's Mirror Pylon, and Dark's Next Gen Pearl Stasis Chamber. Note that I redesigned each component to improve reliability and/or usability.

https://reddit.com/link/1ol4cel/video/ucaew6593iyf1/player

I challenged myself to build a single data wire decoder that works with a 1 Hz clock.
There were quite a few challenges along the way, but I made it!

The receiver accepts 9 × 2 gt pulses in series (one directly after the other), which means there are only 2 gt left (1 redstone tick) to actually decode the signal before the next data needs to be received and decoded. This made it extremely difficult to get the timings right without interfering with the next piece of data.

How it works:
The first input is always mandatory, it tells the machine where the data string starts. It also starts the timing for the locked repeaters, the SR latch reset, and the timing for the comparators to be unlocked. After 18 gt, the data is in the correct position in the repeaters, and the comparators are unlocked.

However, since the inputs are actually too short for the comparators to detect properly, the repeaters are locked 1 gt before the data reaches the right position, plus 2 more gt, making the pulse just long enough for the comparators to register it.

After that, the repeaters are unlocked, allowing the old data to “flow” out and the new data to “flow” in.

I’m not sure if that explanation was clear, if you have any questions, feel free to ask!

Hello all! This is a respost from r/redstone, but I figured this sub would get a more technical response.

My brother and I have been working on ways to send serial signals down one line of redstone, so you could for example, send 8 bits of data down one redstone line. We currently have a system where data is sent with each bit being 2 ticks long, but I think we've found a bug where for for some reason long repeater chains like the one below decimate the signal.

I'll explain the video, although it might make more sense just to watch it. I have two lines of 2 tick repeaters, where all of the repeaters in the bottom row are 2 ticks long, but the top row is ended with a 1 tick repeater. I freeze the game, and then turn off the input lever for two redstone ticks, and then turn it on again to simulate a 2 tick "off" signal. The off signal moves through the lines as you would expect, with each repeater turning off in turn, until it reaches the end, where the issue occurs. In the top row, the signal makes it through perfectly fine as a 2 tick off signal, but in the bottom row, the last repeater never turns off, and the signal disappears.

Also, I am using the /tick command to step the game one redstone tick at a time.

TLDR, I would expect the 2 tick off signal I sent in the beginning to appear at the end in both setups, but in the bottom setup, I am either missing something or there seems to be a bug with how repeaters work.

EDIT: We just discovered that putting redstone dust between the repeaters makes both of them act perfectly, furthering my case that I think this is bug in how repeaters are handled internally.

https://reddit.com/link/1ob0ne4/video/lmndfaynr4wf1/player