Add God's Mastery item#216
Conversation
- New items: Core of the Vault Gods (inert shaded sphere, glowing 4-color god border; drops in the hyper omega injection pool at weight 1 of 613) and God's Mastery (4-point god-colored star, shiny awakened center; crafted from the core surrounded by 8 Blocks of Omega Pog). - Shift-right-click consuming God's Mastery permanently raises the player's MAXIMUM god reputation with all four Vault Gods by 1 (base 50). It grants no reputation itself. The count lives in the player's own PlayerPersisted NBT so it survives death/relog and travels with the player file across sub-server transfers; an explicit PlayerEvent.Clone copy removes any reliance on Forge's built-in persistence. - Cap plumbing: PlayerReputationData's hardcoded 50s become 50 + mastery via ThreadLocal-published caps (read clamp, add guard, Entry clamps), and the load-time legacy clamp that rewrote >50 reputation back to 50 on every server start is disabled - it would silently erase raised reputations. The armor/ model unlock threshold deliberately stays at 50. GodReputationItem's max check honors the raised cap. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
VaultCharmItem froze charms at 50 two ways: getGodReputation clamped every read of the stored snapshot at 50, and shouldUpdateItem early-outed whenever stored and current were both >= 50, so the 10-tick follow-the-holder rescale never ran for a God's Mastery player (stored 50, current 52). New MixinVaultCharmItem lifts both constants; the update check reduces to stored != current, so charms keep resetting to whichever player holds them, in both directions (a 52-rep charm rescales down for a lower-rep holder). The rescale math and snapshot flow are untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The two hand-written model jsons had no ModItemModelProvider entries, so the next runData would have deleted them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
iwolfking
left a comment
iwolfking
left a comment
There was a problem hiding this comment.
Generally looks fine, not sure I am sold on concept or not but I think it is fine enough to add as an additional post game activity.
I am not sold on idea of storing this data in the player's data, but that is more just because all vault/wold's vaults player data is traditionally stored in separate SavedData files and this is a bit different. I think I'd personally prefer to have it the same as usual but it's probably fine really.
I'd like to see the random comments generally removed, the AI glorp comments are generally undesirable. If Claude would like to generate proper Javadoc comments when relevant that would be nice though! This is applicable to the other PRs as well.
|
|
||
| CRYSTAL_REINFORCEMENT = new BasicItem(WoldsVaults.id("crystal_reinforcement"), (new Item.Properties()).tab(ModCreativeTabs.WOLDS_VAULTS)); | ||
| RESONATING_REINFORCEMENT = new BasicItem(WoldsVaults.id("resonating_reinforcement"), (new Item.Properties()).tab(ModCreativeTabs.WOLDS_VAULTS)); | ||
| CORE_OF_THE_VAULT_GODS = new xyz.iwolfking.woldsvaults.items.CoreOfTheVaultGodsItem(WoldsVaults.id("core_of_the_vault_gods")); |
There was a problem hiding this comment.
Class names should never be fully written out like this unless necessary (same class name is used from two different packages in the same class). This is applicable to the other PRs as well. I can address these but would be good to have cleaned up.
There was a problem hiding this comment.
I'll remove the comments and clean up the class names, as well as moving the stored player data. Was vaguely confused on the way it was stored but was worried it wouldn't be properly carried over on death/server restart, but hopefully it should be safe in the SavedData files.
Review feedback on iwolfking#216: per-player progression traditionally lives in separate SavedData files. Counts move from the PlayerPersisted NBT subtree to PlayerGodMasteryData (woldsvaults_God_Mastery), keyed by player UUID. The world file survives death/relog/restart on its own, so the clone-event copier goes away entirely, and the cap no longer depends on an online-player lookup — reputation changes for offline players now resolve their real cap instead of assuming base 50. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…Javadoc Review feedback on iwolfking#216: class names should not be written fully qualified when a plain import works. Also replaces the God's Mastery section banner in MixinPlayerReputationData with Javadoc on the two cap-publishing injectors. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Union-resolves the item/datagen registration conflicts with the merged greedy ticket (iwolfking#215); master's lines are kept verbatim. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Re-sorts the merged lang keys and adds the gods_mastery recipe-unlock advancement, which the branch was missing (its datagen had never run with the recipe provider registered). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The empty redirect body speaks for itself; its Javadoc explains why the legacy clamp is skipped. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2 participants
A new consumable that permanently raises the reputation caps of a player by 1, storing it in their player data and allowing charms to take reputations higher than 50. Crafted from the Core of the Vault Gods, a very rare drop from high cycle hyperboss vaults, so it shouldn't really hurt game balance. More of a fun item to grind for, not designed for anything super special at the moment. Currently doesn't have a cap, done on purpose (the soft cap is the hundreds of hours needed to grind that many), but one could be added if you want (i personally like it uncapped).
🤖 Generated with Claude Code