PHAYRIOSIS REBORN CONTINUED - METEOR / IN CONTROL COMPATIBILITY
DEVELOPER MAINTENANCE HISTORY — OPTIMIZATION FOLLOW-UP
Date: 2026-10-11
Project maintainer and mod author: leo_san
Minecraft: Forge 1.20.1 47.4.x, Java 17
Mod metadata version: 0.1.2 (preserved exactly from user-confirmed latest JAR)

BASELINE:
- The exact previous Phayriosis build used for this update is
  Phayriosis-Reborn-Continued-0.1.2-Meteor-InControl-Compat.jar,
  derived from user-confirmed phayriosis-reborn-continued-0.1.2(5).jar.
- Reference mechanism: Spore-Meteor-Compat-0.1.8-TEST(1).jar.
- In Control test target: incontrol-1.20-9.4.6(3).jar.
- Existing persistent marker kept identical: phayriosisreborn:meteor_spawned_v1.
- Existing Mixin patches and registration are not modified in this update.

ISSUES REPORTED / OPTIMIZATIONS REQUESTED:
1. The three In Control Mixins previously checked Entity.getPersistentData()
   on every spawn event reaching the handler; for Forge, this can allocate
   an empty NBT compound on otherwise-unmarked entities.
2. A temporary spawning scope keyed exclusively by EntityType could have
   marked a nested, independently-created entity of the same type.

IMPLEMENTED:
1. MeteorSpawnScope.isMarked(Entity) now retrieves the entity registry key
   first and returns false for every non-Phayriosis entity and for any
   Phayriosis entity type not directly used in meteor impact spawning:
   converted_human, patroller, infester, gory_mass, assaulter, spitter,
   carrier and nucleus. Only the listed types access getPersistentData().
   This is constant-time, no scans, no per-tick hooks, and avoids initializing
   Forge persistent data on nearly all unrelated entities.
2. The meteor-only ThreadLocal context now stores: expected EntityType,
   the exact ServerLevel instance, BlockPos target, MobSpawnType, and a
   single claimed Entity identity. All position/finalize/join observers
   verify matching world, reason (where provided), and proximity (within
   2 blocks X/Z and 4 blocks Y). The first matching entity is claimed;
   subsequent different entities are NOT tagged by the same scope.
   Nested scopes are still stack-based and always cleared in finally.
   Contexts allocate only on meteor entity spawn attempts, never per tick.
3. The original EntityType.spawn(ServerLevel, BlockPos, MobSpawnType)
   invocation stays unchanged, preserving entity placement and finalization.
   Existing event handler priorities, event-bus registration, manifest mixin
   config, and In Control method injections are unchanged. The same marker
   remains persistent across save/reload.
4. The return-value fallback continues to mark the directly returned
   entity, but never adds the marker to a second, conflicting identity.
   This is a defense-in-depth fallback, not a global rule bypass.

ONLY MOD JAR CHANGES RELATIVE TO THE PREVIOUS PATCH:
- Replaced net/mcreator/phayriosisreborn/meteor/MeteorSpawnScope.class
- Added net/mcreator/phayriosisreborn/meteor/MeteorSpawnScope$SpawnContext.class
- Appended this entry to existing long-form
  META-INF/phayriosis-maintainer/PHAYRIOSIS_REBORN_CONTINUED_MAINTAINER_HISTORY.txt
- Added META-INF/phayriosis-maintainer/meteor-incontrol-compat-optimization-0.1.2.txt
No other original code, mod metadata, resources, or configs were changed.

OFFLINE CHECKS COMPLETED:
- Helper Java compiled with javac --release 17; Java major version 61.
- A mock event-flow regression test passed for meteor-created mobs,
  normal same-type mobs, other-mod mobs, and nested same-type mobs at
  another position. Stubbed test is not a running Forge test.
- Classfile annotations, signatures, existing Mixin bytecode, ZIP integrity,
  and bitwise equality of all unrelated JAR files should be verified on
  packaging (see package_refinement.py and verify_output.py).

REMAINING LIMITATIONS / FURTHER TESTS:
- A nested same-type, same-world, same-reason spawn created at essentially
  the identical block position before the intended instance could still
  claim the context; this is a theoretically narrow edge case. Full
  allocation-time identity tracking requires invasive Minecraft hooks,
  and was deliberately avoided for the user's performance and safety goal.
- In Control may not process every event for each spawn path; the fallback
  only tags entities that survive spawning. The entry-event marking must be
  validated in a live modpack at low daycount under In Control deny rules.
- Verify the impact wave and nucleus still appear, natural Phayriosis
  mobs remain restricted by In Control, reload works, and the mod launches
  both with and without In Control. Check latest.log for MixinApplyError.
- Do not distribute stub Minecraft/Forge classes. The compiled JAR includes
  only the revised actual helper class and nested context class, not stubs.
