MCsim (pre-alpha release)

[CX gamer]

Alright here goes rubber duck problem solving. I have been debugging for way too long.

I have printed all items which were inside the containers...

Code:

{id:"Chest",Items:[0:{id:"minecraft:redstone_torch",Damage:0s,Count:1b,Slot:1b,},],Lock:"",z:0,y:0,x:0,}
Inventory: container.chest
Size:      27
{id:"Hopper",Items:[0:{id:"minecraft:repeater",Damage:0s,Count:1b,Slot:0b,},],TransferCooldown:0,Lock:"",z:0,y:0,x:1,}
Inventory: container.hopper
Size:      5
{id:"Trap",Items:[0:{id:"minecraft:comparator",Damage:0s,Count:1b,Slot:4b,},1:{id:"minecraft:comparator",Damage:0s,Count:1b,Slot:7b,},],Lock:"",z:0,y:0,x:3,}
Inventory: container.dispenser
Size:      9
{id:"Dropper",Items:[0:{id:"minecraft:wooden_button",Damage:0s,Count:1b,Slot:4b,},],Lock:"",z:0,y:0,x:4,}
Inventory: container.dropper
Size:      9
{id:"Furnace",Items:[0:{id:"minecraft:comparator",Damage:0s,Count:1b,Slot:0b,},],BurnTime:0s,CookTimeTotal:200s,Lock:"",z:0,y:0,CookTime:0s,x:5,}
Inventory: container.furnace
Size:      3

...to learn that there are no items in the said container. The NBT tags you see here are just loaded as NBTTagCompound. So I can say for a definite fact that the items get lost between these, which means everything inside the TileEntity.createAndLoadEntity method.

The TileEntity itself gets loaded succesfully, because we get it back and it doesn't print a stack trace. So we know that we can reach the method readFromNBT for each subclasses of TileEntity. I look at TileEntityChest's method in particular, since it's the most stripped down version of my problem, as its only function is to contain items.

• The super.readFromNBT works, because we get those back.
  
• Minecraft's NBT classes all seem to work, because I've pulled the item compound tags out that way.
  
• Nothing is wrong with the size of the array of ItemStack, because I have debugged it up above.
  
• CustomName is not present so we can skip it safely.

I've tried loading items from the working item NBT's, but they return nulls, which means the bug is contained within ItemStack.loadItemStackFromNBT. I try to call readFromNBT, but it returns nulls as well.

Code:

{id:"Chest",Items:[0:{id:"minecraft:redstone_torch",Damage:0s,Count:1b,Slot:1b,},],Lock:"",z:0,y:0,x:0,}
Loading item: {id:"minecraft:redstone_torch",Damage:0s,Count:1b,Slot:1b,}
Loaded item:  null
{id:"Hopper",Items:[0:{id:"minecraft:repeater",Damage:0s,Count:1b,Slot:0b,},],TransferCooldown:0,Lock:"",z:0,y:0,x:1,}
Loading item: {id:"minecraft:repeater",Damage:0s,Count:1b,Slot:0b,}
Loaded item:  null
{id:"Trap",Items:[0:{id:"minecraft:comparator",Damage:0s,Count:1b,Slot:4b,},1:{id:"minecraft:comparator",Damage:0s,Count:1b,Slot:7b,},],Lock:"",z:0,y:0,x:3,}
Loading item: {id:"minecraft:comparator",Damage:0s,Count:1b,Slot:4b,}
Loaded item:  null
{id:"Dropper",Items:[0:{id:"minecraft:wooden_button",Damage:0s,Count:1b,Slot:4b,},],Lock:"",z:0,y:0,x:4,}
Loading item: {id:"minecraft:wooden_button",Damage:0s,Count:1b,Slot:4b,}
Loaded item:  null
{id:"Furnace",Items:[0:{id:"minecraft:comparator",Damage:0s,Count:1b,Slot:0b,},],BurnTime:0s,CookTimeTotal:200s,Lock:"",z:0,y:0,CookTime:0s,x:5,}
Loading item: {id:"minecraft:comparator",Damage:0s,Count:1b,Slot:0b,}
Loaded item:  null

And this is where I had rubber duck's "aha" moment. Inside readFromNBT we see:

Code:

Item.getItemById(par1NBTTagCompound.getShort("id"));

And as far as I know, "minecraft:redstone_torch" is not a short value. I guess the tools are more up to date than MCP, therefore this discrepency. Either way, I'm going to remove this mountain of debugging code and just waiting for MCP to update, rather than make a fragile workaround.