I just wanted to share a passion project I've been working on with u/scorpio_03 for the past 2 months in case others were interested. It's a fork of litematica that adds a bunch of features on top of it which allows to easily manage and share tons of changes on a project.

It has all the important stuff like creating commits, branching for safely exploring an alternative direction with your project, and even basic merging with merge conflict handling. In the backend, it stores a real git repository so you can push/pull your project and commits with platforms like github.

I initially made this for myself and a few friends since, especially for technical builds like tree farms, we are addicted to exploring different layouts and making tons of optimizations to the wiring, etc. At the end of it, we are left with over a hundred different schematics of our project which is not fun to manage by hand at all and figure out the changes.

It’s still in early development and the core workflow is starting to come together, so I wanted to share what I had and see what people think for those who are interested!

I have a carpet duper, and this is a problem that keeps occuring. It's an auto smelter, and I have a comparator at the bottom output hopper to check when items complete, and trigger the carpet duper. AND I have the hoppers leading into a dropper that drops the extra into lava to prevent over flowing. But the carpets keep catching the duped ones on them. How do I keep this from happening?

I found this video about a cool villager swapper that could hold 23 villagers in a cell, but it was sadly broken in 1.20 because of changes to honey blocks. Is there any way to modify to make it work again?

You just have to set "forceBlend" NBT in your chunks to true, and "transplant" them into your old world after clearing some buffer area chunks to grow the incoming biome. Here are some pics.

(trimmed around the jungle parts to keep the mangrove / sulfur cave biome)

I'm looking for an automatic storage system for my Minecraft world, but I'm not sure which design would fit my needs best.

I want a single-item sorter that can eventually handle around 500 different items (although realistically I will probably only need around 350–400). I don't really like multi-item sorters, because I find them harder to organize and understand.

Performance is also a big concern for me. I don't want to use copper golems or other entity-heavy solutions because I'm playing on a potato PC, so I need something that is as lightweight as possible. Water streams would be completely fine if they are still considered a good performance-friendly option.

The system would ideally start with a shulker box unloader and then sort everything into storage.

My dream setup would be something where the storage uses shulker boxes in a modular way. For example, the shulker boxes would already be placed as the active storage, even if they are not completely full yet. Once a shulker box is full and more items come in, it could be moved into a normal storage area, and when I need the storage module again, the shulker box could be placed back automatically. Basically, I like the idea of having storage modules that I can remove and move around with a button instead of having a permanently fixed storage wall.

It doesn't have to be the fastest system possible. I care more about it being reliable, expandable, reasonably cheap, and not too demanding on performance.

What sorter design would you recommend?

does anyone know why,
mobgriefing is true and ive tested another setup just 200 blocks away and it works fine but not here, why is it?

Can not think of any, but maybe there's a niche one

SCHEMATIC

Ive developed a chunk loader that loads a 4x3 of entity ticking chunks that requires no carts, using shulkers breaking as the entity.

Aligning the portals on a chunk border allows for the loader to dispense a shulker in both chunks on ether side of the border then quickly breaking them with a slime block piston into the portal. The recieving side catches the box entity, dispenses 2 boxes on ether side of its border a breaks them into the portal to send them back to the sender.

When the box is recieved in ether dimension, it is fed into a central distribution chest for that dimensions portal. This ensures that, should a box ever land in the wrong hopper (rare, but it happens) it makes no difference. The boxes are cycled quickly so any missed hopper will never result in the chunk unloading due to how infrequently the box misses its target hopper and the centralized distro.

After a week of none stop use, multiple server restarts, and 1 forced crash. The loader is still running and has yet to lose a box. There is plenty of storage for reserve boxes just incase for any reason a box is to go missing, it would take forever and a day to completely run out of boxes.

Why shulkers?

Because a shulker breaking has a very predictable trajectory when compared to an item dispensed from a dropper with random velocity mechanics. Droppers require item alignment wiring and are still susceptible to bizarre unpredictable flight paths. So when loading 2 chunks simultaneously, shulkers are immensely more controlable in a smaller space.

Why design this?

I have found many usecases for these type of loaders. At times using traditions loaders that load a 3x3 requires I build multiple loaders to cover the grid I need loaded and results in excess chunks being loaded. Im currently using these to load my redstone factory, it requires 3 of them, using traditional loaders would require 6 loaders and would load an additional 18 chunks that are not needed for the factory to operate.

