Let's look at your data tag here carefully.
{
Item:
[
id:"minecraft:written_book",
Slot:0b,
Damage:0s,
Count:1b
}
]
}
In this expanded form, you can immediately see that something is odd about your parentheses. There is a closing curly bracket without a partner. You'll have to add {
before id
(which is the first tag inside the item tag). Generally, when something is wrong, expanding the command over multiple lines and indenting properly at every layer is a good idea to catch these type of errors.
Secondly, the tag containing the item tags for chests is called Items
, plural (cf. the wiki).
In total, the data tag needs to be
{
Items:
[
{
id:"minecraft:written_book",
Slot:0b,
Damage:0s,
Count:1b
}
]
}
Or compacted for easy copy and paste:
{Items:[{id:"minecraft:written_book",Slot:0b,Damage:0s,Count:1b}]}
If your players are moving quickly through new terrain so that the server has to create lots of new chunks this can happen. For example, one way to aggravate this issue is to get several players riding horses through previously unexplored territory.
The issue can be aggravated by having players that use client-side cheat mods that let them travel super fast. I have watched a Minecraft server crash because a player was running so fast through previously unexplored territory that the server started reporting being 10s of thousands of ticks behind.
One side effect of the server losing ticks: A player may break a block, only to see the block re-appear. I have played the game with a server console open and have noticed that when the server is lagging badly, sometimes I might have to dig the same block multiple times to actually get the block in my inventory.
In my case, I only had 3-6 players on the server at the time. The server is installed in a virtual machine, and I was able to reduce the occurrence of the problem by giving the virtual machine access to more processor cores.
Another mitigation technique is to convert the server to a Bukkit/Spigot server and use a mod called NoCheatPlus. It is able to prevent players from using client-side cheats that let them move faster than the game intends for them to move. I found it relatively easy to convert my server to a Spigot server and to import my existing world into it.
Though broken blocks re-appearing as if not broken is a specific symptom, from a better perspective, what appears to happen is that the client allows the player to perform some action and assumes the server will keep up, but then the game "rewinds" as if the action occurred during the lost ticks lost on the server. As a result, lost ticks can manifest in various other ways (i.e. a walking/running player may warp back to a point where they were previously located).
Best Answer
There are at least four possible causes for this issue.
Firstly, let's dissect the syntax of the
/fill
command, though, with focus on thereplace
feature./fill x1 y1 z1 x2 y2 z2 block_type_1 replace block_type_2
/fill
- the command. This tells the game what feature it should execute.x1, y1, z1
- the coordinates of the first corner. This tells the game where it should start filling.x2, y2, z2
- the coordinates of the second corner. This tells the game where it should stop filling.It will fill every block with the coordinates of any x between x1 and x2, any y between y1 and y2 and any z between z1 and z2.
block_type_1
- this tells the game what block you want to fill this are with. This is the block that will be placed on the fitting coordinates after passing through the additional, optional arguments.replace
- the additional optional argument. This tells the game that it should only replace blocks of a certain type. This argument has no effect without including the next one.block_type_2
- this tells the game what block type you want to be replaced. This is the block that will be replaced byblock_type_1
if it has fitting coordinates.Now, let's take your command as an example and say what it does by running it through the list I've compiled.
/fill ~50 ~1 ~50 ~-50 ~-1 ~-50 minecraft:grass_block replace minecraft:jungle_wood
x1
=~50
y1
=~1
z1
=~50
x2
=~-50
y2
=~-1
z2
=~-50
block_type_1
=minecraft:grass_block
block_type_2
=minecraft:jungle_wood
This tells the game that it should fill all blocks that are within 50 blocks on each horizontal axis and 1 block on the vertical of the player, with blocks of type
minecraft:grass_block
, but only if the block was of typeminecraft:jungle_wood
before this command was executed.In short, it means it replaces all jungle wood within the cuboid with grass blocks.
Now that we know exactly what the command does when executed, the next step is to troubleshoot.
Here are the possible reasons why the command doesn't work as expected.
1. There might be no blocks of this type in that area
Check if there really is jungle wood within the cuboid to be replaced with grass blocks. Try:
Checking your command. Are you sure you want to replace jungle wood with grass blocks, and not the other way around?
Using the testforblocks command to see if there are blocks of that type in the area.
2. The command might be used by a plugin, preventing it from working
If you are playing on a multiplayer server with plugins installed, one of the plugins might include a
/fill
command that functions similarly to the Minecraft version, however produces a different result.If this is the case, try executing the command with the prefix
minecraft:
instead. (/minecraft:fill ...
)3. Your installation of Minecraft might be corrupted
Despite this being extremely unlikely, if no other solutions work, it is worth trying to reinstall Minecraft, as during the installation, an error might have occured.
4. Your installation of Java might be outdated or corrupted
This option is still highly unlikely, however if the problem persists, try updating or reinstalling Java on your device. Stay away from development/unstable builds as they might have some mistakes/typos in them.
Only download Java from the official website.