rene_z
Assigned
Reported
Comments
I get the same error when I try to create a world. Converting my user account to a local account (not synched with my Microsoft account) doesn't solve the issue.
However, every time I try to create a world a folder is created at this location:
C:\Users\<Name>\AppData\Local\Packages\Microsoft.MinecraftUWP_<some string>\LocalState\games\com.mojang\minecraftWorlds
The folder name seems to be base64 encoded and its only contents are an empty folder named db. Maybe that helps to determine when in the creation process it gets stuck, as I couldn't find any log files that would help.
I get the same error (worldError.IO) on the Windows 10 edition, which seems to be the same codebase as the pocket edition.
Can easily be observed at 0, 0 even with normal FOV.
Dig a hole in the ground and teleport exactly at 0.0, 0.0 (/tp 0.0 65 0.0), you will see the chunk sections disappear on the side of the screen.
Also this is in no way intended, because that would imply that they wanted it to work this way.
At most this is a "Won't fix" if they don't want to bother, but it's not that this is impossible. The calculation of the visible chunk sections is just a bit off when standing on chunk borders and/or with a higher FOV.
This should only happen for natural spawns. Spawn eggs and /summon are basically used by mapmakers and server admins only. A random amount of entities spawning would just mess things up.
Also happens with /summon
Confirmed in 12w27b
Only happens in certain directions.
Can cause an infinite loop when the output updates the repeater itself from a certain side.
Video explanation:
https://www.youtube.com/watch?v=Sjr_FS6eaLI
Also happens when toggling some of the comparators (the ones that point at another comparator).
This happens because the block gets updated, notices that it shouldn't float in air, drops its item and gets immediately reset by the debug world. Then the new block gets updated on placement, causing an (almost) infinite loop. Sometimes you can break out of the loop, sometimes you can't.
A solution would be to automatically disable block drops in a debug world or not letting the player interact with any blocks (although accessing chests etc. would be useful when this is used for testing resource packs).
Also, Mojang already knows about that "bug":
"Added new world generator for debugging, useful for resourcepack makers (hold shift and cycle through “World Type” to select it. Spectator mode recommended, it may crash otherwise.)" (https://mojang.com/2014/06/minecraft-snapshot-14w26a/)
The issue occurs because of the way the data IDs work.
Each double plant contains a bit for upper or lower, the additional bits are used for variant on the bottom half and orientation on the top half.
This means that the top half alone can't "know" their variant.
You can observe this with the debug screen (F3) and looking at the data in the top right when aiming at the top and bottom half of a double plant.
This issue will probably be resolved when the new block state mechanisms are fully implemented and there can be stored more information per block.
Confirmed in 14w04b, the orientation gets set to 0.
Well, I searched for teleport and orientation, from which the latter isn't in the other bug report. Position isn't quite the correct description of the bug.
512-packs are 4-times bigger than 256-packs and therefore need 4 times as much RAM.
Also you need a better CPU and/or graphics card for 512-packs to work.
It's not Minecraft's fault, it's your computer.
It works as intended. The output is only updated, when the command runs again. And that only happens, when the command block recieves a redstone signal, not when it loses signal.
Confirmed. Sometimes they are instant, and sometimes they have a delay of ~1/2 tick or something between.
Seems to be related to coordinates.
Can't reproduce.
Works just fine for me.
Steps:
Place a piston.
Place a block in front.
Place a redstone block 2 blocks behind the piston.
Place a torch at the redstone block to give the piston a 1-tick pulse.
Works as intended.
Toggled comparators have the output (A - B), but only when B is inputted with a comparator (or in your case repeater).
Works as intended.
This has been since ... ever.
You don't swap the item stacks, you fill up the clicked item stack with the items in your hand.
Can't reproduce, works fine
It doesn't work with lapis either, probably for the same reason: The blocks are to cheap
I'm not sure why this Bug was closed, since it is not a duplicate of MCPE-7623. It is an entirely different error and doesn't even mention "Bad File Number".