[1.11.2] Let mobs walk through leaves - weird pathing issue

[Daeruin 24]

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? 

Edited January 19, 2018 by Daeruin
Correct Minecraft version

[KittenKoder 6]

I think you need to override the AI for it to work. 

[xorinzor 1]

Like Kitten said, you will need to modify their AI Pathfinding since that code still assumes leaves are a solid block and as such won't stop to reach their PathPoint until achieved (resulting in the jumping behaviour).

[Daeruin 24]

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.

Edited January 15, 2018 by Daeruin

[Daeruin 24]

Anyone else have an idea?

[diesieben07 7696]

You will need to change the PathNodeType for leaves, which requires either a custom WalkNodeProcessor (and other NodeProcessor implementations probably) or you overwriting the leaves block overriding getAiPathNodeType.

[Daeruin 24]

22 hours ago, diesieben07 said:

You will need to change the PathNodeType for leaves, which requires either a custom WalkNodeProcessor (and other NodeProcessor implementations probably) or you overwriting the leaves block overriding getAiPathNodeType.

 

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?

[diesieben07 7696]

23 minutes ago, Daeruin said:

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?

Yo ultimately need to change the reference to the WalkNodeProcessor instance inside the PathNavigateGround instance present on most living entities at EntityLiving::navigator. You probably need to use EntityJoinWorldEvent for that.

[Daeruin 24]

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. 

Edited January 19, 2018 by Daeruin

[Draco18s 2414]

16 minutes ago, Daeruin said:

The other option you mentioned, overwriting the leaf block, would require ASM, wouldn't it?

No, just create your own leaf block and register it with the vanilla ID

[Daeruin 24]

1 hour ago, Draco18s said:

No, just create your own leaf block and register it with the vanilla ID

 

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.