Phayriosis Reborn maintainer history

0.0.10 - Phase 1 world-configuration migration foundation
- Decommissioned the legacy runtime configuration UI without touching unrelated machine/container GUIs.
- The phayriosis_config_open command no longer registers.
- The legacy ConfigMenu menu type no longer registers.
- The legacy ConfigScreen is no longer bound to a menu type during client setup.
- The legacy ConfigButtonMessage no longer registers on the mod network channel.
- Existing config classes/resources are intentionally retained as inert compatibility baggage in this binary-only migration. Removing them from the archive would create avoidable linkage risk while other generated classes still contain symbolic references.
- Static meteor worldgen has NOT been changed in this phase.
- Meteor/event behavior has NOT been changed in this phase.
- Next milestone: add a world-creation settings model with per-world persistence, then use it as the authority for new-world Phayriosis configuration.

Validation notes
- Only the config registration blocks were neutralized. Centrifuge, Radium Extractor, Biosynch, Plasma Cooler, and Conversion Table menu/screen registration bytecode remains intact.
- This phase intentionally avoids changing Phayriosis world variables or infection behavior so existing worlds retain their current gameplay state.


2026-10-03 Phase 1 verifier correction
- Initial Phase 1 attempted same-length raw opcode neutralization in several generated registration methods.
- Java 17 rejected ConfigButtonMessage.registerMessage with VerifyError: Expecting a stack map frame because dead NOP bytes remained after an early RETURN without rebuilt StackMapTable data.
- Correction: restored PhayriosisrebornModMenus, PhayriosisrebornModScreens, and ConfigButtonMessage byte-for-byte from 0.0.9.
- The old config command is now disabled by omitting OpenConfigCommand.class entirely. No raw bytecode edits remain in Forge registration classes.
- Old ConfigMenu/ConfigScreen/ConfigButtonMessage stay registered but have no normal gameplay entry point; this is intentional temporary inert compatibility baggage until Phase 2 replaces the backend.
- Do not reintroduce opcode-overwrite patches without recomputing Code attributes / stack map frames.

2026-10-03 - 0.0.11 Phase 2 world-settings backend
- Added net.mcreator.phayriosisreborn.config.PhayriosisWorldSettings as a dedicated per-world SavedData object using data name phayriosisreborn_world_settings.
- This intentionally separates future world-creation configuration from legacy MapVariables, which mixes configuration switches with runtime/adaptation counters.
- Schema v1 tracks the seven legacy GUI toggles plus max infectable hardness and block spread speed.
- Schema v1 also reserves dormant meteor settings so later meteor phases can bind to stable persisted values. These meteor fields do not affect gameplay in Phase 2.
- Existing worlds are migrated non-destructively: on player login, if world-creation settings have not become authoritative yet, current legacy MapVariables values are mirrored into the new SavedData.
- The two retained admin commands also mirror their resulting legacy values into the new backend immediately.
- No existing infection procedure reads the new backend yet; gameplay behavior therefore remains unchanged in Phase 2.
- worldCreationConfigured is the ownership handoff flag for the future Create World screen. While false, legacy values remain authoritative and are mirrored. Once the new world-creation path exists, it must set this true and then make the new backend authoritative.

Correction to early Phase 1 history wording:
- The final verifier-safe Phase 1 build did NOT unregister ConfigMenu, ConfigScreen, or ConfigButtonMessage. Those registrations were restored byte-for-byte after the Java 17 verifier failure. The only gameplay entry point removed was OpenConfigCommand.class, leaving the old GUI registered but unreachable through normal Phayriosis gameplay.

2026-10-03 - Phase 2 world-creation crash correction
- Initial Phase 2 backend mistakenly compiled against net.minecraft.server.level.ServerLevelAccessor, a nonexistent 1.20.1 class path created by an incorrect local compile stub.
- Crash occurred on PlayerLoggedInEvent when PhayriosisWorldSettings.ensureInitialized() first resolved that type.
- Correct Forge/Minecraft 1.20.1 interface is net.minecraft.world.level.ServerLevelAccessor.
- Recompiled PhayriosisWorldSettings against the corrected package only; no intended settings behavior changed.
- Rule for later work: local Minecraft stubs must match real package names exactly; verify every newly introduced Minecraft class reference against the target runtime before packaging.

