Articles

Shulkerless Mob Switch – How to TURN OFF Hostile Mobs in Survival | Minecraft 1.14 Village & Pillage


Hello everyone. Today I wanna show you The Shulkerless Mob Switch. For this contraption you need a zombie or
a skeleton spawner. It could be anywhere, but depending on your circumstances you might prefer one location over the other. What is The Mob Switch? The Mob Switch is a contraption that prevents
a natural spawn of hostile mobs. In this case, in the Overworld. Yea, no creepers, no skeletons, nothing. Well, almost. Let me demonstrate. We’re in the normal difficulty, it’s night
time, this is a desert biome, and there are no mobs spawning around us! And this is because our mob switch is running
at the moment, but when I’ll stop this contraption, after a minute or two… Mobs will begin to spawn… I’ve managed to make today’s contraption robust
and modular btw. So, if you’re working with the exact modules
from the world and litematica downloads down from the description, you should be fine. Any Mob Switch relies on lazy chunks. Lazy chunks is a type of chunks which are
loaded, but don’t process entities inside them. If there are hostile mobs inside those lazy
chunks, they will count towards the mobcap, but their performance impact will be negligible. And also, they won’t despawn even if they should,
like when there are no players in 128 blocks radius. So, by placing hundreds of hostile mobs in
those lazy chunks, we prevent any hostile mobs from spawning anywhere else, but the game does not process those hundreds of mobs. One way to make a Mob Switch is to use Lazy
Chunks of the Spawn Chunks. However, when someone will respawn at the
Spawn Chunks, they will load those lazy chunks fully, and that will cause the mobs in the
Mob Switch to despawn. The Spawn Chunks btw is the area around the
spawn point where chunks are constantly loaded if there are players in the Overworld. Actually, it looks like in 1.14.3 they are
ALWAYS loaded no matter what. One of those rare mobs that counts towards
the mobcap and does NOT despawn is Shulker. If you’d try to name tag a regular hostile mob or
give him an item, it will take it OFF from the mobcap. So, without Shulkers, you have to use a spawner
and keep mobs despawnable in order for it to work. In 1.12, people used to artificially load
remote chunks in order to get lazy chunks far enough from the spawn point, and there
is a way to do that in 1.14. I’m gonna make a dedicated Chunk Loading video very very soon, so, make sure you subscribe and press that bell. And also, I have an SMP let’s play with farms and piston bolts a and stuff like that. And btw, I have to mention: this Mob Switch work
only in 1.14.3 and probably up, unless there is an i-card telling you
otherwise, more on that later. Let’s start from the end: here we have a zombie
or a skeleton spawner and a nether portal nearby that will act as a chunk loader. Whenever an entity, including an item, goes
through a portal in any 1.14 subversion, it loads a 5×5 area of chunks around an exit
portal for 15 seconds, but only 3×3 area of those chunks are entity processed,
and the outer area of those chunks are lazy chunks. And this is where we need to put mobs to achieve
the end result: to say goodbye to mobs anywhere else. We don’t necessary have to have a spawner
itself to be in lazy chunks, but we have to have a storage chamber with mobs in lazy chunks. This mob chamber design was showcased by… haydano and PuffingFish HQ, and it allows us to bypass the entity cramming, and stack hundreds of mobs in one block space. And if you use a zombie spawner, you need
to add this tunnel right here to deal with baby zombies. A baby zombie will drop down here, he’ll charge
towards the turtle egg, he’ll think of a trapdoor like it’s a walkable
block and fall into lava. And btw, turtle egg won’t hatch if it’s placed
NOT on sand. You need, I believe, seventy hostile mobs
per a concurrent player, so that if you expect 10 people to play at the same time,
you need to have 700 mobs. You can also use this to switch passive mobs,
bats and squids/fishes. Especially bats!!! You need 10 passive mobs per player,
15 bats per player and 5 water mobs per player. If you’re more than 32 blocks away from any
of them aside of passive mobs, each of them has a slight chance to despawn, so,
I’d recommend to have slightly more mobs than needed. A very important note: DO NOT load this specific chunk fully, the only exception is where you come from that portal. No players are allowed to be on a render distance to this chunk, otherwise mobs in this chamber will disappear, and you’ll have to refill this chamber again. So, basically, if your render distance is 10 for example, then the area between red and yellow
glass is where players are banned from. Note: while the red area goes strait up, the
yellow area is a sphere. And you have to stay inside that yellow sphere
or outside of the red square. Additional note: it looks like integrated
and dedicated servers are quite different when it comes to loading chunks around a player,
even with the same render distance number. On an integrated server, I had chunks being loaded in
a diamond shape within a shorter distance than N, where N is the render distance settings, but on a dedicated server, chunks were loaded
in a square shape, N chunks to each direction, counting the chunk we stand in. So, in both cases, if you’d count N chunks to each direction and it make a square, you should be fine. You know, it’s not actually THAT much of space
to waste, but if you don’t have it, having a Mob Switch in a remote location might be an option. Well, I’m not actually sure, we’ll find out later. And on the other side of a portal… We have the chunk loading engine and an item decoder. The Engine contraption generates rails and
sends them into a portal, that leads to the place with the Mob Switch. I was trying to come up with a design that
uses legit items, instead than duped rails, but all of them wasn’t robust enough. More on that later. And also, if you want to build today’s contraption
in your world, I strongly recommend to use Litematica. Especially for this specific part of the contraption,
because it’s quite hard to replicate just by looking at it. In the overworld we have a droppevator that
sends rails back to the nether… UPDATE UPDATE UPDATE: I’ve almost finished this video, but I have found that items still have a small chance to land on the obsidian, and to deal with that I’ve updated a droppevator design. Now you need to put hopper minecarts inside
obsidian with hopper blocks underneath. Old design will be visible here and there,
but THIS is what you actually need to use. To put hopper minecart into obsidian, all
you need is just a curved rail facing into a block, and make sure there is a block underneath. Like that. In theory you can use just one hopper minecart,
depending on where items are gonna land, but using two is a safe way. Fortunately, it seems like we don’t have to
use hopper minecarts at the Mob Switch itself. Which means less lag for the server. … where they get destroyed. By sending items back and forth like that
we force 5×5 area around both portals to be permanently loaded until a restart,
and that means… Our mob switch is constantly running,
and hostile mobs won’t naturally spawn anymore. This is a control panel at the Spawn Chunks. It’s not necessary to have it, but because
of this contraption over here, it automatically enables the Mob Switch after
a game restart, if the Control Lever is turned on. When we restart a game, this frost walker
boots on the armorstand freeze the water, then this observer sends a redstone pulse, and if the
Control Lever is turned on, it sends an item into a portal. And on the other side… We have a chain of portals. And that item will go back and forth between
the nether and the overworld, and it will eventually end up and the chunk loading engine, loading the chunks around portals on its way for 15 seconds. Unfortunately, when something goes through
a portal less often than once in 15 seconds, it creates a noticeable lag, bug since you have to send an item just once per restart, it’s not that much of a problem… It will take some time for the item to travel
through, so, you might have some creepers spawning in for first 1 or 2 minutes. And here we go, our Mob Switch has been kickstarted. Once again, THIS contraption and the Mob Chamber
on the other side will stay permanently loaded. Unless you turn it off from a control panel. When you switch the state, it will generate
and send either a detector rail to turn it off, or an activator rail to turn it on. And if it is set on “on”, it will send another
activator rail after a restart. You can repeat this section again and again
and run this line as far as you’d like. Of course, that means it will take longer
for the item to travel, and it will lag for longer, but it’s still a possibility,
and it will lag just once per a restart. As an alternative, you can remove the line
of portals that goes from the Spawn Chunks, and just install a lever here. Basically, this is a bare minimum you need
for it to work, but in this case, you’ll have to go here and load this place
manually after each restart. Or if you’re in a single player world, in
the beginning of every single play session… Ouch… All modules of this contraption are not affected
by location or direction. You can channel the exact same thing to any
place you’d like. Well, of course, The Control Panel has to
be somewhere at the spawn chunks, and portals between dimensions have to be linked up correctly. My advice to avoid issues with linking up portal,
is to build this line at the bottom of both dimensions, and make them as close to the matching coordinates as possible. Also, it’s beneficial to use a diagonal
line when it’s possible, because you can move one chunk forward and one chunk to the side from the same portal, so, effectively, you use twice as less portals
in comparison to having a strait line forward and then a strait line to the side. But the portal alignment doesn’t have to be
perfect btw, as you can see right here. We have one overworld module here, and another… over… here… And btw, when it comes to calculating a closest portal,
y-coordinate is considered as 1-1 between dimensions. You can probably move these portals back and
forth for 1 or 2 blocks, but it’s way safer to move the overworld module instead. However, THIS counts a single module and you’re NOT allowed to move anything inside it, including these 2 portals. And it’s very beneficial, but not required,
to have this contraption aligned to the chunk boundaries exactly how I placed it,
so that we have no parts moving BETWEEN chunks, which otherwise would slightly increase the
chances for it to break when the game stops. And in general, it’s a good practice to keep
your active redstone in one chunk, and this is exactly what I’ve done today. So, if you don’t really care how exactly if
works, you can just build it from modules like a constructor and it will work, but here
are the caveats: -The main caveat, as I’ve said previously, is that no players are allowed approach to this place from the overworld. -Double check how many items there are in
inside the hopper clock here… and here. -You need one item in one of these droppers. -You need to set up item filters for activator
and detector rails. -These slime blocks have to be detached from
sticky pistons in the idling state. -And check that there are no random items
stuck in the hoppers and droppers, with the exception for droppers in the final module. You have probably noticed that different portals
have different heights and y-levels. And it’s because depending on a way we send item through a portal, they have different teleportation points and momentum. And I’ve been testing various portal configs
to make it so that we can send an item from the bottom, and receive it back here, and send it forward. So, by combining exactly where and how we
send items through portals, we can have an input and an output in the same portal. Of course, I’ve done all of that testing for you, and
if you’ll stick to these exact modules, you should be fine. Ah, btw… Here we have a redstone torch hidden underneath. And these composters aren’t strictly necessary btw,
but having composters on top of hoppers reduces lag. And now… Let’s take a look at these circuits. This one is the decoder. It starts with two item filters filtering
detector and activator rails. When we get an activator rail from
the control panel we have a signal here, and for a detector rail we have a signal here. Both of them lead into RS NOR latch made of two droppers facing each other and one of them has 1 item. If we get an input here, the latch will change its state, and this comparator will give us an output, that will power the chunk loading engine. After that, we can send a signal into this
dropper again and again for as many times as we’d like, but nothing will change. Until we send a signal into this dropper which switches
the latch and causes the whole contraption to turn off. And the purple circuit here is responsible
for disposing items into lava… Next we have this hopper clock with 4 items inside. It controls the rail duper and the rail pusher… To dupe rails, we need to power this formation
of blocks quite fast, and we can achieve that by having two observers facing each other. I totally expect this to be fixes in further verions,
and when it will happen there will be video in the i-cards. However, we have to reduce the speed because
otherwise rails would stuck at the pusher, and can we achieve that by pushing a redstone
block back and forth above this sticky piston. Next we have a 1.5 redstone tick pulse generator
showcased by Ilmango, powering a sticky piston with a slime block in front. It’s shorter than 2 redstone ticks, but unlike
with 1 tick pulse, sticky piston keeps its block attached. So, this thing sends rails into a portal, they’ll come back from a portal and we disposed by a dropper clock circuit While this entire setup looks chaotic, every single piece here is designed with a purpose to no break after a restart. And because this contraption is supposed to
run 247, it’s necessary to make it restart-resistant. Originally, I was trying to come up with a
design that farms and uses legit items instead of duped rails, but the additional system
we’d need to have was breaking on restart. UPDATE: I think I MIGHT have some ideas
on how I could make it work. There might be an i-card in the future. And that additional system that always breaks is the Item Aligner. If we’d just teleport items from the Nether to the Overworld, every single item will cause a huge lagspike, despite the fact that those chunks are already loaded. And I think it’s because of calculations
of a corresponding portal. But if we’ll send items into the same 2 pixel
window more often than once in 15 seconds, game will REMEMBER that location, and thus
we’ll have no lag because…. Because Minecraft? And the Item Aligner would take care of that, and I’ve tried like a dozen designs of Item Aligners, but unfortunately, NONE of them happened to be restart-resistant. UPDATE: Because it’s Minecraft, you have to
send items more often than once in 15 seconds. I’m not sure exactly why that happened, but if we’d
send items less often than we do, we’d get occasional lagspikes. Actually, we still have them very rarely,
but it’s nothing we can do about. But fortunately for us, this setup acts as
an Item Aligner on its own, and it doesn’t break. Actually, there is a very small chance that
these observer clock can break, but all you need to do to fix it is to replace them. The item transportation system is not AS resistant
to restarts as The Engine, but it doesn’t really matter because you run this system
just once in a while, and it’s not 100% chance to break on restart. There are at least two major factors why those
system break: First one is repeaters are saved kinda wonky,
and if you have two concurrent lines of repeaters with the same total delay, but with the different
inner timings, they can desync if would be unloaded when
repeaters are running. See? The second one is that sticky pistons can lose their
block when they’re unloaded at the wrong moment. In my experience, that moment is that 1 game tick, when repeater is already powering the piston, but repeater’s visuals are yet to
catch up, and if we relog in that moment… Here we go. Nice, I mean, awful. Another thing I’ve found is that if signal that comes to the final repeater is longer than its delay, it’s less likely to break, but it’s still a possibility, and that’s unacceptable for our needs. Why this design doesn’t work in previous versions? In 1.13, whenever an entity moves to the nether,
it loads the surroundings only for 1 tick. And in 1.14 before .3, chunk loading stuff works fine, but hostile mobs in lazy chunks don’t count towards the mobcap. Glad that’s fixed by now. Does it work on Spigot? There is no answer to that, each
spigot server is configured differently, has its own set of plugins, and there are
also like over 9000 forks of Spigot. And to end this video, let’s test how long it will take to load a Mob Switch located at 1000 blocks away from the spawn chunks. Well… I think it’s still worth it… After all, you’ll get a mob-free experience for HOURS,
while this contraption lags for a couple of minutes. And this is all I have to for for today, and
if you have enjoyed this video, leave a like, say something nice in comments, and subscribe:
Chunk Loading video is coming soon say something nice in comments, and subscribe:
Chunk Loading video is coming soon ™ Bye-bye!

Leave a Reply

Your email address will not be published. Required fields are marked *