Filter bosses/heroes listed as being able to drop items by using item level + loot table item min/max level

[fonsleenaars]

Filter bosses/heroes listed as being able to drop items by using item level + loot table item min/max level

[fonsleenaars]

Agreed, the complexity of the actual drop table is higher than what the parser currently uses (just grab all possible drops, adjust the weights per table and calculate the final possibility).

What you're suggesting does seem to be the better idea, however it requires 2 fundamental changes in the current setup:

1. Provide input into an equation of some sort from the website through an input field
2. Provide a mechanism from the parser to translate the equations in the database to easy equations for input from step 1.

I agree it should be the end goal of the parser, however it will take me some time to run through the other issues first. The current priority is on getting the attributes/statistics per item to match what's in-game, as I seem to have hit quite a few exceptions after the last big update.

Thanks for the suggestion though, it'll help me get on track quickly after sorting out the current issues.

[giffsapros]

I wouldn't think you would need to update the website with any sort of additional user input - unless you wanted to allow website users to toggle the filtering? I was just thinking that the parser would check whether the item's level fell within the ranges defined by the loot table's minItemLevelEquation and maxItemLevelEquation, and if not, omit the item from the index built for the loot table's drops, so that bosses using that loot table would not be listed as being able to drop the item on the website.

Even with that limited scope, I agree it would be tricky to get this to work, depending on how complex the equations present in the database attributes are. Seems like you would have to write code for parsing the individual equations, or attempt to just evaluate the mathematical expressions directly as code with Python's eval function (lol).

Definitely understand if this isn't a priority though. Cheers!

[fonsleenaars]

Since I've worked on getting the loot tables expanded and added some more sources to it, it's time to make this a priority now. Work on it will begin now and it should be included in the next release.

[fonsleenaars]

You were absolutely right about the min and max levels capping what can be dropped.

This solves the initial problem, we can now:

• Parse minItemLevelEquation and minItemLevelEquation as it seems the only variable those tend to have is parentLevel which can easily be grabbed from whatever the parent is.
• Remove any items outside this range.

The second problem is the following, the bell curve weights are applied based on the targetLevel. For example, looking at the armband_e01.dbr file in the loot tables, we have:

minItemLevelEquation,36 * 1
maxItemLevelEquation,47 * 1
bellSlope,200.000000;200.000000;200.000000;100.000000;100.000000;100.000000;100.000000;100.000000;100.000000;100.000000;100.000000;100.000000
targetLevelEquation,((20 + parentLevel) / 2) * (1+(averagePlayerLevel / 75))

The bellSlope values are mapped for each level between the min and max, so basically:

Level 36: 200
Level 37: 200
Level 38: 200
Level 39: 100
...
Level 47: 100

The targetLevel sets the starting point for the list above. If the targetLevel comes out to 39, then 39 will start with 200, and so on.

For now I'm going to just run the min and max and remove the initial batch of items that can't even drop and then I'm going to think about how to handle step 2.

[fonsleenaars]

@giffsapros I have deployed the new data set (which has implemented the first step, removing items outside the range) to the staging environment here: https://staging.tq-db.net/monsters

You can browse around and see if this matches up better with what you found. The second step, which will apply the weights as I've described above will be implemented soon as well.

[fonsleenaars]

The second step has also been implemented, is currently live on staging and will be pushed to production with the 1.2.1 milestone for the parser.