PHAYRIOSIS REBORN CONTINUED - DEVELOPMENT HISTORY
RELEASE: 0.1.3 - METEOR ELITE GUARD REINFORCEMENTS
Date: 2026-10-11
Maintainer/author: leo_san
Target: Java 17, Forge Minecraft 1.20.1 47.4.x

SOURCE AND BASELINE
- Built exclusively from Phayriosis-Reborn-Continued-0.1.2-Meteor-InControl-Compat-Optimized.jar, which the user confirmed works in-game.
- This JAR is the authoritative base regardless of any previously named versions from other conversations.
- An earlier message was misunderstood as asking for more defensive software checks. The user explicitly corrected this: more GUARD MOBS around the meteor, specifically stronger Phayriosis entities, and version 0.1.3. No additional software guards were added.

CHANGES FOR 0.1.3
- Expanded only the existing spawnImpactInfected exterior spawn pool from 20 requested spawns to 26.
- Six new meteor exterior defenders: 2 primal_hunter, 2 primal_assaulter, 1 primal_tank, 1 gory_beast.
- All six use the same proven random angular ring positioning, surface heightmap, normal EntityType registration, and MeteorSpawnScope.spawn code path as the original 20 exterior defenders.
- The six additional defenders spawn once per meteor impact, at the existing 102-tick post-impact wave, not continuously or every game tick. The guardian Nucleus spawning at 108 ticks is unchanged.
- Expanded MeteorSpawnScope.isMarked() fast-reject registry whitelist with four corresponding Phayriosis entity IDs, so the persistent marker phayriosisreborn:meteor_spawned_v1 is honored by the existing In Control Mixin for these meteor-created elites. Natural/other spawns of the same mob type remain under In Control.
- Updated META-INF/mods.toml version from 0.1.2 to 0.1.3. Author remains leo_san.
- Updated embedded impact source reference to describe the new wave and the already-patched MeteorSpawnScope spawn invocation.
- Kept meteor physics, explosions, infected terrain, meteor geometry, infection, phase difficulty, global spawn configs, In Control mixin bytecode, and all unrelated resources unchanged.

MAINTAINED COMPATIBILITY DESIGN
- In Control v9.4.6 is OPTIONAL, not a dependency. Existing targeted Mixins protect only persistent-marker meteor mobs in three handlers. Original world-spawn configuration remains intact for all other spawns.
- Per-meteor ThreadLocal spawn context binds the one intended identity to the type, world, spawn reason and approximate position. Existing context implementation was not modified.
- No per-tick entity scans, new event listeners, or new Mixin injections were added in this version.

BUILD PROCESS AND SOURCES
- Existing PhayriosisMeteorImpactSystem.class was modified using a narrowly scoped ASM instruction edit at spawnImpactInfected to expand the constant String[] list; no bytecode frames/branches or method signatures changed.
- Existing MeteorSpawnScope.java was rebuilt as Java 17 using the prior working source, changing only its fast-reject whitelist/comment. Sources and ASM patcher are provided in the separate accompanying Source.zip.
- Java API stubs used in offline tests MUST NOT be distributed inside the mod JAR.

OFFLINE TESTS
- Checked all four new mob registry IDs exist in this exact Phayriosis JAR.
- Java 17 class compile passed, bytecode examination of patched pool showed the six specific names, and unit-style mock checks passed for each new elite plus ordinary same-type spawns, nested same-type at another position and unrelated mod namespace.
- Jar ZIP integrity and unchanged-file diff should be checked after release assembly.
- The user has validated the prior optimized 0.1.2 compatibility JAR in-game. This 0.1.3 wave has NOT yet been tested in a live Forge world.

KNOWN LIMITATIONS / FUTURE VALIDATION
- The original wave includes two 'assaulter' and two 'spitter' resource paths. The Entity registry in this JAR contains 'primal_assaulter' and 'primal_spitter', but not those two abbreviated names. This pre-existing discrepancy was NOT changed in the 0.1.3 release to avoid unrelated behavior changes. If those four prior entries fail to spawn, decide separately whether to repair these paths in a future version.
- Test meteor at low daycount with the user's restrictive spawn.json, confirm newly added elites appear and naturally spawned elites stay restricted by In Control.
- Verify server and client launch with and without In Control and check logs for InControlMeteorBypassMixin success. Review TPS with a meteor event at high player counts.
- No in-game runtime execution of the mod was possible in this build environment; offline bytecode and mock tests do not replace live Forge testing.
