Chunk Loaders in 1 Command - Lazy & Entity Processing Chunks

Let's talk about Chunk Loaders, again!
Today won't be an explanation, I already did plenty of that in a previous post. This time I have a more practical thing for you, Chunk Loaders in 1 Command!
The command will allow you to put and remove loaders with just 1 click. You can also choose between loading a single lazy chunk or a 5x5 grid of them, creating an entity processing chunk.

Well, if you are a boring person who is here just to get the command and install it in your world, find the pastebin for it here.
Now, if you are a cool person who also wants to know how the system works, so you can maybe even use the concepts yourself in the future, keep reading!


The Chunk Loader System by SiberianHat
My system works based on an Arrow Chunk Loader.
This loader basically is an arrow at loaded chunks that keeps checking for a block at another location, therefore loading the chunks there. If you want to know more about it, feel free to read my post about chunk loaders where I explain everything in details.
One arrow is used for every loaded chunk, however there's close to no lag created by these entities alone. The possible noticeable lag caused will be from the chunks themselves. Loading chunks is fun, isn't it?

The rest of the module is just making everything tidy for you to use.
Firstly an easy method to get the egg used to load a chunk/ an area, by giving it to the player when they have an shulker egg named "Chunk Loader" in their inventory, so they only have to rename an item.
Then a system to know when to stop loading a chunk/ an area, detecting when the player breaks the block that represents the loader by just detecting when there is air there.
And also a highlight given to the loaders when you hold the loader egg, so you can easily find all the loaders active; achieved by giving the loaders a glowing effect if you select the egg.

An Area Loader, highlighted by holding its spawn egg

Anyway, the interesting part is to spawn the loaders. Not the single chunk loader, which is only setting a barrier block at y 255 and summoning an arrow (the arrow loader method), but the area loader.
To create an entity processing chunk we need this 5x5 area of 25 loaded chunks. Rather than having 25 commands to place barrier blocks and 25 more to summon arrows, there is a little clock to take care of it all.

Two Area Effect Clouds are summoned beforehand with a Duration [tag] of 26, one to place the blocks and summon arrows and another to control the time.
The clock will keep running as long as this second one still exists. Only one cloud could be used for everything, however, if it entered lazy chunks for any reason, the entity would not be processed and would keep existing for more than it should, as well as keeping the clock running longer. We really don't want that.
Well, when the clock starts, the "summoner" cloud will be at the very corner of the 5x5 grid. Every cicle it'll /setblock a barrier at y 255 and /summon an arrow there (to load the chunk), then teleport itself 16 blocks (1 chunk) at the z direction. There'll also be a check if the cloud has gone to far, away from the 5x5 grid, teleporting it back to the beginning z coordinate and 16 blocks at the x direction. That happens 4 times, so the cloud passes by every chunk in the area and loads everything.
At the end both clouds are expected to despawn, but even if only the one used to control the time does, the clock stops and the other cloud is killed.

By the way, the area loader needs a view distance of 5 or higher to work, because of how the arrow loader is set up; the arrows need to be processed.


It's not a complicated system, nevertheless it was fun to make.
Again, if you somehow missed it, the paste bin for the 1 command install can be found here.


The Original System by SkyLegend and EJ Monkey
It's worth mentioning that, although the system I'm presenting you was made entirely by me, the original idea for the command was thought by SkyLegend and EJ Monkey. You can watch their version here (Sky) and here (EJ).

I decided to remake the idea because of how they approached it: their system is based on a Spread Players Chunk Loader, which works yet is far from the perfect solution.

Why? Well, to keep a single chunk loaded, you need to spread an Armor Stand 20 times per second. On top of that, because of how they set up their system, the entity tries 8 times to land, making so there are 160 checks per second. If you have a 5x5 grid loaded, there will be 4000 checks per second.
That's laggy. Very laggy.
It's warned that using their system causes lag and even potential crashes.

There's also the problem of using water on top of the world.
When /spreadplayers tries to land an entity at a water block, it won't be able to and it'll try again until a valid spot is found or the possible blocks end. In this case, it'll try 8 times until it gives up. The only benefit with this is that the used entity won't leave the spawn chunks, staying loaded even if the player leaves the world.
Still, you can do the same by teleporting the entity back to the spawn chunks every tick. It's not a laggy solution and allows you to remove the water, therefore having 8 times less checks and making the system up to 8 times less laggier, as the entity will only try to land once.

