Extend modular logic to allow for more configuration setups #19866
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR extends the usage of modular beyond just changing the damage type to B, P, or S.
modularConfigs
, that matches traits to sets of modular configs, which they themselves match a string key to an optional damage type (optional because SF2's shock truncheon), an array of traits (that can be empty), and a label that is effectively the localisation of the key of the config.Though not present here, I've tested this with a few setups, like having a thrown trait in the modular trait, or with combination weapons.
Here's a visual demonstration:
modular_showcase.mp4
There are a few spots where I'm not sure if I approached this correctly --
WeaponTraitToggles
'sapplyChanges()
andWeaponPF2e
'stoThrownUsage()
, I'm not too sure about, the latter I think might benefit more from a reorganisation from when data is handled? But I don't know enough about the system to feel out how it would best be reorganised, so consider this a "half-draft" PR.