2012-03-21 14:36:28 [WARNING] Failed to handle packet: java.lang.NullPointerException
java.lang.NullPointerException
at org.bukkit.craftbukkit.event.CraftEventFactory.callBlockBreakEvent(CraftEventFactory.java:548)
at net.minecraft.server.ItemInWorldManager.breakBlock(ItemInWorldManager.java:208)
at net.minecraft.server.ItemInWorldManager.dig(ItemInWorldManager.java:102)
at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:626)
at com.minecarts.familyjewels.NetServerHandlerHook.a(NetServerHandlerHook.java:23)
at net.minecraft.server.Packet14BlockDig.handle(SourceFile:43)
at net.minecraft.server.NetworkManager.b(NetworkManager.java:229)
at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:118)
at net.minecraft.server.NetworkListenThread.a(NetworkListenThread.java:78)
at net.minecraft.server.MinecraftServer.w(MinecraftServer.java:554)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:452)
at net.minecraft.server.ThreadServerApplication.run(SourceFile:490)

Caused by breaking obfuscated blocks too quickly (ala cleanroom)

Does the block have to be obfuscated (eg it appears as stone) and breaking those too quickly? Or does it happen with breaking an obfuscateable (eg diamond ore) block too quickly?

It was happening on stone bricks that were obfuscated. He was tearing down a big pile of stone bricks really quickly and kept getting DC'ed when that NPE was thrown, I assume because he was hitting an obfuscated block before it deobfuscated itself.

Yeah... I'll look into it here as soon as I can. I do question if FamilyJewels should only hide ores in certain worlds.. eg obfuscating things in the clean room might be counter-productive to certain builds / testing / stuff? Although it might not be worth the overhead of checking the worlds... although the check would be minimal

Yea, I imagine a world check would far less intensive than looping through all blocks in a chunk packet. I wish there was a better way to solve it than configuring which worlds to obfuscate. :(

Another option is to do a permissions check on the player, and set the permissions per world.. eg the default group has a permission for cleanroom to ignore ore obfuscation, and every other world shows it... but how efficient is a permissions check vs a world check?

I doubt you'd need to worry about only doing it once per packet.

Sounds good, I'll add a permissions check and see if it helps solve this issue. Might still be unrelated such as packets of block breaking arriving in different order and it's attempting to obfuscation a block which is AIR (eg null internally). Not entirely sure the BlockType I'm fetching is thread safe... so some investigation should be done anyway

Not sure if related, but I got a similar DC with matching NPE but no stacktrace. Happened when I was hitting some leaves while in creative mode, none of which were obfuscated. About the 6th or 7th block break, I instantly DCed with an "Internal server error" message and the NPE is from a packet handling failure...so I'm thinking probably the same root cause.

I wonder though if the stacktrace only reports FamilyJewels because we're hooking ALL player NetServerHandlers, so the exception has to travel through our hooked NSH. Could be a Bukkit issue instead of our own?

Mmm, perhaps. Although this seems to only happen in creative mode -- and I think that might be the issue. Right now I listen for when a player punches a block to update the blocks around it, and uncover any hidden ores.

I think there might be a fundamental issue with that + creative mode, so that as you're breaking blocks very quickly, it's trying to mark them dirty in some unsafe way and update the client with some null blocks thus causing the stack traces.