fix(entity): /effect crashes server on missing player attributes

[MarkPLacer]

Summary

Fixes #1985 — the server crashes when running /effect give <player> minecraft:speed infinite 100.

Root Cause

EntityType::PLAYER has an empty attributes list in pumpkin-data. When a status
effect modifier (e.g. Speed → MOVEMENT_SPEED) is applied, the attribute lookup in
LivingEntity::update_attribute calls .unwrap() on None, causing a panic.

Vanilla handles this gracefully: MobEffect.addAttributeModifiers() does a null check
(if (attribute != null)) and silently skips missing attributes.

Changes

1. Crash prevention: Replaced .unwrap() in update_attribute and get_attribute_base
   with .map_or(attribute.default_value, |a| a.1), matching vanilla's null-safety pattern.

2. Player attribute seeding: Added vanilla-accurate base attribute values for Players in
   LivingEntity::new(), mirroring Player.createAttributes() from the vanilla source:

   • MOVEMENT_SPEED: 0.1 (was falling back to generic 0.7)
   • ATTACK_DAMAGE: 1.0 (was falling back to generic 2.0)
   • ATTACK_SPEED: 4.0
   • LUCK: 0.0
   • BLOCK_INTERACTION_RANGE: 4.5
   • ENTITY_INTERACTION_RANGE: 3.0

Testing

• cargo clippy --all-targets -- -D warnings: zero warnings
• cargo test: 102/102 passed
• Verified attribute values match the decompiled vanilla Java 26.1.1 server source

[Purdze]

hardcoding the player attribute defaults in living.rs is a bit of a workaround, ideally EntityType::PLAYER in pumpkin-data should have its attributes populated properly

the or_insert_with closures aren't needed here since AttributeInstance::new is cheap, plain or_insert would probs work better

[MarkPLacer]

hardcoding the player attribute defaults in living.rs is a bit of a workaround, ideally EntityType::PLAYER in pumpkin-data should have its attributes populated properly

the or_insert_with closures aren't needed here since AttributeInstance::new is cheap, plain or_insert would probs work better

Thanks! Switched to or_insert in 3985dab. Yeah, the hardcoded attrs are a workaround, entity_type.rs is auto-generated so the proper fix would be in the extractor. Kept this PR scoped to the crash fix, but happy to look into that separately.

[CompileRider]

I think the missing-attribute fallback in update_attribute / get_attribute_base makes sense, since avoiding the panic here is the right immediate fix.

What feels misplaced is the if entity.entity_type == &EntityType::PLAYER block in LivingEntity::new(). LivingEntity::new() already initializes attributes from entity.entity_type.attributes, so adding player-only defaults there looks more like a workaround than the real owner fix.

It seems cleaner to populate EntityType::PLAYER.attributes in the generated entity data and let the shared living path stay generic.

[MarkPLacer]

I think the missing-attribute fallback in update_attribute / get_attribute_base makes sense, since avoiding the panic here is the right immediate fix.

What feels misplaced is the if entity.entity_type == &EntityType::PLAYER block in LivingEntity::new(). LivingEntity::new() already initializes attributes from entity.entity_type.attributes, so adding player-only defaults there looks more like a workaround than the real owner fix.

It seems cleaner to populate EntityType::PLAYER.attributes in the generated entity data and let the shared living path stay generic.

Thanks for the feedback! I completely agree. The root cause was that Extractor skipped attribute injection for non-spawnable entities, such as players. I went ahead and modified the upstream Extractor to fetch attributes directly using DefaultAttributes.getSupplier(...), updated the assets, and effectively removed the workaround here. player now flawlessly possesses 31 generated Base Attribute defaults. I'll push the updated assets/entities.json here and submit a PR to Extractor shortly!

[MarkPLacer]

Hold up, I've messed up in the latest commit, I believe

[CompileRider]

Hold up, I've messed up in the latest commit, I believe

that's to learn

[MarkPLacer]

Actually, after looking into it, it was a false alarm on my end earlier... The latest commit in this PR is fine, I believe. The crash fix and the generated player attribute data change are separate from the movement-speed issue I hit while testing. I’m keeping this PR scoped to #1985, and I’ll investigate the speed/modifier behaviour separately