Welcome to my latest (and as of right now, only) blog on Planet Minecraft. What is it about? I'm glad you probably didn't ask. Basically, what this blog is for, is for me to talk to you about the technology that drives my latest (and largest) project: Parkour & More. Here, I talk about how I build the map, how I make the buttons work, the redstone powering some of the levels, and, of course, active / in-development command sequences (chains of commands that finish a function.) I'll also be explaining how it works, in some cases, why it works, ways to use it to your advantage, and some of the future possibilities i'll be using in Parkour & More. Each day in this blog will be marked with a heading describing the day and time.

Now that you have a basic understanding of what this blog is about, let me list some color keys that I will be using frequently.
- Orange means that this is a technical term (or one that I'll be using in place of official technical terms) and something that will / has been defined in more detail (likely in each day's Footnotes.) You will only see the first instance of the word colored, after that point, it will be normally colored.
- Teal means this is a location.
- Purple means this is an explanation or feature.
- Red means this is a key detail.
- Blue indicates a name or link.
- Yellow means that this is a personal opinion, not a fact.
- Bright teal indicates a date / timecode.
- Green indicates a heading.
- Bold means that I have placed emphasis on this.

Alright, now you know the color key I'll be using throughout this blog, we can get into something more interesting.

Last Updated: October 18th, 1:55 PM


October 14th, 11:10 AM
How the Buttons Work
As this is the first page of the blog, I'll start with something more basic: How to detect when the player presses the button, then execute the relevant command.
This is very simple; all you need is a bit of Redstone and command knowledge. The only way I know to execute a command without making the player themselves execute the command is using a Command Block which any player can get in Creative Mode with command permission. When the player presses the button, it triggers the redstone line (useful when you need to link a redstone device and a Command Block) which then triggers the Command Block.

Command Chains
What if you don't just need to execute one command? What if you need to execute two or three or even four? There are several different ways of doing this, and they work. However, there is a specific way that you can do it which is clean and efficient, and can fit in a much smaller space.
There is a specific way to do this, and if you don't configure the Command Block correctly, your Command Chain will not function.
Configuring Command Blocks is easy and simple. All you need to do is place it, then right click it. This will open the UI for the Command Block. There are a few buttons: 'Impulse' , 'Unconditional' , and 'Needs redstone.' I will be talking about these in a moment.
Command Chains are simply a line of Chain Command Blocks connected together. To do this, you must first understand how they communicate to each other. On the side of every command block, there is an arrow. This arrow points either up, down, east, west, north, or south. This is the direction that (if one has been placed touching the previous Command Block) the Command Block will 'connect' to the next, allowing you to set up Command Chains using Chain Command Blocks.

Configuring Command Blocks
Having the capability to configure a Command Block is critical to being able to create Command Chains, which form the base of almost every complex command system in Minecraft. It's rather simple.
Impulse: This means that the Command Block will only fire once while it is powered, regardless of any other configuration. Clicking this will change it to Chain, which simply means that the command block can now be used in Command Chains. This also means that it can now be activated by any Command Block correctly oriented. Clicking this button again will change the mode to Repeat, which is self-explanatory. Clicking again will change it back to Impulse.
Unconditional: (This is only valid for Chain Command Blocks, and should not be changed for Impulse or Repeat modes!) This means that the Chain Command Block will execute its command regardless of the previous Command Block's execution result (did it execute or did it fail to?) Clicking this will change it to Conditional, which means the Chain Command Block will only execute its command if the previous Command Block execution result indicates that it was successful. In this mode, if the previous Command Block's execution result is failure, the Chain Command Block will terminate the Command.
Needs Redstone: The Command Block will only be triggered if the Command Block receives a Redstone input (such as a button press) and is required for Impulse Command Blocks to function correctly. Clicking this will change it to Always Active, which means that it will repeatedly trigger, regardless on if there is a redstone input. This is required for Chain Command Blocks and is optional for Repeating Command Blocks. Chain Command Blocks only execute if the previous Command Block is activated, meaning that they will trigger each other if either a Repeating Command Block or Impulse Command Block is the first command block in the Command Sequence and is activated. Only the first Command Block in the entire chain needs to be activated, meaning that Chain Command Blocks do not require redstone (assuming you set them to be Always Active.)

How This Relates to Parkour & More
This is all information that is very important to understanding how my map functions. Everything in this blog will have a connection of some sort to said map.
How does this 'chapter' connect to Parkour & More? These basic Command Block functions and Command Chains allow me to create a sequence that gives the player a reward, teleports them around, all while keeping track of where they are, hiding and showing specific UI elements, and sending messages to them. This would be much harder without the knowledge of how these function.
For example, a basic Command Sequence is shown below.
Impulse Command Block: /tellraw @p "Level Complete!"
Chain Command Block: /give @p iron_nugget 10
Chain Command Block: /tp @ p 000 000 000
Chain Command Block: /setblock 000 000 000 birch_button[​facing=south]

If you don't understand any of that, don't worry. It will be explained in tomorrow's chapter. This is the basic structure of what happens when the player presses the button at the end of the level.
Thanks for reading this chapter, and I hope you come back for more!


October 14th, 3:00 PM
Basic Function Commands
Despite the name of this section, this one is fairly simple. I will be talking about very useful commands that are commonly used throughout Parkour & More.
The most frequently used commands in my map are tellraw, tp, give, and setblock, all of which are basic, yet important, commands.
tellraw: This allows you to send a message to a player / group of players without a name or the [@e] tag at the beginning. This also allows you to format the text in more specific ways which are not described here.
tp: Teleports the player to a specific location. Different from teleport, which allows you to teleport an entity to an entity.
give: Allows you to give an item to a player, such as giving the player 10 iron nuggets for completing a level.
setblock: Sets the specified block to a different one, such as setting a sign to a button after completing a level.
These commands are the most frequently used by me in my map. Each one has its own syntax which is critical to understand, else you won't be able to become proficient at using them. If you are able to understand these, you will be able to apply your understanding to more complex commands, which will be featured in later chapters.

Bossbars
Believe it or not, you're already quite familiar with this if you've ever fought the Wither or Ender Dragon. They are bars that appear at the top of your screen (displaying boss health in Vanilla Minecraft) which changes based on input from the game (such as damaging the Wither; the bossbar will be slightly depleted.) However, they also provide a very useful feature for mapmakers with command knowledge. Bossbars are a powerful, and flexible, tool for us to use to display all sorts of data. In Parkour & More, the most common use for the bossbar that you will see is Sector progress. Every time you complete a level, it gets filled up slightly more. Doing this is simple, with almost no setup required.
For this section, I will be using the custom bossbar for Sector 1 progress.
When setting up a new bossbar, the first thing that you need to decide is what the name and ID is going to be. If you're going to have one or two bossbars, it might be wise just to use numbers or short names. However, if you're going to be using a lot of bossbars in your map, it would be wise to use a longer ID with more description. For example, the bossbar ID for Sector progress, for Sector 1, is quipnytherum:sector1progress. It's short enough, yet descriptive enough, that I will be able to understand its function, where it is used, and know why it is required, just at a glance. For a long list of bossbars, this is critical to keeping track of your bossbars. This sort of descriptive name will also return later, when we are talking about much more complex commands. To create a bossbar, do /bossbar add [​ID] [​Name]. The ID is only visible to you in the command toolbar, but the Name is visible to the player when the bossbar is visible.
Once you do this, the bossbar is created. Now, to make it visible to you. Run /bossbar set [​ID] players @p, then run /bossbar set [​ID] visible true. An empty bossbar should show up at the top of your screen. You can change the style, color, max value, value, visibility, and players. When making a map that you won't be the only one using it, you should set up a command block with the set players @p command so they are automatically added to the bossbar, enabling you to show and hide it at will.
What if you want to change the value? You can directly change it, but it would be advisable to use Command Blocks so that it is automatic. In the Command Block, type /bossbar set [​ID] value [​value.] By default, the max value is 100. This knowledge allows you to display more information in a much more stylish way then just having it appear in the chat.

Tellraw
This command is very, very useful to mapmakers, as it allows messages, such as quest info, to appear in chat without obscuring vision. It's also a lot less complicated than bossbar, at least, when you aren't stylizing it using advanced syntax.


The basic syntax is as follows: /tellraw [​destination entity, @p is recommended] "[​message]"
If you wish to add whitespace (grayspace?) in between tellraw messages, simply add spaces between the quotes (" ") and it will be generated blank.

That's all I've got for now. If you want to know more, please PM me or wait for tomorrow's chapter to come out!



October 18th, TIME
First off, let me say I'm sorry for not updating this sooner. I've been really busy between my map and my personal life.

Data
Now, we're getting more complicated. The data command is very useful for when you need to keep track of... data. For example, you can use command blocks to edit and delete data, then have command blocks react in a specific way based on what's in the data.

I will not be going into what I plan on using this for in the future, but I will be telling you how it is used in my map.

An example of how I use the data command is used right when you spawn. When you load the map and spawn, you appear in a chamber with a gateway and two pads, which, when stood on, send a single chat message will be sent to the player. To do this, two command blocks are required. A repeating command block set to Always Active, set to the command: execute at @e[​dz=0,dy=2,dx=0] run execute unless data quipnytherum:info.map used run tellraw "[​message.]" The chain command block, set to always active and conditional has the command: data storage modify quipnytherum:info.map used value true. (Note: The syntax might be incorrect in this case, as I am typing this from memory. I will update this with the correct syntax later today / tomorrow.) This will set the data to used, meaning that the repeating command block will only execute once. This can be used in multiple different ways, but the most common in Parkour & More is for sending messages and keeping track of advancements.

Teleportation Gateways
With the latest release of my map, the buttons to teleport have been replaced with gateways, which when stood in, teleport the player instantly. How do they work?

These 'Teleportation Gateways' are simple, utilizing the tp command and execute command. They detect when a player is standing on the beacon, then instantly teleports the player to another location. This is detected using the following command:

execute at @e[​dz=0,dx=0,dy=2] run tp @p # # #

This won't work unless the command block is constantly active, so why doesn't it just teleport the player randomly? This doesn't happen because of the NBT data tags attached to the '@e', "@e[​dz=0,dx=0,dy=2]." What do these mean? dz is the distance from the command block on the Z axis. The dx and dy tags are similar, detecting distance on the X axis and Y axis respectively. This is different from the distance NBT tag because it only detects distance on a specific axis, instead of in a sphere around the command block.
A more detailed NBT chapter will be released later.

Execute
You've heard me talking about this command quite a bit throughout this blog, but I have yet to explain it in more detail. However, this section is all about the Execute command.

The execute command allows you to run other commands in a much more sophisticated way, and allows you to add execution criteria. This is extremely useful when you need to check to see if the player has done something or has entered a location, or to check to see if the entity meets certain requirements (such as an arrow hitting a player and exploding, and not exploding if it hits a mob...)

For example, you can check to see if a player is in a certain radius to the command block before it sends a message, like so:

execute if @e[​distance=..100] run tellraw @p "[​Message]."

However, this will execute if any entity enters the bubble, which is less than ideal. However, this is easy to fix using another NBT tag. Modifying our command to only execute if a player enters the bubble changes it to look like this:

execute if @e[​distance=..100, type=player] run tellraw @p "[​Message]."

As you can see, we added a 'type' NBT tag, which will allow the command to ignore entities unless they are players.

This is a basic glance at the execute command. Later, I will release a section dedicated to the syntax and usage of this command.

Alright, that's all I have time for today...