Daeruin

That seems to have done the trick! I thought it might be something along those lines. +1 knowledge.

I'm attempting to add seasons to my mod. I thought I was being clever by registering a new block color handler for vanilla leaves that randomizes the leaf color, so every leaf block has a different color. Each season has its own palette of colors to choose randomly from. The fall leaves look fantastic! I update the leaf block colors every time the season changes by forcing Minecraft to reload the renderers, via RenderGlobal#loadRenderers, in a ClientTickEvent. The issue I didn't foresee is that leaves tend to change color randomly all throughout the day, even without me reloading the renderers. I guess there's something in the client that's trying to look up the block color at certain points. I'm not sure what it is. Was my idea just a bad one? Or is there some way to salvage it? Maybe there's some way for me to ensure the same "random" color is always chosen within the same season for a given block? Or store which color is chosen somehow? Code (I chopped out some of the seasons enum for brevity):

Make your block extend BlockRotatedPillar instead of Block. BlockRotatedPillar has the code to change the orientation of the block depending on which face you click when placing it.

I played around with it for like two hours, and it wasn't working. Then I finally realized all these posts I was looking up on Google were related to 1.12. (And, coincidentally, I realized my OP title said 1.10.2 instead of 1.11.2, which is what I'm actually using. Now fixed.) Other than that, I like this solution because I think I can get around the entire issue by simply overriding the getCollisionBoundingBox method in the new block I create. That would allow me to avoid using the GetCollisionBoxesEvent, and all this other rigamarole. So maybe I'll wait on this feature until I finally update to 1.12. Or play around with replacing it in world gen instead.

Hmm, looks like EntityLiving::navigator is protected, as is the createNavigator method that sets it. That puts a damper on things. I guess that would mean using reflection to access the PathNavigateGround instance. Actually, the reference to the WalkNodeProcessor inside the PathNavigateGround instance is protected, too, so I would have to use reflection again or make my own extension of PathNavigateGround to provide my custom WalkNodeProcessor. The other option you mentioned, overwriting the leaf block, would require ASM, wouldn't it? It seems like another option would be to replace all leaves with a custom leaf class during world generation.

Thanks, I'll start looking into that. How does one provide a custom WalkNodeProcessor? I presume I would extend the class and override some methods (getPathNodeType?). Then what? Do I need to register it with Forge or something?

Jabelar, you prompted me to review my whole system. You're right. I had forgotten that my method for determining whether a block has sufficient support is based on the assumption that the original block is gone. But I've now changed it so I'm passing in a parameter that includes a list of all blocks that have already been identified as unsuitable for support, including the original. This allows me to use BreakEvent, even though the original block isn't broken yet, which is better because HarvestDropsEvent might miss some blocks. So, thanks for the advice and sorry it ended up not being related to Forge.

I've tried using NeighborNotifyEvent. What I'm doing here is implementing gravity on a wider selection of blocks. But because I'm dealing with vanilla blocks, the functionality I need is in my custom methods. So notifying the block's neighbors does nothing for me on its own. I still have to manually check each neighboring block to see if they should fall. And as soon as one falls (the original block gets deleted and turned into a falling entity), it triggers another NeighborNotifyEvent where I check all its neighbors again, and I get into nasty infinite loops that cause stack overflows. At least, I think that's what's happening. It's why I moved back to messing with BreakEvent or HarvestDropsEvent.

So, yeah. I can't override onNeighborChanged in a vanilla block...

Anyone else have an idea?

Thanks for reporting back. The forum would be a TON more helpful if everyone did that instead of treating it like a chat room.

I failed to mention I'm dealing with vanilla blocks.

The point still stands that getArmorInventoryList returns an object of type Iterable, and will therefore never be an instanceof your armor class. You can instead begin iterating through the list and break out of the iteration as soon as you find one instance of your armor. I'll also echo the advice you were already given to add println statements in between every if statement to make sure the statements are true at each step along the way.