Also, water partially blocks sunlight and is visible when you look at the sky.

8 water blocks at y 255, used to prevent entities from successfully being spread to the location

Apart from using /spreadplayers, their system is pretty good. I used some of their ideas on my system, like a spawn egg to start and breaking a block to stop the loader.
They also managed to fit everything in a very small amount of command blocks, seeing how complicated the system is.
Be sure to check out both of them!




Well, that's all I had for today. It wasn't much, but it came with a very useful tool you can use!
Feel free to use the tool to your liking, just be sure to give the proper credits if you plan to showcase it or share it to someone else. Also, let me know if you find any bugs!
Thank you also for reading and have a nice new year!

The Return Function (Multiplayer and Single Player)

Who needs plugins or mods nowadays?


When playing on a Vanilla server like the Maizuma Creative Server, people start missing plugins and mods normally used on public servers.
I often ask what our group would like to see implemented on the server and, when the Back function was suggested, everyone loved the idea.
What this function does is to remember your position every time before you teleport, so you can go return there by just using a command. It's a really simple yet really useful tool to have, so I started to work on a command block version of it, which I named the Return Function.

I originally made the system for our multiplayer server, but I also decided to make a tiny single player version so I can release it to anyone who wants to have it in their world. There'll be an One Command install it after the explanation!

Well, let's talk about how everything works!


The Single Player Version [gfy]
The basic idea behind the Return function is to remember the player's position before teleporting. They can then type a trigger command, which works for non OP players, to return there whenever they want.

We can leave an stationary entity at the saved location to keep track of it. Returning there is as easy as teleporting to the marker created when teleporting.
Of course we need to be always able to find the entity if we want to teleport to it, so it's also necessary to keep it loaded. There is a ton of ways to achieve that and I discussed them on this post about Chunk Loaders.

In this case I used the Arrow Method, that relies on summoning an arrow and teleporting it to loaded chunks after it hits a block. I like this method as it's very easy to set up and causes no lag compared to others, needing only a slow clock making sure the arrow doesn't despawn.
However, there is a very specific problem we may run into, when a player instantly leaves and "unloads" an area, turning the chunks they were at into lazy chunks, that don't process entities, and not letting the arrows hit a block, process necessary for the loader to work.
To avoid the problem, we can either load a 5x5 area of chunks around the arrow - which is not a really good idea haha - or create the arrow before the player teleports. This second idea is much better.

Anyhow, I called the fortune teller society and no one answered me - they already knew what I was going to ask - so, as far as I know, there is no way to know when a player will teleport before they do.
What we actually do is to create a temporary loader periodically, deleting the previous every time we create a new one. When a player actually teleports, the current temporary loader will become permanent.
It might not sound like the best idea lag-wise, but it doesn't cause any problems, as it'll just kill 2 entities and summon another 2. I used a 1 second clock and works fine, yet you can also make it even slower if you wish to, just keep in mind it'll take longer and longer to save your location.

Well, with the problem out of the way, we just need to know when a player teleports, which is pretty straighfoward.

To detect when a player moves a certain amount of blocks in an instant, we can compare their previous position to the new one.
One tracker entity is all we need to compare the positions. It will constantly be teleported to the player and, on the next tick, before teleporting again, the entity detects if it is at least a minimum distance away from them. If that's the case, the system deletes the last position saved and saves a new one.
In any case, the tracker will always be teleported back to the player after the check is done.


That's pretty much it. The single player version doesn't require a lot to work to be done.
I also compacted it into a 1 Command Block creation so you can install it on your single player world. The command can be found here (the command blocks look different from the gfy, but it works the same way).
If you find any problems with the system, please let me know so I can fix it.

The Return Function, after being installed with 1 command

Oh, before going into the multiplayer version, I just want to let you know the system doesn't work in the Nether and the End, due to command blocks not being able to handle entities at different dimensions correctly or reliably.


The Multiplayer Version [gfy]
Let's now jump into the multiplayer version, which is very similar as the single player one in essence, just with some more additions to be able to handle multiple people at once.

To mark the position where the players have to go back to, we keep using a marker entity. However, we will now use an ID score system so we can know to whom each one belongs.
The IDs are given to every player who teleports using the Command Book and Tellraw menu, even if they aren't officially part of the MCS group, and it gets cleared from them when they log off. If the ID is cleared, both the loader and the position marker correspondent will be deleted to avoiding multiple chunks unnecessarily loaded.


To return people to their original position, if they use the Return function, we teleport them to the markers created before they teleport, just like the single player version, though we have to know which marker belongs to the player requesting the Return.
To associate the two with equal ID scores, we can use the player's score and remove it from all markers. The one left with a score of 0 will be the correspondent marker to which the player will teleport.
Of course, the score will be then added back to the markers so they have their original ID score back.


Now, to know when markers and their loaders are no longer needed, because the player with the ID correspondent to them logged off, we use a system similar to detecting players joining or leaving the server, like we did to refresh the Command Book to people logging in on a previous post.
We have a normal clock running a /testfor, checking for players with any score on the ID objective. A comparator taking an output from the command block will point at a BUD, which will update if any changes happen to the amount of players with said score.
It is worth mentioning that, even though a comparator can only output a signal strength up to 15, if the SuccessCount of the command block goes higher than that, the comparator will also update the BUD.

A clock testing for players with any score on the ID objective, with a comparator pointing into a BUD

The ID System
Being detected a change in the ID score list, we now will decide how we are going to handle the extra markers, if that is the case. There are two methods used, an instant one, that can only handle 1 extra marker at once, and a slow one, that can handle many extra markers at once. We could always use the slow method, however it can take a long time to process, if there are many IDs, and it keeps us from letting players teleport using the book.
Using the instant method is preferable. It is most times the case as well.

Anyway, to know when we use one or the other we will see if there are 2 or more extra markers in comparison to the amount of players. To count both, as well as to do more calculations later on, we use 2 entities which I'll refer as ReturnCP (Return Calculation - Players) and ReturnCL (Return Calculation - Loaders).
We firstly make every player with an ID score add 1 to ReturnCP and every loader add 1 to ReturnCL. We just do a scoreboard operation to remove the score of ReturnCP from ReturnCL. 
The end results can be 0, meaning the amount of players is equal to the amount of loaders, nothing is done in this case; 1, meaning there is only 1 extra loader, so we execute the instant method; and 2 or more, leaving us to execute the slow method.

The Instant Method
This method consists of adding all the ID scores of players to ReturnCP and all the ID scores of loaders to ReturnCL, then subtracting ReturnCL from ReturnCP. The result will be the exact ID score from the missing player, remembering that there is one extra loader because that person left.
We then remove the result from all loaders, so we know the respective one will always be left with score of 0. The one found is killed and we add back the result to the remaining loaders.

We can't use this if there are more than 2 loaders because the end result would be the sum of those, not letting us know exactly which ones are unnecessary.

The Slow Method
This method is rarely used, yet still needed, in case two or more players leave the game at once for any reason.
It consists of taking all the loaders, one by one, and checking if there is a player for each. The ones without respective players will be deleted.

Before the process starts, we first need to stop the teleport commands from being executed, as they use the ID scores of players to remember their original position before moving, used for the Return function.

We start the clock setting an impulse command block to auto:1b, which will execute all the following commands. The command block will set itself back to auto:0b and, only if the clock needs to cicle again, it'll be set back to auto:1b, repeating the process.
The actual commands will first add 1 to a counter, using the ReturnCL in this case, and then remove 1 from every loader and player with an ID score, with the objective of having a single one of each with a score of 0. If there is a loader but no person with a score of 0, it'll be deleted.

The process repeats as long as there are loaders with at least 1 on ID. If all have been checked, they will all have a score of 0 or less, so the impulse command block at the start won't be set to auto:1b and the clock will stop.
We can detect when the command that keeps the clock running fails and execute the final commands to reset everything, which adds the score accumulated by ReturnCL to all remaining loaders, restoring their original ID score, and lets the teleports to be used again.




And that is the Return Functions explained! If you have any questions you want to make or something you want to point out, please comment below.
Feel free to use the 1 Command to install it on your single player word. Again, it can be found here.
Apart from that, I hope you've liked the post. Thank you for reading as always and see you next time!

