-
-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add loadout filters for total, weapon, and armor light level #10520
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great!
selectedLoadoutsStore, | ||
); | ||
|
||
// The UI, at the time of implementing this, only shows the light level using the following rules: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should probably reuse the code the UI uses:
Which is called like:
let [items, warnitems] = getItemsFromLoadoutItems(
itemCreationContext,
loadoutItems,
store.id,
allItems,
modsByBucket,
);
const loadoutItemsByCategory: Record<BucketSortType, ResolvedLoadoutItem[]> = Object.groupBy(
items.concat(warnitems),
(li) => li.item.bucket.sort ?? 'Unknown',
);
const power = loadoutPower(store, loadoutItemsByCategory);
- Remove armorlight, weaponlight filters - Remove use of class - Clean up manual filtering of items by their bucket hashes in favor of orderBy and bucket hash - Some cleanup of types + resolving LoadoutItem's to DimItem's
Thanks for the update. I'm still wondering why not reuse the code from LoadoutView to calculate the power level, though. |
Eep, sorry - got busy and haven't had a chance to follow up on that. I had looked at this and largely agree - it's probably the right call. I think my biggest concern is that I couldn't figure out how to get to an Think it's worth bringing up on the discord, since it's probably going to be non-trivial? Or am I overthinking it? |
Ah, that's a good point. I think you'd need to dig into |
Yeah, let me poke at it a bit. I should be able to pull the relevant bits out. |
Alright, so I looked at it and the logic for
Which I'm guessing can be simplified down to just the call to If you'd like, I'd be happy to separate the logic in the (newly renamed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks great. Thanks for adding it!
This might require some iteration before merge (or even being redone entirely) but I figured I'd put the code out there to start the conversation, at least.
Short version is this implements 3 new filters for the loadout search:
light:
/power:
which filters by the calculated light level of the loadout, if all slots are filledweaponlight:
/weaponpower:
which filters by the calculated light level of the weapons, if all 3 slots are filledarmorlight:
/armorpower:
which filters by the calculated light level of the armor, if all 5 slots are filledThese liberally reuse the range syntax from the
light:
filter from the main inventory, so they largely have all the features you'd expect.The "If all slots are filled" quirk comes from spending some time staring at the loadout UI - it only shows a light level for a loadout if there are items in all slots, which seems like a reasonable constraint so I carried it forward for all three filters. I could see an argument for weapon/armor light level filtering not needing this restriction, though.
As with the loadout UI (and inventory filters), artifact level is not taken into account when filtering.
My big concern here is that this is well outside my knowledge of the DIM codebase, so I kind of cobbled together the translation from a loadout -> DIM items + all the validation since I couldn't find any sort of pre-implemented utilities for it. I may have missed something very obvious, or honestly I may have simply done something that is counter to long term roadmap.
I'm also not sure I'm happy with having both the
light:
andpower:
variants, but it's no additional maintenance and it seemed worth it for symmetry.Anyways, apologies for dropping this on you unannounced. I can ping you on discord if we need to chat about it some.