sblectric

Can confirm.

There is a 1.8.9 version that mods use, and it works fine.

Store the BlockPos in the item's NBT and read it when right-clicking.

Nope, it's not needed. Debug mode is only needed if you're changing some code.

No, this is for having entities spawn naturally in biomes, not in a specific circumstance like qxjl1010 needs.

Yeah, pretty sure that's a bug with shields in particular. I tried doing pretty much exactly that in my Advanced Addons mod, and the "blocking" model would never work, no matter what I tried. To make matters worse, the shield functionality isn't even exposed, so I had to use an event handler to mimic the blocking damage to the shield. Shields are not too easy to extend!

You can either color the stem yourself, or leave it grayscale and color it via an IBlockColor implementation.

Waila does that for even vanilla crops, so I wouldn't worry about it.

Ahh yeah, I can see how putting into an inventory and such could be a bit tricky.

I'm pretty sure it's just reading from NBT, so nothing really hacky here.

I solved my problem. I had to iterate over all the active log4j loggers like so: LoggerContext ctx = (LoggerContext)LogManager.getContext(false); Collection<LoggerConfig> lc = ctx.getConfiguration().getLoggers().values(); for(LoggerConfig c : lc) { c.addFilter(new SpamFilter()); }

You could always wait for the item to be held in the item update method, then when the status changes, write it to the ItemStack's NBT. Then, read that NBT from the ItemStack in the hasEffect method.

It seems that there can only be one log4j.xml file per classpath, and Minecraft's is taking precedence. Is there any way to get around that?

Oh, I see what you're saying. I'll look into it, thanks.

I don't want it to be a static file in the jar, I want it to be configurable. Still looking into the XML format for log4j, I don't know what I'm saying.