What You Need to Know About 1.9 Chunk Loaders

It's finally time to start talking about the fun stuff!


Let's begin with Chunk Loading.
When creating Command Block systems, we might need to access chunks outside the Players' reach, be it to find entities or use blocks from there.
Sadly Minecraft doesn't give us an official way to remotely load chunks, but there are a few mechanics we can use to solve the problem.

I'm gonna talk about some solutions, each very useful for its own necessity and working based on how Minecraft itself works.


The Arrow Method - Keeping a Chunk loaded
Around a year ago, test137E29 uploaded a video talking about Arrow Chunk Loaders.
Sadly, it relied on using an extending piston and, after piston movements got improved in 1.9, the old system no longer works.
But that doesn't mean we can't still use the concept to our favour and improve it.

test's Chunk Loader worked by simply turning an Arrow's position to NaN (Not a Number) coordinates, which would then make it appear at x = 0, z = 0.
It's possible to set the position of other entities to NaN coords as well, like Myren Eario showed with Shulker Bullets, but Arrows are special as they constantly check the block they are inside of to detect if this is broken or moved. Now, if the block is at unloaded chunks, the Arrow will need to load that area so the detection can be done.

Of course normal Arrows don't act as loaders. When they aren't being processed by the game, the block test will cease.
However, if they are in a loaded area and away from their original position, they will do the block test and remotely load the chunk the block is in. This behaviour allows us to load any area we want.

test137E29 has achieved that by using the NaN position, yet we can actually change the Arrow's position using the /blockdata command.
While the NaN method has the limitation of only working up to 32768 blocks away from 0,0 and needing to keep 0,0 loaded, changing the Pos [tag] doesn't have an area limitation and it can send the Arrow where you want, letting you have the spawn chunks anywhere.
The down sides of this new design is the need to use Command Blocks to make it work and not being able to remove the block the Arrow was in while it's acting as a loader.

Changing the position of an Arrow with commands to send it to 0,0

This loader is used to keep chunks loaded, meaning we need to previously load them before they keep like that.
The main applications are more about accessing entities or blocks inside those chunks.
You can use an entity as a marker and teleport to it whenever you want, being able to do this.

IMPORTANT EDIT
After making the post public, I found out it's not necessary to change the position of an Arrow with /entitydata for this method.
As long as the entity doesn't move, any changes at its position won't interfere at the tile tags, which remember the coordinates of the block it is inside of. In other words, using a teleport will also work.
The only condition for using the /tp command is to have a solid block at the destination. If there's air or something the Arrow can fall through, its Motion tag will change, forgetting where it was previously at.

So, to load a chunk using an Arrow, it's as simple as summoning it at a block, waiting a tick and teleporting to a loaded chunk. It's as perfect as it can get.

Teleporting a loader Arrow to an entity at loaded chunks

Using the System
Firstly we need a block for the Arrow to stay in. Keep in mind that this block cannot be broken while the loader works.
We then summon the Arrow inside the block with a pinpoint tag, just so we know which one we are working with. I also like to give a starting Motion [tag] to make sure it'll be inside the block as fast as possible, though is not necessary.
Afterwards, we'd need to change the Pos [tag], however the Arrow needs a tick to update itself and realise it's inside a block. An easy way to wait this one tick is to set an impulse Command Block to auto:1b using /blockdata and make it power the remaining commands, just reset it right back to auto:0b so it can be reused later.
Having passed a tick, just do an /entitydata to change the Pos [tag] to the coords you wish the Arrow to appear. You can also use the same command to remove the tag used to pinpoint the entity and even add new ones.

Now we'll also need to make sure the Arrow doesn't despawn. Simply put a clock reseting its life [tag] to 0s every so often. It doesn't need to be fast, only trigger before 1 minute.
Edit: You can also set the Arrow's tag to -32768 so it lasts around 27 minutes!

You can find the commands used here.


The Reversed Arrow Method
I've shown you how to load chunks by changing the position of an Arrow whilst it stays inside a block, but the reverse process is also possible.
We can summon an Arrow anywhere and tell it is inside a block somewhere else. For that we use the xTile, yTile and zTile tags, which refer to the block's position.

