Webhook data extra.rarestProbability only sent once per loot notif

[APKiwi]

Checklist

• I've searched the issues and pull requests for similar looking suggestions.
• I've checked the Unreleased section of the changelog for newly added features that sound like my suggestion.

Describe your Suggestion

I understand that 'rarestProbability' is indicative of the rarest item. Would it be possible to receive this data for each item (ie extra.items[{item.probability}]? It must exist already as you can determine which item is rarest at some point.

Reasoning

It would be convenient to have this data for analysis and logging rarity of items individually so we can build miscellaneous analytics around who is the most spooned (as we have # of kills), the most unlucky and the most unusually rare drops (receiving a Grimy Dwarf Weed from a Mummy https://oldschool.runescape.wiki/w/Mummy#Ancient_Pyramid) etc.

Additionally beneficial for extreme cases like double uniques from Vorkath or Zulrah.

[APKiwi]

Looks like the PR is done, is there something blocking this feat?

[iProdigy]

I'll try to finish the PR this week (or next week at the latest) - it's still a draft because:

• i want to check more edge cases that could arise in various NPCs' drop tables that could lead to inaccurate metadata
• the $O(m)$ algorithm in the PR involves a bit more complexity than the naive $O(n \cdot m)$ approach, so I have to gauge whether the optimization is worth the complexity
• been busy irl

[APKiwi]

Legend. Love your work

[iProdigy]

update: could only find the edge case for Sorebones and Zombie pirate (Harmony Island) during The Great Brain Robbery, so I think we're good on that front. The problem with their drop table is they can drop two different items with the same exact name: Bandana eyepatch (in red or blue variation), so our reported probability is the chance of getting any variation rather than the specific color that dropped (and each color has a different drop rate in reality). This edge case is quest-specific and the items are unimportant, so I probably won't bother adding a special case to patch it.

on the second bullet point, technically we're already using the $O(n \cdot m)$ approach, which is easier to review (and uses less memory), so I'll prolly switch back to that