Note when aligning:

-Align with all 3 coords for best results x,y,z

-If the recieving side is not on a chunk border and your coords are accurate. Go back to the sending side and use the coords from the other bottom portal frame block. They should align on a border in both dimensions

Idk whats going on, I've literally been building a sugarcane farm like 4 blocks away from this one and sleeping every night. I haven't heard any monster attacks too. The same happened to the carrot and beetroot farms that can be seen in the back.

Edit: i didnt mean they literally dispawn, amd I have lighting rods

Edit2: Im using iris shaders and sodium (required for iris)

Sugarcane needs an adjacent water source, so max-density layout is a coverage problem: each water tile hydrates up to 4 neighbors, capping theoretical density at 80% regardless of arrangement.

I modeled it as an integer program (CP-SAT / OR-Tools) to solve for the provably optimal water placement on a given plot:

• Standard community pattern: 66.7% density
• Optimal: 75.3% (94% of the theoretical ceiling)
• On open/unconstrained terrain the solution converges to a hexagonal-ish tiling and hits the full 80%

The honest trade-off: this optimizes purely for space/density, not for automation. The irregular water placement breaks observer-based harvesting since you lose the clean rows and water-transport paths. I think it's still automatable with slime flying machines, but I haven't tested that in practice.

Where it actually shines is irregular plots or obstacle-heavy terrain, where there's no established pattern to copy and manual intuition falls apart.

Code, more grid sizes, and obstacle-terrain examples: https://github.com/Serranegra/optifarm

Curious if anyone here has cracked automating a non-uniform cane layout (that's the open problem this leaves)

https://www.mediafire.com/file/nag4ojdhisjoaxg/Worm%2527s_Stateless_2_Speed_Loaders.litematic/file

Hey all, hoping someone can sanity-check my setup or confirm a known issue.

I'm running a wither obsidian farm in the End (similar to the "32,000 obsidian/hour" style tutorials) — Wither is caged on the obsidian platform, not moving, and I've got a snow golem set up in a poke-hole to hit it with snowballs so it goes into the charged/blue-skull phase and starts breaking obsidian.

Problem: the golem's snowballs just aren't connecting with the Wither. Wither stays at full/near-full health, no charged skulls, no obsidian breaking. I've confirmed:

• The Wither isn't moving.
• The poke-hole/line of sight looks clear to the Wither's body.
• Golem appears to be in position per the tutorial.

I found an old bug report thread describing this exact issue — golem randomly stops being able to hit its target even in an otherwise working farm, with the only fix being to break and replace the golem. I also saw a YouTube comment on a relevant tutorial (on 1.21.11) saying the workaround is to skip relying on the golem entirely and just use a dispenser loaded with snowballs, fired via redstone clock, aimed straight at the Wither.

I'm now building that: dispenser next to the Wither, wired to a simple 2-repeater clock loop for continuous firing.

Questions for the hive mind:

1. Is the golem-not-hitting-target issue still a known bug on 1.21.11, or is this version-specific/newer?
2. Anyone had good results switching fully to a dispenser instead of a golem for damage in these farms?
3. Any gotchas with wither skulls/explosions damaging the redstone clock circuit near the dispenser that I should watch for?

Appreciate any input — first time building one of these and want to make sure I'm not missing something obvious before I fully commit to the redstone.

https://www.mediafire.com/file/nag4ojdhisjoaxg/Worm%2527s_Stateless_2_Speed_Loaders.litematic/file

Looking for a way to calculate the pitch i have to look at (whilst im standing from any position) in order to land my fishing bobber at another position/target.

Playing around with concepts, next up is multiple minecarts to double or triple the speed. The setback behind multiple minecarts is that miscellaneous shulkers with multiple different types of blocks, non-stackable items, and tools all cram into each minecart at once. If you have a stack of cobble. Four minecarts can each take 16, but now a whole slot is taken up by just 16 and you can’t technically read that it’s full. I think the way to go about is to divide the signal strength by the number of minecarts. If a cart can hold 64x5 items. Divide by 4 carts. Then divide by the signal strength for a reader of 5.3 or just 5 flat.
Idk gonna mess around with it. I’ll be back!