It's possible to remotely load a chunk by using this reverse process, without the area being previously loaded.
On the other hand, you can only use it at set coordinates and, if you want to keep it loaded, there must be a block there beforehand. If there isn't, the chunk is still going to get loaded, though it'll unload randomly shortly after.
Also, when the Arrow is summoned, it takes one tick for the chunk to get loaded. We can use the 1 tick delay method I talked about to trigger the other commands.

This method is only used for very specific areas, however it is very light to use, as no lag is caused, and really useful for pontual uses of a small area which doesn't need to be previously loaded.


Using the System
To use this system, one command is enough: /summon Arrow x1 y1 z1 {xTile:x2,yTile:y2,zTile:z2}
x1, y1 and z1 are the coordinates where the Arrow is going to appear. You need to keep this area loaded in order for the loader to work.
x2, y2 and z2 are the coordinates you wish to load. There must be a block there beforehand if you intend to keep the area loaded. If the Arrow can't land in a block at these coords, those will be updated to where it was summoned and the chunk will only load for a short moment.
You also need to make sure the Arrow doesn't despawn if you want it to keep loading the area.

Summoning an Arrow to load the 1000 1000 coordinates

The Spreadplayers Method - Loading New Chunks Remotely
The /spreadplayers command is known for being able to load new chunks remotely, although it has a mistaken fame of being unreliable. Nevertheless is possible to use it without problems, just using simple fixes.

The way this command works it similar to how Arrows check for the blocks they are in. When entities are spread, they have to land somewhere where they can stand on, so if there is no block there or water/ lava, they'll try to land somewhere else.
The /spreadplayers will randomly select a block to put the entities and, to know if the location is legit to use, it'll have to be loaded so the block is tested.

Now this is very helpful, we can use any coords we want in the command, even relative to other entities. Not only that, but also load multiple chunks at once and the target location doesn't need to be previously loaded.
It's also instant!
It sounds perfect, however it needs to run every tick, on a 20Hz clock, to make sure the chunk stay loaded. Having lots of these working at once can cause considerable lag because it also needs to do extra calculations every time.
I recommend only using it to access unloaded chunks and, if you need to keep them, use the Arrow method right after.


Remotely Loading a Specific Chunk
If we use set coordinates, loading a chunk is very simple. The main command used is /spreadplayers x z 0 1 false @e[tags], being x and z the destination. We'll need to use an entity for that, any type should work fine. To keep the chunk loaded the command must run in a 20Hz clock; a repeating command block does the job.

There's a little problem, though. If the command stops running, normally because we leave the world, the entity will stay stuck at the destination chunk and we won't be able to load there anymore. The fix is straightfoward, we just need to prevent the entity to stay at unloaded chunks.
The simple solution is to teleport it back to where the command is being executed when /spreadplayers triggers. With that, the loader will manage to keep working after leaving the world and even after more than 7 hours running straight, from what I've tested.
We can also prevent the entity from even leaving its original position, by not letting it land at the set coordinates. Do that by either having only void or water/ lava as the highest blocks there. We cannot always use this solution, but it avoids having to use an extra teleport.

Using the spreadplayers command on a Pig to load the 1000 1000 coordinates

Remotely Loading a non Specific Chunk
There's no need to restrain ourselves to specific destinations. By using relative coordinates, /spreadplayers can be used to load anywhere you desire.
Now, by using relative coords, the entity needs to be first sent to the location and then execute the command on itself. We can achieve that by teleporting the entity there as, when we teleport it to unloaded chunks, some commands can still be run before it unloads, such as teleporting again or using /spreadplayers.

Ok, teleporting also uses specific coordinates, even when using relative ones. But with the help of scoreboards and a little of binary we can go anywhere! Just have one score for each axis (x, y and z) and you're set to go.


To reach the destination, binary comes in play.
To teleport in one direction, we start by checking if the score of that axis is higher than a high 2^n value. If it is, the entity will be teleported by this amount and the same amount will be removed from the score. If it's lower, the current value is ignored.
It then repeats the process with the next value, 2^n-1. The process happens over and over until it reaches 2^0. By the end of it, the entity should arrive at its destination.

