New loot system

[werebat]

I think I figured it out. It has to do with the number of items in the lootdrop. I had 30 items at a chance of 2. So when a kill happens, it was rolling for all 30 items at a 2% chance. Computers do not have a true random like a dice roll, instead it uses an algorithm to simulate the random numbers. So a 2% chance on 30 rolls would mean that 60% of the time you were likely to get a drop. Off 10 kills that is 6 drops which is about what was happening. So I changed the chance to 0.5 and now it is about 1 out of every 6 drops. So it appears your chance should be (desired % drop / # items in drop) to drop properly. I am not sure how low the chance can be set, but if you have a very large number of items in your drop, then it may not be feasible depending on limits. At least thats how its working for me. The old way with probabilty worked fine since there was only one roll made against it. The new system has its merits too so its just a matter of figuring out how to make it work for your purposes. One suggestion would be to randomize the seed before each roll. I may try this when I get a chance but for now the above step seems to working.

[ChaosSlayerZ]

that's exactly the problem with new system
you still have to pre-calc all the chance like in old system and then manually convert it to the new system.

For example if in old system you had a 3% chance to drop SOMETHING out of a list of say 25 items (4% per item) - you just set the probability to 3%, and fill out the item table with even chance per item adding up to 100%.

in new system you now have multiply all 4% by 3%, and set each item to 0.12% for each item. Ton of headache for no gain, not to mention loss of functionality.

[Elysius]

Cavedude you're the man but can we please change this back to the old way? I've stopped working on my server because the amount of work having to make a separate loottable for almost every single NPC is pretty daunting. :(

[revloc02c]

Originally Posted by cavedude

I'm not going to be around much for the next 2 or so weeks, but I plan on taking a look at re-introducing probability with its usage being optional sometime after then in October.

I see pros and cons of both the new system and the old system. I am wondering if you can just implement both by using the probability column as the determining factor:
If probability = 0 use the new system
If probability != 0 use the old system

Just a thought.

(Except the old system would be even cooler if the new columns Mindrop and Droplimit, and minLVL and maxLVL were included in it.)

[ChaosSlayerZ]

IMHO the only problem with old system was uneven RND.

The problem with new system beyond the screw up of loot table design user-friendly interface, is a loss of a significant feature such as utilization of a single loot entry in potential scenarios and variations.

If probability just added on top the new system I am not sure how this will work with each item on the list rolling by itself. Since new list is designed with no probability in mind. But I suppose this can be fixed with setting drop limit.


Again, IMHO simply keeping the old system (+fixing the RND number generation) AND adding the new features like Mindrop is the best way to go.

[chrsschb]

I've been using the old system for over 5 years now and what you guys call "weird RND" is truthfully part of what made EQ, well, EQ. The numbers ARE random, and I've seen every item in a table drop fairly closely to it's proposed drop rate when looking at the whole picture, not just a single person's bad luck.

2% drop rate on super rare item:

Guy one gets item in 5 kills
Guy two gets item in 45 kills

50 / 100 = 2%

Sucks for guy two, BUT THAT IS WHAT WE KNOW AND REMEMBER!

[ChaosSlayerZ]

chrsschb, your example if perfectly normal - but thats not what meant by broken RND.

Let me give you an example:

you have loot table of 10 items, 10% each, and multiplayer of 5. (100% prob)
In theory, you should get up to 5 different items per kill.
What happens in reality, is that RND generates numbers in close series.
So when RND is asked to generate 5 numbers in a row from 1 to 100, it doesn't pick 5, 20, 77, 13, 56. It picks 88,81,84,89,91. So when it comes to loot table, you end up getting 4 copies of item that sits in 80-90 range and 1 item in 91+.

This doesn't happen every-time but VERY often.

[chrsschb]

Originally Posted by ChaosSlayerZ

chrsschb, your example if perfectly normal - but thats not what meant by broken RND.

Let me give you an example:

you have loot table of 10 items, 10% each, and multiplayer of 5. (100% prob)
In theory, you should get up to 5 different items per kill.
What happens in reality, is that RND generates numbers in close series.
So when RND is asked to generate 5 numbers in a row from 1 to 100, it doesn't pick 5, 20, 77, 13, 56. It picks 88,81,84,89,91. So when it comes to loot table, you end up getting 4 copies of item that sits in 80-90 range and 1 item in 91+.

This doesn't happen every-time but VERY often.

I haven't ran into this issue, sorry.

[Traul]

I really like ChaosSlayerz proposed modifications. Is there any update/progress on this at all?

[prickle]

The changes seem ok to me. However, the only problem i have with it is the PEQEdit interface wasn't updated to account for the changes. So, when i though i was setting a 5% chance to get one of 30 items, i was actually setting a 5% chance to get each of 30 items with no limit, because the PEQEdit interface did not have the mindrop and droplimit fields and the default for both is 0.

Fortunately, it appears that GeorgeS GUI tools have been updated to account for these changes, which helps with correcting the drop rates.

[cavedude]

PEQ PHP editor was updated way back in September, Rev 342. Make sure to grab it from SVN and not the download. I'm not going to be maintaining the downloads anymore. I just don't have the time.

I'll get back to the loot changes soon. I'm going to add probability back as an optional part of the system due to the fact that you can no longer have the same lootdrop in multiple loottables with different percentages. But, I'm 95% certain that is the only functionality the new system lost over the old, so no further changes will be needed. Of course, if we come up with something else the new system cannot do that the old could, I'll look at that as well.

For those who plain just don't like it, you can always revert locally. It's only 1 method, part of another method, and a few database calls. That code is hardly ever touched, so you could probably continue on with it in a conflicted state and never be bothered by it.

[ChaosSlayerZ]

you mean the probability, not multiplier, right?

[cavedude]

Sorry, yes! I'll fix my post.

[ChaosSlayerZ]

thank you Cavedude

[ChaosSlayerZ]

So Cavedude, when can we expect the new source revision out with the changes discussed?