mmcmain

I was following Shadow's tutorial here: https://shadowfacts.net/tutorials/forge-modding-1102/tile-entities/ So there is a problem using NBT inside of a TileEntity? If so that would explain it. My class at the time of my stuttering test was quite literally his TileEntityCounter without the increment/decrement behavior on it when you clicked. The only other differences I had were variable names. When I used that TileEntity as the product of my OreGen I got the bad stuttering. When I switched it to a block I got none. Hence my assumption at the time that the NBT data of 10's of thousands of blocks might be the culprit. This is my current TileEntityOre class. I have not tested populating the world with these though. package com.mmcmain.hardcoremining.block; import net.minecraft.nbt.NBTTagCompound; import net.minecraft.tileentity.TileEntity; import java.util.Random; public class TileEntityOre extends TileEntity { private static final int DEFAULT_ADDL_DROPS = 160; private static final int DEFAULT_MIN_DROPS = 40; private static final String NBT_TAG = "oreCounter"; Random random; private int oreCounter = -1; public TileEntityOre() { random = new Random(); oreCounter = getDefaultOreCounter(random); markDirty(); } @Override public NBTTagCompound writeToNBT(NBTTagCompound compound) { compound.setInteger(NBT_TAG, oreCounter); return super.writeToNBT(compound); } @Override public void readFromNBT(NBTTagCompound compound) { oreCounter = compound.getInteger(NBT_TAG); super.readFromNBT(compound); } public void setOreCounterForDepth(int depth) { oreCounter += additionalOreCounterForDepth(random, depth); } public static int estimateOreCounterForDepth(Random random, int depth) { return getDefaultOreCounter(random) + additionalOreCounterForDepth(random, depth); } public static int getDefaultOreCounter(Random random) { return random.nextInt(DEFAULT_ADDL_DROPS) + DEFAULT_MIN_DROPS; } public static int additionalOreCounterForDepth(Random random, int depth) { int oreCounter = 0; if (depth >= 128 && depth < 255) oreCounter += (random.nextInt(DEFAULT_ADDL_DROPS/4)); else if (depth > 24 && depth <= 50) oreCounter += (random.nextInt(DEFAULT_ADDL_DROPS/2)); else if ( depth > 0 && depth <= 24) oreCounter += (random.nextInt(DEFAULT_ADDL_DROPS)); return oreCounter; } public void setOreCounter(int amount) { oreCounter = amount; markDirty(); } public boolean hasOre() { return oreCounter > 0; } public int getOreCounter() { return oreCounter; } public int reduceOre() { return reduceOre(1); } public int reduceOre(int amount) { oreCounter -= amount; markDirty(); return oreCounter; } }

[removed redundant post]

Hello, I have implemented a new ore type that requires me to use a TileEntity due to my need for NBT data. When I started the project, my initial approach was to use this TileEntity class as in my oregen. However I discovered that when I flew around in creative I got a lot of stuttering. This led me to assume that my stuttering was the serializing in and out of my blocks as I moved around - despite the fact that my NBT was a single integer. So after some work I have since redesigned the system so I use basic blocks that instead know how to convert themselves into the proper TileEntity when someone or something attempts to harvest them. So far this all works great and there is no measurable impact on performance. As I move to the second phase of design I see a need to make a few changes to my Block class to handle more edge cases. Before I go down that path I thought I would check to see if my assumptions are correct. If I had a TileEntity that had a single integer as NBT and populated it as prolifically as vanilla ore am I correct in assuming this would have a demonstrable impact on performance? I knew a lot less about the mod API's than I do now and there is still much I don't know so I want to be sure my assumption is correct. If my performance issue was likely related to something else then I would prefer to track that down and use the TileEntity as my ore directly. Thanks.

Ok thanks. I just realized that I should change: if (toolDamage >= playerTool.getMaxDamage()) player.inventory.removeStackFromSlot(player.inventory.currentItem); to if (playerTool.getItemDamage() >= playerTool.getMaxDamage()) player.inventory.removeStackFromSlot(player.inventory.currentItem); because if I update to 1.11+ where the fix is then I would potentially be destroying a new tool if someone was using a mod that replaces broken items on your hotbar.

Sorry should have noted the version in my original post. Just updated that. 1.10.2-12.18.3.2511 At the time I started it was the latest "release" for 1.10.2 but I haven't checked in a few days.

Forge 1.10.2-12.18.3.2511 I have a custom block with custom harvesting behavior. I override onBlockDestroyedByPlayer and do a bunch of checks on the block. One of them is applying more than typical damage to the tool being used. In my onBlockDestroyedByPlayer I do not pass the event up unless the block in question is not mine. I had thought damaging the tool would be as simple as calling: playerTool.damageItem(toolDamage, player); However although this does damage the tool, the tool is not removed when durability reaches zero. I assume because there is some additional cleanup code handled somewhere that I am not calling. Instead the behavior is that the stack count goes to 0, the icon is still rendered, the durability looks graphically to be 0 and then the tool can be used again from scratch gaining a new durability setting on a new use. I have searched pretty extensively and can't find anything related to my issue. If anyone has any insight that would be greatly appreciated. -- Before posting this I figured-out the answer. Leaving it here in case anyone else runs into the same issue. I had to add the following: if (playerTool.getItemDamage() <= 0) player.inventory.removeStackFromSlot(player.inventory.currentItem);