[1.7.10] Can't mine blocks while setting stack NBT

[HappyKiller1O1]

This is so weird, I am using NBT as a timer and basically while I set it for the hammer I can't mine blocks. It keeps canceling. Here is how I use it:

public void onUpdate(ItemStack stack, World world, Entity entity, int i, boolean flag) { //3600 = 3 minutes
	fixNBT(stack);

	if(!world.isRemote) {
		if(stack.stackTagCompound.getBoolean("AutoRepair")) {
			if(stack.isItemDamaged()) {
				int autoRepairDelay = stack.stackTagCompound.getInteger("RepairBase");

				if(autoRepairDelay < stack.stackTagCompound.getInteger("RepairDelay")) {
					autoRepairDelay++;
					stack.stackTagCompound.setInteger("RepairBase", autoRepairDelay);
				}

				LogHelper.logInfo("Delay: " + autoRepairDelay); //TODO WORK ON AUTO REPAIR

				if(autoRepairDelay == stack.stackTagCompound.getInteger("RepairDelay")) {
					stack.damageItem(-1, (EntityPlayer)entity);

					stack.stackTagCompound.setInteger("RepairBase", 0);
				}
			}
		}
	}
}

 

All I can say is it cancels while it sets NBT. Pretty weird so any help is appreciated.

[larsgerrits]

When Minecraft detects even a slight change in the ItemStack the player is holding, like changing hotbar slot, or changing the ItemStack's NBT, it resets the break timer, and does that animation. I believe Tinkers' Construct fixes this by not changing the NBT when the tool is used.

[HappyKiller1O1]

How exactly would I check if the tool is in use? Is there a method for it in ItemStack?

[HappyKiller1O1]

So I have this to check if the item is in use:

if(player.getItemInUse() != stack) {
						LogHelper.logInfo(player.getItemInUse());

						int autoRepairDelay = stack.stackTagCompound.getInteger("RepairBase");

						if(autoRepairDelay < stack.stackTagCompound.getInteger("RepairDelay")) {
							autoRepairDelay++;
							stack.stackTagCompound.setInteger("RepairBase", autoRepairDelay);
						}

						LogHelper.logInfo("Delay: " + autoRepairDelay); //TODO WORK ON AUTO REPAIR

						if(autoRepairDelay == stack.stackTagCompound.getInteger("RepairDelay")) {
							stack.damageItem(-1, player);

							stack.stackTagCompound.setInteger("RepairBase", 0);
						}
					}

 

But, the Item in use is CONSTANTLY null. How does Minecraft determine if the Item is in use?

[HappyKiller1O1]

What's... reflection? Excuse my ignorance I have seriously never heard that term before.

[coolAlias]

What's... reflection? Excuse my ignorance I have seriously never heard that term before.

Better head to Google then

[HappyKiller1O1]

So, I found this example of reflection here:

http://examples.javacodegeeks.com/core-java/reflection/java-reflection-example/

 

My two questions are, do I have to do EVERYTHING shown in order to retrieve the field and set it accessible? Or, can I just set the class and make it accessible? And, do I have to make a separate reflection class or, can I put the reflection in my Item class?

[Ernio]

If you think you read enough, look at this:

 

List<IResourcePack> defaultResourcePacks = ObfuscationReflectionHelper.getPrivateValue(Minecraft.class, Minecraft.getMinecraft(), "defaultResourcePacks", "field_110449_ao");

 

Example of usage reflection in MC.

And yeah - use ObfRefHelper to make it work after compiling, you need to find correct obfuscated field for one you want to access.

 

Next post will probably tell you where to look for them, as I don't remember now.

[Draco18s]

Better idea:

Rather than counting a timer in your NBT, save a worldTime plus your delay, and wait for the world's time to exceed the time you saved in the NBT.

[HappyKiller1O1]

If you think you read enough, look at this:

 

List<IResourcePack> defaultResourcePacks = ObfuscationReflectionHelper.getPrivateValue(Minecraft.class, Minecraft.getMinecraft(), "defaultResourcePacks", "field_110449_ao");

 

Example of usage reflection in MC.

And yeah - use ObfRefHelper to make it work after compiling, you need to find correct obfuscated field for one you want to access.

 

Next post will probably tell you where to look for them, as I don't remember now.

 

That seemed to work.

 

@Draco18s I would do that but, considering it takes twenty minutes for a full day and night cycle more or less. Wouldn't it only run every twenty minutes?

[HappyKiller1O1]

Well, I used what Ernio said and it works. World time would probably be more efficient but, I think the way I have it now is fine too. Thanks for all the help guys! Couldn't of done it without you.

[Draco18s]

Well, I used what Ernio said and it works. World time would probably be more efficient but, I think the way I have it now is fine too. Thanks for all the help guys! Couldn't of done it without you.

 

Note:

Reflection is slow.  And I don't mean in a "don't do it much" kind of way, I mean in a "don't do it in the onUpdate of any object" way.

 

While I don't think the following description is technically accurate, but it might explain the problem conceptually:

 

Try...catch spawns a thread and waits for it to either crash (catching the exception) or finish executing.

[Draco18s]

While I don't think the following description is technically accurate, but it might explain the problem conceptually:

 

Try...catch spawns a thread and waits for it to either crash (catching the exception) or finish executing.

Not sure what you are saying here. But if it means that try-catch is slow, that's not true either.

Try-catch is basically free. Unless an exception actually happens, which is then quite slow, but that's ok, since it's an exception, meaning it's exceptional that it happens.

 

False.

I had code wrapped in try...catch (a method.invoke call) in a block-update function (ASM injection).

It ran so hilariously slow as to take 10 seconds for water to flow 1 block But /forge tps still reported 20 ticks a second.

Removing the try...catch fixed it.

The only reason i could remove the try...catch was because the calling method was ASMed and the compiler couldn't complain about the unhandled exception involved.

[Draco18s]

Kind of without Internet at the moment, but I'll try and remember when I get home again.