GM4_Datapacks
GM4_Datapacks copied to clipboard
Gamemode4Dev
Improved Metallurgy Band Recycling
This PR expands on the duplicate protection currently in place when casting a Shamir by nudging the odds even more. This is of particular importance as the amount of Shamirs keeps on increasing, making for a rather frustrating casting experience.
What is the current duplicate protection?
Currently, if a Obsidian Cast is recycled during casting (replacing some of the ores that would usually be required), the newly cast Shamir can not be the same as the one that was on the recycled Obsidian Cast. Due to the amount of metal an Obsidian Cast contributes, only one Obsidian Cast can be recycled per successful Shamir cast.
Whilst this makes casting slightly less frustrating, it barely makes a difference as the amount of available Shamirs grows. I.e. if there are only two Shamirs installed (e.g. with base Metallurgy) this makes casting trivial, as you'll always get the Shamir you want after a maximum of two casts. However, if there are 20 Shamirs available for a metal the current system has practically no impact at all.
How does this PR improve the system?
This PR introduces a memory of previous Shamirs on each metal band. Whenever an Obsidian Cast is recycled and turns into a new Obsidian Cast with another Shamir, the old Shamir is added to this memory/list. E.g. if an Arborenda Obsidian Cast is recycled and turns into a Sensus Obsidian Cast recycling that Sensus Obsidian Cast will yield neither Arborenda nor Sensus. If no more Shamirs are available, a Mundane Band Obsidian Cast is created, otherwise another Shamir is created, e.g. Iacio.
Notable Consequences
- Using this system, an unlucky player must cast
<amount of Shamirs available on the metal>-times to get the Shamir they want - This makes Obsidian Casts less stackable, as the Memory of each is stored on the item. We could consider making Shamirs unstackable altogether by storing a UUID within the NBT, e.g. at
gm4.unstackable.
Footnote -- Metallurgy Codebase
During the making of this PR I've noticed that Metallurgy could make further use of storage and reduce the amount of duplicate entity selectors in the process. A metallurgy rewrite or code-overhaul should be considered in the near future.
The NBT on metallurgy items could also use a cleanup, however, this would require complicated upgrade paths. E.g. the tags gm4_metalllurgy.active_shamir, gm4_metalllurgy.stored_shamir, and gm4_metalllurgy.memorized_shamirs could be moved to gm4_metalllurgy.shamir as gm4_metalllurgy.shamir.active, gm4_metalllurgy.shamir.stored, and gm4_metalllurgy.shamir.memorized.
I have some concerns about the loss of stackability this introduces to shamirs, especially considering that the player has no way currently to see this extra memory data on their casting. It would be very annoying to forget that you cast a band and then try to use it later to make a shamir already in that band's memory. I suppose this could be solved with an additional lore text along the lines of "echos with the memory of 'Arborenda'" but I think that would look kinda bad.
What do you think about making this an AOE timed phenomena around the casting site directly? When a band is recycled, its data is entered into an AEC/Marker, and the next band to be cast in the immediate area cannot match the Marker's memory. Either after some time or when an only-ore casting is made, the Marker deletes itself and regular casting odds reassert themselves. This would work pretty intuitively (could even include particles or something) as long as the caster is only recycling bands they don't want to come back up in the casting.
I have some concerns about the loss of stackability this introduces to shamirs, especially considering that the player has no way currently to see this extra memory data on their casting. It would be very annoying to forget that you cast a band and then try to use it later to make a shamir already in that band's memory. I suppose this could be solved with an additional lore text along the lines of "echos with the memory of 'Arborenda'" but I think that would look kinda bad.
An alternate solution would be to add a new item called a "Reforged Cast" which are unstackable. This cast would act the same as a normal obsidian cast, but would indicate that it was created via band recycling.
I have some concerns about the loss of stackability this introduces to shamirs, especially considering that the player has no way currently to see this extra memory data on their casting. It would be very annoying to forget that you cast a band and then try to use it later to make a shamir already in that band's memory. I suppose this could be solved with an additional lore text along the lines of "echos with the memory of 'Arborenda'" but I think that would look kinda bad.
An alternate solution would be to add a new item called a "Reforged Cast" which are unstackable. This cast would act the same as a normal obsidian cast, but would indicate that it was created via band recycling.
This sounds like a good middle ground. There are two other possible implementations I'd like to mention for completeness' sake:
- Make all Shamirs unstackable (❌unfavorable for autocasters)
- Only store the extra memory temporarily, e.g. smooshing the Shamir onto a tool deletes the memory (ℹ️seems weird lore wise)
An alternate solution would be to add a new item called a "Reforged Cast" which are unstackable. This cast would act the same as a normal obsidian cast, but would indicate that it was created via band recycling.
This is the solution I will go for.
@BluePsychoRanger Should I force reforged casts to be unstackable? Their current technically-stackable-but-unlikely-stackable nature might be confusing, even if it can be useful at times.
@BluePsychoRanger Should I force reforged casts to be unstackable? Their current technically-stackable-but-unlikely-stackable nature might be confusing, even if it can be useful at times.
Yes, just add a randomly generated number to the tag, maybe under a general gm4 tag like gm4_uuid or gm4_unstackable
Would this include all future newly formed shamirs? Or just recasts?
Infinitas has an issue currently that would be fixed with unstackable shamirs, so this would be nice.
Would this include all future newly formed shamirs? Or just recasts
As stated in the original proposal, the reforged cast would be a new, unstackable item. We've had lengthy conversations about the stickability of casts/shamirs and came to the conclusion that they should remain stackable.
I will have to do some further research, but I think there is another problem here we didn't account for:
- Placing these shamirs with memory will wipe their memory
And as far as I know, we can not easily address this, we have to chose whether we tolerate this method of memory wiping or whether memory wiping is considered a "deal-breaker" for this PR. @hozz8528 suggested that this memory should not be persistent and was somewhat bummed when I made it so that the memory is conserved during smooshing; One possible "solution" would be to make this memory "volatile" (as in also wiping the memory upon smooshing), however, I am not sure how to feel about this, as it will lead to stackability inconsistencies again.
I am heavily leaning towards the memory reset upon placement now. Converting this to a draft until necessary changes have been made.