I have some block physics functionality that needs to be triggered by a block being broken, but it requires the block to actually be gone. BreakEvent fires when the block will be broken, but right before it's actually deleted, so it's too early for me. The blocks above the broken one won't be able to fall if the block isn't gone yet. HarvestDropsEvent fires after the block is broken, but it only fires if the block is being harvested—so it won't fire if you break a block without a tool of the proper harvest level. It seems like I need something in between the two. I've considered using BreakEvent and just deleting the block myself, but this preempts the block from being harvested. That might be OK. You could imagine the block's drops being crushed by the blocks above it falling. It's probably the better of the two choices. Do you have any other clever ideas, or am I overlooking something?

I have written my own AI tasks before, but the AI tasks themselves don't do the pathfinding calculations. That stuff comes from the RandomPositionGenerator class, I think. Are you saying I need to replace the vanilla pathfinding algorithms? Wouldn't that also entail replacing every AI task that calls for an entity to move anywhere? Sounds like a pain in the butt. It makes me want to consider replacing all vanilla leaf blocks with custom ones.

I've made it so the player, and any living entity, can move through leaf blocks. (I used the GetCollisionBoxesEvent.) However, there's an unexpected result of this. Other living entities seem to have trouble with their pathing when the get next to, or inside of, leaf blocks. They often try to jump on top of leaf blocks. When they fall through, they try to jump again, and they get stuck in a silly jumping pattern. If they manage to get entirely inside some leaf blocks, they just sit there unmoving. Is there some way to fix this? How would I make it so entities don't see leaf blocks as solid obstacles?

Check out Shadowfacts' tutorials for the basics of creating blocks and items. Also check out Choonster's TestMod3 for lots of examples.

Thank you, if I had your reply initially I wouldn't have wasted so much time. I spent a long time trying to figure out how @Holder would help anything. My field does have the @CapabilityInject annotation, I just left it out when pasting into my original message. And yes, the capability is being added by my own mod. So I will simply suppress the warnings and forget about the null checks. Thanks!

I'm relatively new to Java (and coding in general). I tried to read up on the @Holding annotation (couldn't find anything called @Holder) but couldn't figure out how it would help. Indeed my IDE thinks the capability is always null since it's set that way initially in the provider and apparently never changed except during registration, which I guess my IDE doesn't know about. Which makes null checks kind of pointless. In the following example, THIRST_CAPABILITY != null gets highlighted saying the condition is always false. But if I take away the null check, getStorage() gets highlighted saying there's a potential NPE. if (THIRST_CAPABILITY != null) return THIRST_CAPABILITY.getStorage().writeNBT(THIRST_CAPABILITY, this.instance, null); I mean, I know I've registered the capability, so I could just suppress the warning. I guess that's what I'll do unless I hear of anything better.

I recently switched over to IntelliJ's IDE and am now getting a warning that I didn't get before about my player Capability potentially being null. Everything has been working in my testing prior to this. No null pointer exceptions when accessing the capability and such. So I'm curious how and when capabilities can actually be null? Clearly it's initially set to null in the provider class. public static final Capability<IThirst> THIRST_CAPABILITY = null; When it's instantiated, IntelliJ tells me it may produce a null pointer exception. private IThirst instance = THIRST_CAPABILITY.getDefaultInstance(); Everywhere I use getCapability or getStorage, I get another warning about potential NPEs, for example here: IThirst thirstCapability = player.getCapability(ThirstProvider.THIRST_CAPABILITY, null);

Sorry, I linked to the wrong thing. That code goes with an actual tutorial here: https://www.planetminecraft.com/blog/forge-tutorial-capability-system/. Not the greatest, but it's something to help get started. And no offense to whoever wrote Forge's official documentation for capabilities, but it's really difficult to understand for beginners.

There is a tutorial that walks you through creating a mana system using capabilities: https://github.com/mchorse/capabilities/tree/master/src/main/java/mchorse/capabilities

As for tutorials, for the very basics (custom blocks, items, containers) I usually recommend Shadowfacts. Jabelar has a ton of great stuff. Also look up Choonser's TestMod3 and The Grey Ghost's Minecraft by Example for lots of great example code. What you want to do sounds something like the mod Open Terrain Generator. Maybe look it up and see if there's anything useful.

True, but it can be a decent stand-in, depending on what it's for. I've used it in cases where I need to do something when a block breaks, but _after_ the block is actually broken. BreakEvent fires before the block is deleted from the world, which is problematic in some cases.

You need to give us more detail about what you are trying to do.