Loot Tables

[cavedude]

You have probability set to 100% as well, correct? I made the mistake of removing probability and then subsequently putting it back has caused most of the confusion about the new system since the SQL had to change twice and weren't really comaptible with each other. That's completely my fault, I am not sure what I was thinking removing probability.

Please post your test code that you used to both determine which order the items are being rolled in, and also how you simulate and log the loot rolls. My own tests have shown the chances are well within the acceptable range, and the players on PEQ didn't even notice when the loot system was changed in the code several months back. But since I rewrote the system, I am biased to its use. Perhaps you are trying to do something with it I did not expect. If there is indeed a problem I have no problem looking into it.

I must also point out, the code to determine the random order of the items and also the logic that rolls the items is exactly the same as in the old system. That code was pulled over with the small change that floats are now supported for chances. If there is a problem with it, it may be due to the function that generates the floats. However, that function is heavily used in our code. If there was a problem with it, I'm sure something else would have tipped us off by now. I don't see how order has anything to do with effecting chance, however. If I remember, once a number is generated that is used to roll against each entry per table. Order is irrelevent (in the case of mindrop and droplimit both being 0 of course!) since every item is being compared to the same value.

[noudess]

Originally Posted by cavedude

You have probability set to 100% as well, correct?

Please post your test code that you used to both determine which order the items are being rolled in, and also how you simulate and log the loot rolls. My own tests have shown the chances are well within the acceptable range, and the players on PEQ didn't even notice when the loot system was changed in the code several months back. But since I rewrote the system, I am biased to its use. Perhaps you are trying to do something with it I did not expect. If there is indeed a problem I have no problem looking into it.

I must also point out, the code to determine the random order of the items and also the logic that rolls the items is exactly the same as in the old system. That code was pulled over with the small change that floats are now supported for chances. If there is a problem with it, it may be due to the function that generates the floats. However, that function is heavily used in our code. If there was a problem with it, I'm sure something else would have tipped us off by now. I don't see how order has anything to do with effecting chance, however. If I remember, once a number is generated that is used to roll against each entry per table. Order is irrelevent (in the case of mindrop and droplimit both being 0 of course!) since every item is being compared to the same value.

Hi.

Hmm. I see now the detail with drop_limit=0. That nuance escaped me. So yes, for true percentages, without needing a drop_limit >0, I see.

I guess my question now is, do the devs of the dbs truely get this? I see many db entries with chances set up very poorly related to what actually comes out.

Who is master here? Is eqemu written to make the db releases work, or is the db tailored to make eqemu work?

To answer my detailed case, how would you make the db choose from 4 entries, always returning exactly one entry, where the odds are 10, 10, 40 and 40?

drop_limit=1,min_drop=1 does not work, as we get the resulting confusion illustrated in my table. The 40s dominate, with the 1st 40 getting the most.

Enter that into my spreadsheet and the drops come 5.6%, 13.8%, 29.5% and 25.1% for 1 trip through. The table doesnt handle when we need to reloop, but I believe it would just scale. This is what my test code and analysis matches.

I see now that the problem only lies with the above case.

Thanks for being so helpful. I hope to learn and be able to actually help at some point :P

[cavedude]

The PEQ DB is run by me, and up to recently was still using the old loot system for the most part (mindrop=0 droplimit=1.) Of course, as you've come to realize this produces loot with incorrect odds since once an item is picked, the rest aren't even rolled and yes even with a randomizied list the items with higher percentages will be naturally favored. These problems existed in the old system, and that's why it needed to be re-written (there was NO way to get true odds in the old system at all.) At least now, with probability set to 100% and droplimit and mindrop both set to 0, the odds will be as true as we can get them.

The DB end is a work in progress. I recently merged Magelo's data in, and over time you'll notice our data will begin to slowly take advantage of the new loot system with accurate odds. But, we have to make sure for example NPCs don't drop too few or too many items at a time. Sadly, Magelo doesn't provide average item drop count information so we have to figure that out on our own. By decreasing and increasing the number of items per table, strategically grouping items, and by carefully using mindrop and droplimit we can begin to see drop rates that match Magelo while also keeping count in a "normal" range. But, since every NPC drops a different number of items all with difference chances it isn't going to be an overnight process.