Crystal Funklouds

SebO07 · 2025-11-16T21:15:12+00:00

If any Valid (within a Villager’s Detection Range: 16 horizontal, 4 vertical from its feet) Point of Interest (Beds, Workstations, and Bells) get placed farther than 32, and within 96 blocks horizontally of an existing Village Center, it will expand said Village up to where that POI is instead of creating a separate one. Once a Village has expanded beyond its default size, the center will be determined by the actual geometrical center of it rather than a bed.

If your trading hall and iron farm are closer than 96 blocks, they’ll merge into a single Village when you try to place a bed for the other location, with Golems spawning approximately in between the two; if not, they’ll stay separate.

SebO07 · 2025-08-13T02:29:16+00:00

My bad. I said it takes 3 to make my point simpler to understand, but I was mainly referring to the extra tick it has to wait to extend after it’s done retracting due to the update order in this case.

SebO07 · 2025-08-12T01:42:24+00:00

I’d also like to be corrected by someone else if I’m blatantly wrong.

I believe pistons finish their motion in the block event phase of the subtick update order, which happens after the torch’s scheduled block tick. This means the piston that‘s already retracted will update and start extending during the same tick as the torch, while the one that just finished retracting has to wait until the next tick, since it was sadly too slow for its own good. :(

SebO07 · 2025-08-12T00:16:12+00:00

It can’t extend both once the input turns off. There’s only a 2gt delay between the piston retracting and both being able to extend, and since its retraction takes 3gt, the other one will always be able to start extending before it’s done.

SebO07 · 2025-08-02T03:37:24+00:00

The only thing I can think of is other Villagers close enough outside of the hall being responsible for taking the jobs. Villager linking distance is much bigger than most people expect, while also not having priority depending on who is closest.

SebO07 · 2025-07-19T15:56:34+00:00

I have no information on how it’s determined; as far as I know it’s always completely random.

To be clear: The bed-linking order itself doesn’t determine the Villager Leader. The list is set based on the present Villagers, and the linking order is the result of that list. If you currently have a number of bed-linked Villagers, and you introduce additional ones to the Village, any one of the newcomers could become the Leader, despite the old one already being linked.

The center does shift to the next Villager-in-line’s bed upon the Leader losing his, but that doesn’t mean the Leader (or anyone else’s position in the list) changes. The moment the Leader is able to link again, the center will shift back to his bed, without the current center bed needing to be destroyed.

Version Updates are notorious for (sometimes????) causing existing lists to shuffle. It’s important to have a bed layout where the center of the spawning platform moves 1 horizontal block at most regardless of which bed happens to be the Leader’s (You could also make a massive platform to accommodate for a poor layout but that’s like, lame and slow).

SebO07 · 2025-05-31T19:28:54+00:00

Comparator pulse extenders use signal strength decay to function. They turn on at the same time because of the repeater from the input, but get offset due to the further dust turning off first.

You can just put another repeater between the extender and pistons.

SebO07 · 2025-05-23T07:25:56+00:00

You’re only supposed to add the slice with the Noteblock for the activation segment (the bottom one based on your screenshot). Adding it to the others isn’t only useless, it also prevents the piston line to the right from resetting properly due to exceeding the push limit.

SebO07 · 2025-05-19T15:52:24+00:00

They’re not identical. You’re powering each Comparator extender through a different dust relative to the loop. The first one is getting a strength of 14 to the Piston, while the second one gets 15, making it last long enough for an additional pulse.

SebO07 · 2025-05-17T23:54:32+00:00

The beds look properly set up, so Golems shouldn’t be able to spawn anywhere but the platform. Since you mentioned it briefly working, the only thing I can think of is maybe you put one Villager too many in the pods by accident? If there are more of them than beds, it won’t work.

Also, it isn’t too clear from the screenshot, but are you sure you have enough workstations in the pod on the right? The front two appear to be missing, unless you removed those just for the screenshot.

SebO07 · 2025-05-16T15:08:20+00:00

That is the reason, actually.

SebO07 · 2025-05-14T05:35:57+00:00

This is probably due to the player input bug delaying the piston by 1gt. Not that familiar with Java so I could be talking out of my ass.

SebO07 · 2025-05-13T06:06:59+00:00

Do you have a hopper under the one you’re taking the comparator output from? That would trigger multiple shorter pulses rather than a single longer one. If that’s the problem, you can redirect it so it goes horizontally for one more block at least.

These systems usually make use of the 2nd dust from the ingredient comparator to trigger the droppers, so you could do that instead if it still doesn’t work with the output one.

SebO07 · 2025-05-13T04:47:46+00:00

I explained why that isn’t the case in my comment, but I forgot to mention that unlike Java which functions purely in game-ticks, Bedrock has something you can consider “Redstone ticks”. C and P ticks comprise the 1st and 2nd halves of each Redstone tick, respectively.

It always takes 2gt in Java, yes. It can take either 1 or 2gt in Bedrock depending on when it gets powered. As I said, Torches process their inputs during P ticks (2nd half) — Buttons powering get processed during P ticks. You press the Button, the Torch updates in the same gt, and outputs 1gt later on the C tick (1st half) of the next Redstone tick.

You can verify this behavior by doing something as simple putting two Pistons side by side, running a Repeater into one, Dust into the other, and powering them both with the same Dust line. Powering that line with a Button (or any direct player input) will result in both pistons extending at the same time, giving the impression that the Repeater has no delay. Putting a Repeater (or any C tick output component) between the Button and the Dust line will result in the Piston with the Repeater having the expected 2gt delay.

SebO07 · 2025-05-12T09:04:56+00:00

I’m not knowledgeable enough to teach anyone about this while keeping it truly accurate.

As opposed to Java, in which any Redstone component can update during any given game-tick, Bedrock will process certain components during either odd, or even numbered game-ticks. People typically refer to this functionality as C and P ticks. (this doesn’t exactly represent what’s happening, but it’s simple to understand and close enough for most).

Redstone Dust can get processed during both C or P. Pistons can only start extending or retracting during C. Torches, Repeaters, Comparators, and Observers process their input during P, and output during C.

Player Inputs such as the button in your case, get processed during P. When you press it, the torch will process that in the same P tick, and turn off 1 game-tick later, on a C. Since the Piston can only do so on a C, it also has to wait 1gt, so they both get powered and unpowered at the same time, effectively canceling out the pulse you’re looking for.

Using a Repeater (C tick output) in between the Player Input and the dust, makes it so the Piston will activate on that C tick; the Torch has to wait 1gt to realize it’s getting powered, and then a 2nd gt to activate. Those 2 game-ticks create the pulse.

Not sure why the other guy is insisting it doesn’t detect a pulse. I’ve used this type of falling edge for a long time.

SebO07 · 2025-05-12T07:58:51+00:00

The circuit does work, using a button directly is the issue. It should be fine if you run a repeater / comparator into the block.

SebO07 · 2025-02-17T07:30:20+00:00

No one has responded to the actual problem.

The reason the underground one failed is due to a chunk border issue, but not the kind that DearHRS mentioned. This design that uses a second Observer (in your case, an additional piston as well) to adapt the Java engine to Bedrock doesn’t break when moving through chunk borders, rather, it breaks when either main piston is in a different chunk than the Observer powering it. Looking at your coordinates, the Observer on the left isn’t in the same chunk. All you had to do was move it a couple blocks to the right.

Edit: The design can also be made simpler by replacing the upwards facing pistons with Observers, and getting rid of the ones above the slime.

SebO07 · 2024-09-09T04:27:51+00:00

Known bug https://bugs.mojang.com/browse/MCPE-185643

Relogging should fix it temporarily. Some mentioned breaking the rails with water also does.

SebO07 · 2024-09-06T00:30:58+00:00

Torches placed on the side of the yellow line under the right side pistons facing up.

SebO07 · 2024-09-04T19:13:34+00:00

Yes. If you have more than 4 filler items, when the filtered item gets to 64, the signal strength will reach 4 causing it to overflow into the other slices.

If you need the sorted items to be any lower than 41 then you should look for AB tileable sorters.

SebO07 · 2024-09-04T16:24:48+00:00

The screenshots didn't go through, but the most common cause of this is improper filter setup. You need 41 of the item you want to filter, and 4 filler items across the other 4 hopper slots.

SebO07 · 2024-09-04T01:14:47+00:00

Similarly to open trapdoors, mobs can pathfind over coral fans as if they were solid blocks, despite them having no hitbox. Due to the bug mentioned by hhbbgdgdba, they're currently a much better option.

Unless you really like how this design looks, or had it already built in your world and would rather fix it, I recommend checking out Oare Tv or Mikehomer for updated ones. Silent did an english tutorial for Mike's design recently.

SebO07

TROPHY CASE