PHASE 3 (0.0.12)
- Removed only the large/small meteor Forge biome modifiers, disabling static meteor chunk generation.
- Preserved configured/placed features, Java feature classes, meteor NBT structures, blocks, and dungeon assets for the future live meteor event.
- No Phase 2 settings, infection logic, commands, or machine GUIs changed.
- Superflat remains valid for startup regression testing; use fresh normal terrain to verify the old static meteors no longer appear.

[0.0.13 / Phase 4]
Added verifier-safe compiled PhayriosisMeteorEventData and PhayriosisMeteorScheduler classes. The live meteor now has a persistent server-side eligibility/roll state machine. Successful rolls only create a pending flag; no meteor entity or terrain effect exists yet. Scheduler is Overworld-only, respects Phase 2 meteor settings, persists across reloads, and never restores Phase 3 static meteor worldgen.

2026-10-03 - 0.0.14 / Phase 5
- Added a real registered/synchronized falling meteor entity (phayriosisreborn:phayriosis_meteor).
- Added server-side launch conversion from Phase 4 pending rolls.
- Pending events are consumed only after entity spawn succeeds; launch failures retry instead of deleting the event.
- Added persistent active-flight/launch/impact runtime fields (meteor event schema 2).
- Added client-only renderer using the existing meteoric_rock item model at large scale as a temporary native visual.
- Impact is intentionally non-destructive in Phase 5: records completion and discards the meteor; terrain/crater work is reserved for Phase 6.
- Static meteor worldgen remains disabled from Phase 3.
- Validation note: new classes compile to Java 17 class version 61 and were checked for the prior bad ServerLevelAccessor package reference; none is present.


0.0.14.1 - Phase 5 clock-domain correction
- Fixed meteor minimum-day eligibility to use dayTime instead of gameTime.
- Added schema-3 migration to clear stale pre-fix scheduler timing without losing active/pending events.
- Test instruction correction: /time set affects day eligibility; it does not fast-forward the 3600-game-tick retry interval.

0.0.18.6: Recompiled PhayriosisCreateWorldClient to repair Java 17 StackMapTable VerifyError introduced by 0.0.18.5 raw control-flow patch. Game-tab-only behavior preserved.


=== 0.0.18.8 - Phase 7A SRP-style Create World lifecycle port ===
Date: 2026-10-04

User clarification/reference:
- Reference implementation is Scape and Run: Parasites (SRP) 1.12.2, jar SRParasites-1.10.9.
- SRPWorldCreateButtons was inspected directly. SRP creates one dedicated world-settings button on GUI init, lays it out relative to a known vanilla Create World control, and updates that button after Create World page actions. It does NOT rely on a perpetual render-time position/visibility chase.

Observed failures before this build:
- 0.0.18.6: Phayriosis button still followed the World/More tabs and clicking it crashed.
- 0.0.18.7: opening Create World itself crashed with NoSuchMethodError because Component.m_237113_(String) had been compiled with return type Component instead of the real SRG descriptor return type MutableComponent.
- The previous Render.Pre visibility mirror was also the wrong architectural fit for Minecraft 1.20.1 tabs.

Corrections in 0.0.18.8:
- Port the SRP lifecycle concept to 1.20.1 rather than copying 1.12.2 code literally.
- Create/layout one Phayriosis button during ScreenEvent.Init.Post, directly under Allow Cheats / Allow Commands.
- Remove the per-frame ScreenEvent.Render.Pre visibility chase entirely.
- Track CreateWorldScreen's vanilla TabNavigationBar and react after mouse/keyboard tab actions, analogous to SRP's ActionPerformed post handling.
- Determine the selected vanilla tab through the public TabNavigationBar -> TabButton API by reflection on public method shapes, avoiding private CreateWorldScreen fields and mapping-sensitive method names.
- Show/enable Phayriosis only when the selected tab object is CreateWorldScreen.GameTab; hide/disable it on World and More; show it again when Game is selected.
- Component.m_237113_(String) is compiled with the correct runtime return descriptor MutableComponent.
- Button.OnPress lambdas are compiled against the exact 1.20.1 SRG SAM m_93750_(Button).
- Restore PhayriosisWorldCreationScreen.class from the last known correctly-linked 0.0.18.4 build so its Component.literal and OnPress descriptors are also known-good.
- Java 17 verification is required before shipping.