Do the calculations using another objective so you don't loose the information.
Also note that the Minecraft world goes from -30 000 000 to 30 000 000 on the x and z axis, so if you want to cover the entire map use 2^n as 2^25.

The coordinate scores can be changed by hand or using command blocks to specifically set those, but we can also transform the entity's position into it, allowing the entity to remember any position it was it.
Wubbi shows us how to do that in his Warp Points video. I recommend watching his video if you want to learn the concept, he explains in details there.


Loading Multiple Chunks at Once
There are two ways of loading a group of chunks.

The first is to have the area you want to load with a water or lava ceiling or without any blocks for the entity to appear when /spreadplayers is used.
The command always try to put the entity somewhere. If it can't, it'll try another location until it works. While it does that, it'll load chunk after chunk to know if it's possible to put the entity there, resulting in all the chunks being loaded in the end of the process.
This method works every time, if you block all the possible landing spots, but it's not clean at all.

The second way is to have multiple entities being spread.
Well, it works but is not optimal at all. That's because, the bigger area you want to load, the more entities will be necessary. The problem, though, is not having lots of entities, but processing all of them at once. Specially if you plan to keep it loaded by using a 20Hz clock. Don't do that.
To be short, I recommend doing this only if you need to execute a clone/ fill at a big unloaded area. Using as a constant loader might make your computer cry. It also might be a better idea to have multiple /spreadplayers, one at each chunk of the area you want to load, rather than just one command spreading through the whole area.

spreadplayers used to load a 50 block radius area around the 900 900 coordinates. 51 entities were used

Other Loaders
There are a few more ways to load chunks in Minecraft. The more useful are the ones which use Arrows or /spreadplayers, but here are four more if you feel you don't have loaders enough.


The End Gateway
In 1.9, the End recieved a lot of implementations. One of them was the End Gateway, which acts as a teleporter. What is fun is that, when an entity enters it, the destination will be loaded, regardless of what goes through the portal.
The destination coordinates are stored in the end gateway block itself as the ExitPortal tag and, using /blockdata, we can change it to go where we want.
To load a chunk, simply summon an entity at the portal. Sadly, though, the area will unload randomly shortly after and it'll only work with specific coordinates.

Using this is about the same as the Reverse Arrow Method, maybe a little more complicated as there's an extra step of needing to have the gateway block. It's also not possible to keep the chunk loaded, like with an Arrow.


Hoppers
A really simple way to load chunks, being also really limited, is to have a hopper with an item inside at a chunk border, pointing at its adjacent one. The hopper will need to know if there's a container in front of it wanting to recieve the item, for that the chunk in front will be loaded.
For it to work the hopper must be loaded, meaning it's not possible to put it anywhere and hope it works. It acts more as an extention of loaded chunks than a proper loader, nonetheless it is pretty good at doing that.


Redstone Dust
Powering a redstone line instantly will load all of the chunks it is in for a short moment. It's very useful when playing survival, but for map making is not recommended, as it takes a huge space, you need to set it all up first and it's quite laggy from all the block updates, specially if you have a really long section.


Nether and End Portals
When an entity goes through a nether or end portal, the other side will be loaded. End portals are not very useful, as they can only lead to the End of the spawn chunks, which are already loaded; however nether ones can be placed anywhere.
This is a very messy method to use, but it can be useful in survival, like the previous one.
It's normally used at Iron Farms to prevent them from breaking. There's no real gain on using it for map making, though.




Well, that's what I had to talk about Chunk Loaders. I hope you've learned something and, if you know about something that isn't here, leave a comment and let me know!
Thank you for reading as always and see you next time!

The Command Book and Tellraw Menu

Let's lay down the basics to dive into the advanced later on, shall we?


Everything has start. Even those old physics teachers who seem to have been around since the beginning of the universe. And, of course, the Maizuma Creative Server also had one.

The server, today powered by more than 2000 Command Blocks running multiple functions, from the very handy Return to a custom Fill and Clone, recreated to work for non opped players; was also a simple "build wherever you want" type of deal once.
After a while, we (Cass and I) decided to organize everything, and so it was born the Maizuma Creative Server 2!
I love these fancy names.

But now let's talk about what's fun, Command Blocks. Today will be a super simple explanation so we can start covering everything from the basics. There'll be some tricks I used in the end as well.


