Loot Tables

[noudess]

I am new here. I apologize if this is out of line, or has been hashed out. I've seen some posts about it, but I don't think they went into the depth this post is intended to.

The current way loot is picked out of lootdrop is very hard to predict. The spreadsheet I am linking here shows how the code behaves, and I use it as a tool to get the chance entries in the db to actually produce what I want. As you'll see, for the list of 4 items in this lootdrop table, items I want to drop 50%, I have to make 91% in the table, because of the way the software runs.

Full explanation is inside the spreadsheet.

So my question is. Do we not want eqemu software to reflect the percentages we type into these lootdrop entries? I think we do, which means we'd have to change the code. I have read and reread the code, and I understand the logic of it, but the very nature of how it works makes each entry depend on the others, which makes it hard to enter.

I ran tests on my server using the table linked to here. The numbers run pretty close to dead on with what my spreadsheet says, except that the random number of where to start seems to lean a bit toward starting at the top of the list. It starts there 8% more than it should. Not sure why.

Comments? I can share the data collection as well if you like. I used log messages to document every dropped item from these lootdrop entries along with where in the list it started and ran the numbers.

[ChaosSlayerZ]

does your server runs on code before or after these changes?

http://www.eqemulator.org/forums/showthread.php?t=35770

[noudess]

Originally Posted by ChaosSlayerZ

does your server runs on code before or after these changes?

http://www.eqemulator.org/forums/showthread.php?t=35770

After. I understand all that was said there.

[cavedude]

Set droplimit and mindrop to 0, and every item will be rolled once no matter where it is in the list.

I even mention in that post that setting a droplimit or a mindrop will effect the odds, there is no way around that. Something isn't going to be rolled one way, and something else gets extra rolls in the other. But with mindrop and droplimit set to 0, each and every item gets 1 roll, regardless of the outcomes of all the other rolls.

[noudess]

Originally Posted by cavedude

Set droplimit and mindrop to 0, and every item will be rolled once no matter where it is in the list.

I even mention in that post that setting a droplimit or a mindrop will effect the odds, there is no way around that. Something isn't going to be rolled one way, and something else gets extra rolls in the other. But with mindrop and droplimit set to 0, each and every item gets 1 roll, regardless of the outcomes of all the other rolls.

My example spreadsheet has mindrop and droplimit set to 0. I'll do some confirming before I post again, but I am pretty sure of my findings. I've had 1000+ spawns now, and the numbers in my spreadsheet are dead on(again, except that the RNG seens to favor starting at 1), showing that the chance entered is not very reflective of the actual chance.

[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.

[noudess]

Great to hear it is the same person running both! If I can be of any help, let me know. I've been tweaking stuff in my db loot tables just about every day, but I really don't want to grow apart from your db.