Permanent UI rules:
- Use SRP's event-driven ownership pattern as the conceptual reference: init/layout once, update after GUI actions/page changes.
- Do not reintroduce a Render.Pre per-frame visibility mirror for this button.
- Do not infer active tabs from Allow Cheats.visible; the injected widget is external to vanilla TabManager and tab ownership must be checked from the vanilla tab navigation state.
- Keep the button labelled exactly "Phayriosis" and positioned directly under Allow Cheats on the Game tab only.
- When manually compiling SRG-linked client classes, verify Component.m_237113_ returns MutableComponent and Button.OnPress uses m_93750_(Button).

No Phase 6 meteor, impact, shockwave, chunk-loading, worldgen, entity, audio, or terrain behavior changed.

=== 0.0.18.9 - Phase 7A meteor reward + distant impact-audio tune ===
Date: 2026-10-04

User-tested baseline:
- 0.0.18.8 Create World / SRP-style Phayriosis button lifecycle is confirmed working, including tab behavior and button opening.
- Treat the 0.0.18.8 Phase 7 UI integration as stable and do not alter it for this tuning release.

Changes:
- Preserve the exact accepted meteor impact sounds and sound-selection order.
- Increase only the long-range impact witness envelope from 512 blocks to 1024 blocks.
- Keep impact/flash/shockwave particle delivery capped at the existing 512-block visual range to avoid doubling particle/network load.
- Increase the hollow meteor chamber reward target from 42-50 to 70-80 unique exposed ore blocks.
- Increase rare-ore weighting while keeping common material dominant. New 49-entry weighting is approximately:
    13 iron, 10 biometal, 7 copper, 8 gold, 5 crimsonscale,
    2 emerald, 2 diamond, 2 plutonium.
- Ore placement remains individual exposed chamber-wall blocks with duplicate-position rejection; no veins were introduced.

Permanent rules:
- Do not change the accepted impact sound asset merely to increase hearing distance; extend delivery/range instead.
- Keep long-range sound scaling independent from the 512-block particle/flash visual range for performance.
- Meteor chamber loot may be generous because this is an apocalyptic world event, but rare ores should remain a minority and placement must remain finite/unique.
- Preserve the stable 0.0.18.8 Create World UI classes unless a later UI feature explicitly requires changes.


[0.0.20.2 / Phase 7C one-shot meteor]
Validated 0.0.20.1 exposed repeated automatic meteors. Cause: a successful launch cleared pendingMeteor and scheduled the next eligibility roll. Fix is deliberately lifecycle-based, not a permanent tick rejection: successfulLaunches >= 1 is the persistent per-world consumed state; first success unregisters the scheduler + launch LevelTickEvent workers. On save reload, EventData.load retires them once. A tiny ServerAboutToStartEvent lifecycle listener re-arms workers for a different world/server opened in the same JVM. Preserve all Phase 6 meteor behavior and Phase 7C difficulty logic.

0.0.20.17: Dimensional spawning defaults ON. Universal infection gate broadens spread to ordinary modded blocks while protecting BlockEntity/NBT blocks and liquids; existing hardness/blacklist rules remain authoritative.

