Skip to content

Mob AI: vanilla parity pass on the existing goals - #3095

Open
TheDarkSword wants to merge 7 commits into
Pumpkin-MC:masterfrom
TheDarkSword:fix/goals-and-selector
Open

Mob AI: vanilla parity pass on the existing goals#3095
TheDarkSword wants to merge 7 commits into
Pumpkin-MC:masterfrom
TheDarkSword:fix/goals-and-selector

Conversation

@TheDarkSword

Copy link
Copy Markdown
Contributor

Went through every goal we already have against the vanilla sources and fixed what diverged. No new goals here, that's a follow up.

Goal framework. TargetingConditions never ran its selector, the combat check only had the "no targeter" branch (so peaceful applied to every target, and canAttack/isAlliedTo were missing), WrappedGoal did not forward isInterruptable, canContinueToUse defaulted to false instead of canUse(), target searches filtered the nearest candidate instead of picking the nearest matching one, and TargetGoal had no targetMob fallback. Teams are now readable for any entity and not just players, so the ally checks work.

Goals that did nothing. Turtle egg breaking, blaze movement and fireballs, skeleton strafing, villager trading and panic were stubbed or structurally wrong, and the ranged goals had line of sight hardcoded to true.

Timers. A few goals ran at half or double the vanilla duration, mostly reducedTickDelay vs adjustedTickDelay, or overriding requiresUpdateEveryTick where vanilla does not.

Everything else. Small differences found one goal at a time: selector ordering, FollowParentGoal picking the wrong parent, MoveToBlockGoal measuring from the block corner, SwellGoal reading a live target, OpenDoorGoal, TemptGoal scare handling, HurtByTargetGoal alerting, mobGriefing on sheep, breeding experience.

RandomPos and GoalUtils. Ported those two plus DefaultRandomPos and LandRandomPos, so strolling, panic, fleeing and raid pathing pick a destination the navigation can reach instead of any random offset. Line of sight results are cached per tick like Sensing does.

Why the raycast fix is in here. World::raycast treated a shapeless block as a full cube, so it always reported a hit on the block the ray starts in, normally air, and never got past the origin. It regressed in 0d55aa5. I only found it because it makes every line of sight check in this PR silently do nothing, so splitting it out made no sense.

Target conditions ignored their selector, goals could not stay non-interruptible, target searches hid valid targets, and a few timers ran at half or double speed.
Turtle egg breaking, blaze attacks, skeleton strafing, villager trading and panic were all incomplete or stubbed out.
Small logic differences found going through each ported goal against the vanilla source.
Strolling, panic, fleeing and raid pathing now pick a destination the navigation can actually reach instead of any random offset.
Also moves the triangular sampling onto the rng, where it belongs, instead of a helper in the blaze goal.
A shapeless block was treated as a full cube, so every raycast reported a hit on its own origin and nothing could ever see anything.
Several goals ask about the same target every tick, so they were each paying for their own raycast.
@RoosterBooster007 RoosterBooster007 added bug Something isn't working entity Non-player entity behavior, metadata, tracking, attributes mobai Mobs and AI refactor Clean up, clean up / Everybody, everywhere labels Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working entity Non-player entity behavior, metadata, tracking, attributes mobai Mobs and AI refactor Clean up, clean up / Everybody, everywhere

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants