Quote:
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