=== 0.1.4 (hotfix) — release version and file naming ===
Date: 2026-10-12
Author: leo_san
Base: Phayriosis-Reborn-Continued-0.1.3-Modpack-Config-Meteor-HP.jar (latest user-approved build).
Changes: Updated Forge mods.toml mod version from 0.1.3 to 0.1.4; renamed distributed jar to phayriosis-reborn-continued-0.1.4(hotfix).jar.
Unchanged: All compiled classes, spawn behavior, meteor guards/100-HP floor, 500-HP nucleus, modpack UI visibility option, In Control spawn exemption, configuration, assets, and dependencies.
Validation: JAR integrity and exact binary identity of all class files and non-document metadata checked offline. No Minecraft gameplay launch test was run for this metadata-only release.
Maintainer handoff: Continue from 0.1.4 hotfix. For new functionality, avoid mutating other systems without request.


Phayriosis Reborn Continued - Meteor Defender Spawn Reliability Repair
Build: 0.1.4 (hotfix, no internal version increment)
Target runtime: Minecraft 1.20.1, Forge 47.4.x, Java 17
Author remains: leo_san

Problem report
- Meteor landings out of player render distance lacked their exterior defenders.
- Ordinary animals or unrelated mobs occasionally appeared near the meteor with 100 maximum health.

Root causes and findings
1) Exterior defender arrays requested phayriosisreborn:assaulter (twice)
   and phayriosisreborn:spitter (twice), but entity registration contains
   primal_assaulter and primal_spitter. The former had the 0.1.3 elite equivalent,
   but the names in these four older slots were invalid.
2) spawnEntity used ForgeRegistries.ENTITY_TYPES.getValue() and checked only
   the returned value for null. A registry can return a default entity for
   unknown names. The result was not compared against its requested registry ID,
   so fallback animals could be spawned and subsequently given the 100-HP floor.
3) Meteor defenders were ordinary mobs without persistence-required enabled.
   Distant despawn/unloading could prevent exterior defenders from being present
   when the player returned. Entity spawning might also transiently fail while
   impacted chunks are being prepared; the old path made only one attempt.
4) The fast whitelist used by the In Control exemption retained the old
   'spitter' path and did not recognize 'primal_spitter'.

Implementation
- Replaced the two 'assaulter' slots with 'primal_assaulter', and two
  'spitter' slots with 'primal_spitter'; total exterior defender attempts
  remains 26, with the existing elite guard pool left in place.
- Replaced entity lookup with exact requested registry key comparison,
  restricted to the phayriosisreborn namespace; invalid IDs never spawn.
- Kept the original EntityType.spawn -> MeteorSpawnScope spawn mechanism,
  marker, In Control injections, and one-entity context intact.
- Added a MeteorDefenderSpawnManager helper for exterior defenders only.
  On success, it requires the meteor-origin marker, then enables Mob
  persistence and applies the previous 100-HP minimum helper.
- Added a maximum of 3 extra server-thread spawn attempts, two ticks apart,
  only when an exterior spawn returns null or lacks the marker. This stays
  within the original meteor ticking-chunk lease and prevents runaway retries.
- Updated the marker whitelist lookup to recognize 'primal_spitter'. This
  updates both the exact string and its Java hash-switch key; lookup for
  unrelated mobs still does not touch persistent NBT.
- Preserved Nucleus creation and its separate 500-HP adjustment entirely.
- Did not change meteor crater placement, block effects, configuration,
  meteor schedule, chunk ticket count, mob AI, or natural spawn rules.

Verification
- Java 17 compiler accepted the new source helper.
- ASM parsed both patched classes, verified expected patch-point counts.
- Exact registry and source identifier inspection validated old/new IDs.
- Structural bytecode checks confirm exterior guard calls use the new helper,
  Nucleus still uses the original entity spawning path, and the existing
  meteor In Control mixin configuration remains byte-identical.
- Live integrated Forge testing is NOT performed by these checks.

Testing next
1. In a world with the existing In Control day limits, land a meteor far
   outside any player's view. Approach later and verify all exterior mob types,
   including Primal Spitters, remain present and have at least 100 max HP.
2. Ensure non-Phay animals at/near the impact do not get meteor boosts.
3. Verify Nucleus stays at 500 max HP inside the meteor.
4. Inspect latest.log for '[Phayriosis Meteor] defender spawn failed...'
   if exterior defenders are still missing and capture forced-chunk logs.

