Skip to content

Add foundations for hostile mobs - #611

Open
starwarslevi wants to merge 6 commits into
Steel-Foundation:masterfrom
starwarslevi:hostile-mob-foundation
Open

starwarslevi wants to merge 6 commits into
Steel-Foundation:masterfrom
starwarslevi:hostile-mob-foundation

Conversation

@starwarslevi

@starwarslevi starwarslevi commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Type of change

  • Block implementation
  • Item implementation
  • Command implementation
  • Entity implementation
  • Bug fix
  • New feature
  • Breaking change
  • Refactor / code cleanup
  • Performance improvement
  • Chore / tooling

Description

shared foundation for hostile mobs: goals/targeting, pathfinding, attributes, combat, equipment, spawning, persistence, daylight burning, leash gating, entity conversion

left out on purpose: brain (PR #249), ranged combat (PR #423)

How this was tested

cargo test -p steel-core (2598 passing), clippy clean, fmt + workspace green

Screenshots / logs

Checklist

  • Code builds w/o errors or warnings
  • Self-reviewed the diff
  • Docs updated (if applicable)
  • No leftover debug code / comments

Classes / commands modified:

Additional notes

ur da goat

@github-actions github-actions Bot added the Enhancement New feature or request label Sep 6, 2026
@chocodev11

Copy link
Copy Markdown
Contributor

this one doesnt check peaceful mode?

@chocodev11

Copy link
Copy Markdown
Contributor

uhhm and do conversion failure path preserve passager, vehicle and leashable of the old mob?

@github-actions

github-actions Bot commented Sep 8, 2026

Copy link
Copy Markdown

This pull request has conflicts with the base branch "master". Please resolve those so we can test out your changes.

@coco875 coco875 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall I think that there is a lot of useless or comment that are uselessly long

Comment on lines +231 to +235
/// Vanilla parity: `BlockState.isValidSpawn(BlockGetter, BlockPos, EntityType)`, whose
/// default requires a full UP support face and light emission below
/// [`MAX_MOB_SPAWN_LIGHT_EMISSION`]. Blocks override it for special spawn surfaces
/// (soul sand accepts everything, magma only fire-immune mobs, ...). Consulted by
/// `Mob.checkMobSpawnRules`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

look a bit long

Comment on lines +50 to +52
/// Maximum light emission a block may emit while still allowing mobs to spawn
/// on it, mirroring vanilla `BlockBehaviour`'s default `isValidSpawn` predicate
/// (`state.getLightEmission() < 14`).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sure it can be sorter

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean shorter?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes x)

Comment on lines +28 to +34
/// Vanilla `Attributes.STEP_HEIGHT` default, used when the attribute is absent.
const DEFAULT_STEP_HEIGHT: f32 = 0.6;
/// Vanilla `Endermite.MAX_LIFE`: ticks until the mob discards itself when not
/// persistence-required.
const MAX_LIFETIME: i32 = 2400;
/// Vanilla `Endermite` constructor: `this.xpReward = 3`.
const XP_REWARD: i32 = 3;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does comment it are necessary ?

Comment on lines +87 to +101
/// Vanilla `Mob.convertTo`: creates a fresh `entity_type` mob, transfers the
/// shared conversion state, runs `after_conversion`, adds the new mob to the
/// world, and discards `from` for single-mob conversions.
///
/// Steel registers the new entity *before* transferring state. Vanilla runs
/// `ConversionType.convert` and `AfterConversion` first and then discards the
/// source unconditionally after `addFreshEntity`, with no failure path; Steel
/// instead keeps `from` alive when the world rejects the new entity, which only
/// holds if nothing on `from` (its passengers, vehicle, and leash) has been
/// moved onto `to` yet (documented divergence).
///
/// Returns `None` when `from` is removed, the world is gone, `entity_type` is
/// not allowed on the current difficulty (vanilla `EntityType.canSpawn`), has no
/// registered factory, the created entity is not a mob, or the world rejects the
/// new entity; `from` is left untouched in all of those cases.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a bit too much text

@starwarslevi

Copy link
Copy Markdown
Contributor Author

if anyone wants to resolve the conflicts and comments for me they can--i've been extremely demotivated recently and just feeling pretty overwhelmed with this project, so i don't really feel like i can deal with them right now

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Enhancement New feature or request Merge Conflicts

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants