-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Trait state is stored in a slightly weird way: trait data is stored for checked trait items that aren't for the currently selected trait; a nonexistent key means a trait item is unchecked. (I did kind of do this on purpose at the time; I knew it would lead to this annoying case and still did it.)
Currently our template data is stored as an exact copy of the trait state object in redux. This means that it's possible for a template to store the fact that a trait item that isn't for the currently selected trait is checked. This is harmless but silly.
The corollary to this is that it's possible for a template to store the fact that a trait item that isn't for the currently selected trait is NOT checked. This would be harmless but silly... except that a nonexistent key is how you do that, which is also the state for "the trait item in question did not exist at the time the template was created, but it does now."
Due to this ambiguity, the code currently treats traits like Inferno, which I just added, as manually disabled if you load a template from before they're added, rather than taking the "should this trait item be enabled by default" value from the data itself.
This is kind of annoying to fix. If I'd stored every existing trait item in the template data as either "trait-id": { /* */ } or "trait-id": false, it would be easy to identify traits which did not exist at the time, though that would have wasted some storage.
It is fixable; relevant traits can be found by following the getTraitsModifiers algorithm and the existing template data can be cleaned up that way:
discretize-gear-optimizer/src/state/slices/traits.ts
Lines 146 to 151 in 874c3bf
| const visible = | |
| itemData.minor ?? | |
| (typeof itemData.gw2id === 'number' && allSelectedTraits.includes(itemData.gw2id)); | |
| if (visible) { | |
| result.push({ id, ...itemData, amount: value?.amount }); | |
| } |