Known limitations
- Forge-integrated offscreen lifecycle behavior must be validated in-game.
- Failed spawns are retried three times at two-tick intervals; permanent
  failures are logged without infinite loops or chunk forcing beyond the
  existing impact lease.
- The old 'assaulter' whitelist remains in the generated fast lookup but
  no longer causes spawns; it is inert and is not broadened to non-Phay mobs.


=== 0.1.5 — version metadata update from verified meteor-defender fix ===
Date: 2026-10-12
Author: leo_san
Baseline: phayriosis-reborn-continued-0.1.4(hotfix)-meteor-defender-fix.jar (user confirmed meteor spawning works in-game).
Changes: Set Forge mod version to 0.1.5; release filename Phayriosis-Reborn-Continued-0.1.5.jar; append release documentation.
Unchanged: All compiled classes and gameplay behavior, including valid Phayriosis-only meteor defenders, bounded retries and persistence, the meteor-only In Control compatibility marker, min-100-HP exterior guards, the separate 500-HP Nucleus, world creation config visibility option, and all existing configs/assets.
Verification: Inspected JAR entry names, hashes, version and author; ZIP integrity passed. No new runtime test was performed for this metadata-only update.
Handoff: Use this 0.1.5 JAR as the authoritative next baseline; do not revert the verified 0.1.4 defender reliability fixes.


=== 0.1.5 METEOR ENTITY FACTORY COMPATIBILITY HOTFIX ===
Date: 2026-10-18
Author: leo_san
Baseline: Phayriosis-Reborn-Continued-0.1.5.jar, confirmed working in-game for meteor defenders.
Reported failure: Easy Mob Spawn Control 1.6.2 GUI enumerated all EntityTypes, invoked EntityType.create(clientLevel) to determine whether types are living mobs, and triggered AbstractMethodError in the Phayriosis custom meteor EntityFactory lambda.
Evidence: crash.txt dated 2026-10-15 17:36:56, opening Easy Mob Spawn Control's config screen. Stack trace: EntityType.m_20615_ -> EasyMobSpawnControl.EntityUtil.isLivingEntity -> MobListManager -> SpawnControlScreen; missing EntityFactory.m_20721_(EntityType,Level).
Root cause: The custom PhayriosisMeteorEntityRegistry class's invokedynamic LambdaMetafactory call site used the development-mapping SAM name create instead of the Forge 1.20.1 SRG runtime SAM m_20721_. The existing generated PhayriosisrebornModEntities registry already uses m_20721_ correctly; only the custom meteor factory was wrong.
Fix: Replace exactly one UTF8 constant-pool entry for the meteor registry lambda SAM name, create -> m_20721_, preserving bootstrap method, functional signature, constructor target, and all other classes. No changes to Easy Mob Spawn Control, Forge mod version (remains 0.1.5), or any meteor logic.
Unchanged: Nucleus 500-HP behavior; exterior defender composition, persistence and minimum 100-HP floor; optional In Control compatibility, persistent spawn markers, world creation visibility configuration, chunk handling, and all remaining code/resources.
Validation: JAR ZIP CRC integrity; javap post-patch InvokeDynamic verification; exact SHA-256 identity for all 2,816 unrelated class files; mod metadata and unchanged resource verification. No live Forge game test has been performed for this hotfix.
Recommended test: Start the modpack with Easy Mob Spawn Control 1.6.2 and Phayriosis 0.1.5 hotfix, open Mods > Easy Mob Spawn Control > Config and use its entity list/search. Then spawn a Phayriosis meteor and confirm all existing behavior remains intact.
Outstanding limitation: Another mod can still mishandle instantiation of unusual entities during GUI scanning. Report any new crash separately; do not assume it is this resolved AbstractMethodError.
Handoff: Continue from the hotfix jar. Preserve existing meteor logic and the Forge runtime-mapped lambda name when rebuilding or remapping custom registry classes.
