The /fill, /clone, /setblock, and /testforblock commands issue an error message if any part of the target area is outside the render distance. I thought it was saying that my coordinates were outside the world limits (which should be infinite) or that I couldn't use a target area that had ungenerated chunks, so I spent a lot of time and effort forcing chunk generation and moving the player around between executing command blocks. The message is misleading and I would argue it's an error. A better message would be something like "Cannot xxx blocks outside of the currently rendered part of the world".
Original description:
Several commands, including at least /fill, /clone, /setblock, and /testforblock, sometimes incorrectly issue the message "Cannot <xxx> blocks outside of the world" when given simple absolute coordinates that definitely are within the world limits.
"<xxx>" varies with the command and can be at least "place", "test for", or "clone". It seems obvious the commands are using a common validation procedure for the coordinate arguments, and this procedure is incorrectly failing the validation. However, a given set of coordinates will succeed sometimes and fail other times, and the effect is reproducible using the following test case ON MY COMPUTER.
Steps to reproduce:
1. Create a new flat world.
2. Teleport to (0, 4, 0).
3. Enter the command: /fill ~127 ~ ~ ~127 ~ ~ dirt
Observe that the result is "1 blocks filled".
4. Enter the command /fill ~128 ~ ~ ~128 ~ ~ dirt
2. /tp 0 4 0
3. /setblock 0 3 0 gold_block (to ensure the chunk is generated)
4. /tp 480 4 0
5. /setblock 0 3 0 diamond_block
> The error message is displayed
6. /tp 416 4 0
7. /setblock 0 3 0 diamond_block
> The block is placed
8. /tp 464 4 0
9. /setblock 0 3 0 iron_block
> The block is placed
10. /tp 480 4 0
11. /setblock 0 3 0 diamond_block
> The block is placed
Notice that steps 5 and 11 are placing the same block at the same location from the same player position, but that step 5 fails while step 11 succeeds.
What I found is that once the /setblock fails, it will consistently fail until I get to within 416 blocks (26 chunks?) of the target coordinates, and once it succeeds it will consistently succeed as I move farther away until I move 4 or more chunks in one jump.
These steps might not reproduce the problem on another device. The steps may be Windows 10 specific, or even specific to my computer, though I expect other Windows 10 computers with relatively limited memory could reproduce it with specific distances that might be different from mine. The reason I say this is that I have a hunch this problem is dependent on the destination chunk being unloaded, which would vary with the amount of available memory, and it might even be dependent on the specific memory management algorithms in use, which are often platform-specific.
Linked issues
is duplicated by 1
relates to 1
Comments 6
May be a duplicate of MCPE-19588.
I found the same issue when attempting to clone across several thousand blocks. Obviously setting the render distance to max isn't going to help me actually get the blocks from one place to the other in such a large distance.
An actual work-around is to use /tickingarea add for either the destination or source (or both). Then you can use /clone (and I assume any other affected commands as well). If you no longer want the area to be kept ticking after cloning, just remove the area once complete.
As of 1.5.3, this problem seems to have gone away.. If anyone is still experiencing this issue, please comment with your current version.
Experiencing this bug with the /clone command on a Realm in 1.14.60, trying to clone something from almost 2k blocks away.
As a workaround, those who only need to use these commands for a limited time can increase theirr render distance to include the target area specified in the command. The render distance is measured from the player or command block that executes the command.