The Command Book [GFY]
One of the first things that were made was a Command Book so all the members could have access to teleport commands, without the need of giving them OP.
Currently, the Book has most the commands the server offers, together with all the teleports. It's also unique for everyone who has their own plot, allowing them manage it to their liking.
I will talk more about all the commands and the plot system in the future, by the way.

Well, the way you get the Book is by simply looking straight down and jumping once. Also, because we have new members from time to time being added to the Book, players who log into the server will always recieve a new one.

Making you recieve it is very simple.
We need a objective stat.jump, called book, to detect when a player jumps.
Firstly we only want the book to only be given once to a player, avoiding their inventory to be spammed, so if a player jumps and book goes to 1, we will reset it if the player has a written_book in their inventory titled "Command Book".
If the player's score hasn't been reset and they are looking down, all we need to do now is to give them the Command Book.

Now, to know a player has to receive it, I give them a score on a trigger objective. With that, not only they can get it by looking down and jumping, but also through the tellraw menu.

Oh, you can find the commands used here.

Some of the tricks used

Although this is a pretty simple system, I still wanted it to be as efficient as possible.

If you worked with Command Blocks before, you know lag can be a issue if you have multiple of them running at once, so having as little checks as you can will help avoid the problem.

For that, the only constant check we have is if a player has a score on book. Only then the rest of the checks will be executed.

The complication we find is when we want to execute the checks only when the clock finds a true result. We could, of course, use comparators, but it could break if two players would jump one right after the other, reseting the first and leaving the other with their score so the comparator would never turn off.

The solution? An Armour Stand (or an Effect Cloud).

We can execute at players with scores on book, who execute at an Armour Stand located at the command blocks a command to power them.

It's possible to power them on many ways, but the one I've been using a lot since 1.9 is to set an Impulse Command Block with the command /blockdata ~ ~ ~ {auto:0b} to {auto:1b}.

Setting an Impulse CB to auto:1b will power it like you'd to with a redstone signal. Setting it back to auto:0b will simply reset it. We can then link some Chain Command Blocks as we like to the Impulse one.

An Armour Stand used to mark the Command Blocks' position

The Tellraw Menu [GFY]
Going to a block, looking down and jumping, opening the Command Book and then using the command you want can sometimes be a little too much. So, for a faster access to some commands, I made the Tellraw Menu.
On MCS3.0, most of the commands from the Book will also be in the Menu, apart from the direct teleports to players and plots.

The way you access the Tellraw Menu is by looking straight down twice. Doing that will open a short list of commands that you can expand by clicking at [More Options].

The Tellraw Menu, expanded to show more options

Knowing when to show the Tellraw is also very straightfoward.
We will need a trigger objective, called menu. Then all we need is a series of events: the player looks down, menu gets set to 1; they look a little up, menu gets set to 2.
If they look down again, now with menu = 2, the Tellraw will be executed and the score will be set to 3 so the message doesn't repeat over and over.
To show more options, a trigger command will be in the Menu to set the score to 4. Another Tellraw will then be executed and the score will be reset back to 3.
Of course, we also set menu to 0 if the player looks back up.

Again, you can find the commands here.

Some of the tricks used
For the Tellraw Menu to work, the players need to have a score on the menu objective.
Normally, no player or entity starts with a score on any objective. We can use the command /scoreboard players add @a menu 0 to fix that easily.

Now that's pretty simple, but they key is actually when to use the command.
Having it on a clock is unecessary and it would only add lag. The best course of action is to use it only when a players joins the server. Nothing like a stat.leaveGame won't help.

We can detect when a player logs in or out of the game with a simple setup, having a clock testing for all players with a comparator to take its output. Because the comparator outputs a different signal depending of the command block's SuccessCount, it'll update everytime the amount of players online changes, even if it goes to more than 15.
Then all we need is to detect the comparator change, using a BUD, and we can use the command mentioned before.
This can also be used for many other functions, like an welcome message.

A clock testing for all players, connected to a BUD

The same system, now connected to an instant BUD to activate faster

Well, that's about it. I'd like to point out again those were very simple commands and the next ones will be a lot more interesting.
Like the last time, thank you for reading and I hope you continue for the upcoming posts!