The key thing to understand is that Sony uses a XdY die system which is actually quite simple and flexible. EQEmu's system/schema cannot replicate Sony's output in all cases and is also less intuitive and more complex.
Treasure tables and item tables are essentially two components of EQEmu's singular lootdrop table. The treasure table contains the "frequency" which is the probability, plus the die size (which EQEmu lacks), die rolls (multiplier) and item table ID. Separating the tables this way allows item table reuse. EQEmu's analogs would simply be probability and muliplier; also I suppose mindrop and droplimit which Sony does not have. EQEmu does a probability roll for each multiplier iteration however so the functionality is not identical. When you reuse lootdrops in EQEmu, each master NPC loot table has their own copies of these lootdrop values to allow flexible reuse like Sony does.
EQEmu's lootdrop primarily differs in how multiple items can drop from a single lootdrop. EQEmu has multiple ways/modes of interpreting the table list. The original way lootdrops were handled was to simply roll each item individually and possibly drop each one if the roll succeeded. Sony's way adds up all the drop chances which must add up to 100% then rolls once to determine which item drops. EQEmu added mindrop and droplimit to ensure a drop or enforce a maximum. Unfortuneately these parameters did not result in actual drop rates that matched the input drop percentiles and often resulted in highly unpredictable drop rates, so new ways of processing the tables had to be added.
I bought up that issue in 2015 and KLS implemented a solution which improved things. KLS essentially added two new table processing modes. Instead of rolling each item individually, when mindrop>0 it will instead add up all the item percentiles together and do a single roll against it all and that roll decides the item, which is done mindrop number of times. This is much closer to how Sony does their tables. There is the minor issue of this being unintuitive in that you will end up with duplicate items when you would not expect them when you set mindrop>1, but it's otherwise more desirable because drops rates will end up more predictable. This is essentially a different table 'mode' because it's running an entirely different loop, but nothing in the editor form indicates this so it's unintuitive.
If droplimit > mindrop, ANOTHER loop is run after the previous loop, or is run in place of it if mindrop=0. This loop does a single roll against either the sum of the item chances or 100, whichever is higher. In that way the roll can allow the possibility that nothing drops while ensuring drop chances are as they are input. This is effectively a third table mode. It works well if drop limit is 1 and mindrop is 0; however this creates some issues otherwise:
1) It becomes impossible for more than one item to drop at the same time without re-running the loop, but rerunning the loop is counterintuitive when not handling mindrops; after all you wouldn't re-run the loop when mindrop and droplimit are both 0.
2) If you re-run the loop, you end up with too many drops; sometimes WAY too many drops depending on the table parameters.
3) If you re-run the loop, you can end up with mindrop+1 drops of the same item (items with multiplier set to 1) which makes no sense.
4) If mindrop>0, then the dropped items average is higher than expected; i.e. mindrop=1 droplimit=2 will drop significantly more items on average (even while the limit is enforced; varies depending on the item drop rates) than mindrop=1 droplimit<=mindrop.
In 2020 I implemented a somewhat crude solution for TAKP to mitigate the above problem by implementing a fourth loop which is run if droplimit is 2+ above mindrop. It is essentially the loop that would have been used if we were not ensuring that drop chances are literal to the table data. It randomizes the starting point of the items and rolls against them individually and exists once the limit is reached. This mostly works because the higher the droplimit above mindrop, the closer the results will be to the literal table percentages, so drops using +2 droplimit will be much closer to the table % than +1 droplimit. This does not fix problems 3 and 4 however, but will prevent high droplimits from creating a ton of items.
I see that in 2021 noudess did something to the drop code but he did not document the change and it's too much of a headache to try and figure out. I can't say what EQEmu's current state is exactly. Just writing this post was a headache. You can see how complicated this got just trying to make the actual drop rate match the drop chance input by the content developer. Even after all that, it still isn't accurate in all cases.
Best practice for content developers would be to avoid having a droplimit higher than mindrop if mindrop is non-zero and to not have a droplimit above one if mindrop is 0. Try to make drop chances in lootdrops add up to 100% and use multipliers and probabilities to drop multiples.
I'll use Dozekar as an example to illustrate the primary issue EQEmu has in being unable to replicate Sony's drop rates. Dozekar can drop between one and seven tear items. The chance to drop any given number of tears should be about 14.3% each (100/7 or 1d7). But the only way to try and replicate this with EQEmu would be to create two identical lootdrops of the tears, make one table a 100% single drop, and the other table 50% probability with multiplier 6. However if you do that the result will end up like this:
Kills with 1 total drops: 15334 (1.53%)
Kills with 2 total drops: 94001 (9.40%)
Kills with 3 total drops: 234776 (23.48%)
Kills with 4 total drops: 312521 (31.25%)
Kills with 5 total drops: 233834 (23.38%)
Kills with 6 total drops: 94101 (9.41%)
Kills with 7 total drops: 15433 (1.54%)
That was the result of a loot simulation script I wrote simulating 1,000,000 kills. This problem occurs for any dX roll of 3 or higher, so will be a problem for items like spider silk. So not only do you need to make two tables/lootdrops, but you cannot get accurate results even with two tables.
For TAKP I had Cavedude implement a 'multiplier minimum' field to lootdrops years ago which elimiated the need to make two tables, but the unequalness in drops probability remains for TAKP. This was not a good solution and I now know that a better solution would have been to add a boolean field which when toggled on would randomize the multiplier value when the NPC spawned from 1 to X. Even this would still only work if the probability is 100% because EQEmu does a probability roll for each multiplier, unlike Sony. That is also why simply adding a new integer field to serve as a die size wouldn't work for all cases.
|