Trevius, you're correct that if the tables don't add up to 100% there will be trouble converting, though realistically counting errors of a few percent can probably be disregarded off the bat. They won't make much of a difference, and were probably created by a deleted item or a mistake on a single entry anyway.

But for custom setups like yours, you already figured out the solution. You'll basically be doing half of what the code was doing anyway, since in the end the total probability had to equal 100% from a mathematical standpoint. You'll just need to add the extra step of simplifying the chances down to their root percentage.

Oh Cavedude I strongly disagree that multiple lootdrop tables are no longer needed.

Look at following example:

So I have a Zombie in old system.
I want zombie to drop 1 body part and 1 weapon item on every kill

So you NEED 2 loottables for this:
loottable 1 - has all the zombie body parts in it
loottable 2 - has all the weapons in it

If you try to put this into same loottable and give a multiplier of 2 - you may end up in getting 2 weapons or 2 body parts per kill instead of 1 body part +1 weapon.

In your new system, this is still the case.

More to that, I don't have just 1 zombie type on my server, I have 50 different zombie TYPES from level 1 to level 50, EACH of whom can drop the SAME body parts, yet different gear.

For each of those npc types its much more practical to use TWO loottables - one to handle common body parts and another to handle gear drops, rather than to keep adding body parts into each and every gear table for each npc types.

Not to mention that gear loottable can be shared with other npcs - orcs, gnolls whatever, who can still drop the same weapon but NOT the zombie parts.

As you can see its way more practical to have:

-a loottable that handles create type unique items (per create type)
AND
-a lootable that handles universally shared items like weapons for given level range

and then use permutation of those to construct complete loottables for any given npc.

level 10 zombie will use:
-level 10 weapons table
-zombie body parts table


level 50 zombie will use:
-level 50 weapons table
-zombie body parts table


level 10 orc will use:
-level 10 weapons table
-orc body parts table


level 50 orc will use:
-level 50 weapons table
-orc body parts table


So as you can see I used 3 loottables to represent 4 different npcs.
And the difference only keeps growing as tables shared among even greater number of mobs, without the need to create unique table for each.

---------------------------------

PART 2

back to the subject on new system in general.
Going back to my example of where new item % drops are essentially multiplications of old probability times old item chance.

Math wise everything is the same, but human intuition wise - its a extra step added to get what you need.

In old system I would say: "I want an orc to drop 1 weapon out of 10 random ones once per 4 kills". And i would set my tables like this:

Loot_entry: mult 1, probability 25%
Loottable: 10 items with 10% chance each

In NEW system this converts to:

mult 1, droplimit 1:
each item set to 2.5%

Everything is identical MATH wise.

BUT in my mind to place data into DB with NEW system in mind, I still have to calculate "what I need" the OLD way, then do the multiplications in my head, and enter data the NEW way.

Now exmaple above is simple - cause its just 25% X 10%

now try soemthign liek this:

I want a mob to have 33% chance to drop something on his table that has 10 items in a following manner:

-item1 12%
-item2 9%
-item3 11%
-item4 8%
-item5 27%
-item6 13%
-item7 8%
-item8 2%
-item9 7%
-item0 3%


In old system I just set probability to 33% and items to what I want them to be.

In NEW system I have to do ALL OF THE WORK ABOVE PLUS do all the multiplication of item chance times the 33% and then put them in the DB.

I honestly don't consider this approach easier :(


The addition of droplimit and mindrop is GOOD.
But removal of loot_entry probability is not so great in my opinion - it makes things much harder to calculate in your mind and requires unnecessary per-calculation steps.

First off, you're over thinking everything including my explanations! :)

Obviously we still need multiple lootdrop tables, that's why I didn't touch that. What I mean simply is we now have ways to reduce all of our tables down to 1 if we so choose. The old way, we essentially were forced into using multiple tables.

Okay, completely forget about the old system... Probability never existed, in fact EQEmu never has had a loot system before today. As a human, when you flip a coin what is the chance it'll land on heads? 50%. Now do you think well, it becomes 25% because there is a 50% chance I won't even flip the coin? No. You will always assume whatever prerequisite is already met before figuring out chance. That's what I've done. That table is always going to roll true, you're always going to flip that coin. Now what do you want the actual chance of an item dropping to be? We only multiplied chance by probability to convert to the new system. From here on out, forget about doing that in your head. How often do you want the item to drop, figure that out and put it in your DB!

Going from 1) Probability 2) Multiplier 3) Chance Per Item

To 1) Mindrop 2) Maxdrop 3) Multiplier 4) Chance per Item

= Easier?


Does not compute. I understand what you're trying to accomplish, but the math is more difficult. My tables are already setup so that if I want something to always drop, it does, and if I want it to be rare, it is. I'm not seeing how this system is going to simplify that.

I'm still going to have to have multiple lootdrop entries in order to control the differences between loot sets (quest items, random loot, guaranteed drops, etc) so nothing there has changed.

/mindblown

Cavedude, this approach looks easy when you only have 1 item in question that you setting chances for.

Obviously if my only dilemma to drop a Rusty Mace at 25% chance I am not going to set it to 50% check to drop anything at all and then another 50% check to drop the Rusty Mace.

However once multiple items come into play the new approach becomes a more complicated way of looking at things.

Imagine following (old system):

Imagine you have a orc who may or may not have a BAG.
In side that bag he may have 1 out of 10 items each with different % chances.

So old system would very roll to see if an orc had a BAG at all, and then it would start looking at - what exactly was in the bag?

So if I want to set it up such that Orc has 33% to "have the bag" (in other words "have anything to drop at all"), and in that bag I want an Ultra Rare Sword to only drop 1 time out of 50, I would use the Old system to set:

-general lootentry to 33%
-specific item in that loottable to 2%
-all other items in that loottable to other % as it suits their rarity

And that's it - system runs itself.

But in new system to achieve all this I have pre-calculate all that and THEN multiply all my values to 33% and then put them into the table.

This leads to: my simple system of:

-orc has "a bag with loot" 1/3 of the time
-the bag has Uber Sword 1/50 of the time

to "Mob drops sword 0.66% of the time" which is counter-intuitive to me ... :confused:

Now imagine there are 9 other items "in the bag" and I will have multiply each and all of them by 33% to get the values for the new system.

I am not talking about just internal math/coding inside the server- I am talking about the way human brain approaches this. When you want a mob to drop something you not thinking in terms of "I want this mod drop to Uber Sword 0.66% of the time and a Chain Bracer 8.25% of the time".

This is most definitely not an easier way to think (as a human).
Most people (server devs I guess) when they are designing the loottables they won't thinking in terms: "I want the Uber Sword to drop 0.66% of the time" They would think in terms: "I want an orc to drop a bag with loot 1/3 of the time, and 1 out of 50 there will be an Unber Sword there"

Extend this logic to 10 or even more items pet loottable and you see how much more complicated setting up the data becomes.
You are forced to move from nice round numbers like:

-mace drops 10%
-sword drops 15%
etc

to things like:

-mace drops 3.33%
-sword drops 1.678%

etc

Again, the final math will be the same, but setting up the tables is definitely becomes a headache. :(

ADDITION

I pondered on this some more and found another SIGNIFICANT problem concerning removal of probability rolls.

You have a loottable that has some weapons on it.

You have following npc types:

orc pawn
orc trainee
orc apprenties
orc warrior
orc centurion
orc legionary
orc warlord

You want EACH of them to have a chance to drop the weapons from your weapon loottable, BUT you want each of them to have different drop chances like this:



orc pawn 10%
orc trainee 20%
orc apprentice 33%
orc warrior 50%
orc centurion 66%
orc legionary 77%
orc warlord 90%

In OLD system what you do is:
-you make a SINGLE weapons table and then assign it to each orc type with a different probability chance.
DONE

In NEW system, I have to create SEVEN different loottables, ALL of them containing identical items but with different item chances multiplied by the probability factor I no longer have access to.

So aside from having to do things like: "multiply 25% item drop chance by the missing 33% probability factor" I have to do this for SEVEN different loottables! Not to mention create the otherwise identical loot-table SEVEN times over.

So my work load just went from "creating loottable ONCE and giving npcs types 7 modifiers to drop it", went to creating 7 NEW lootables over and over and doing my best of not mess things up when putting in the numbers like 6.75%, 13.75% etc.

Now imagine that beside orcs, there are gnolls, kobolts, ratmen, and whoever else, all whom use to have a SINGLE weapons loottable.
NOW, For EACH of them you will need an INDIVIDUAL loottable entry.


So, which one you think is the better "user interface"? ;)

Looks to me like you could essentially just not update your loottable.cpp and loottable.h then you just have to worry about the zonedb.h using the old function:
void AddLootDropToNPC(NPC* npc,int32 lootdrop_id, ItemList* itemlist);

If you are not interested in the new solution then this is another option.

Currently I have every item in the database (except epics) capable of dropping at a 2% chance for all mobs and it works great. I have not updated yet so I am curious what changes I will need to make in my script. It does look promising though. I plan on updating when the newest db is available.

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. It'll also be best to hold off on feedback about the system until then as well. It'll give everybody a chance to actually use it, and honestly anything said during that time will be lost as I won't be able to keep up with the forums.

Thank you for your consideration Cavedude.
I would not be stirring things up about it, if I would not have genuinely believe that we are stand to loose a helpful feature here.

adding it back in as a server rule would be good then it can be enabled or not by custom content providers like many other features.

Came in to post exactly what ChaosSlayerz did, particularly his ADDITION post. This change has made things much more difficult for me.

Couldn't we simply re-add the probability on individual loottables and have it default to 100 when creating a new one?

I can say that I've got loot dumped for all expansions, I just need to refine it and comb through it with Cavedude before finalization.

http://i.imgur.com/3f1tL.jpg
http://i.imgur.com/tETry.jpg
http://i.imgur.com/OBW21.jpg
http://i.imgur.com/uD0NQ.jpg

I am using the new loot system with the defiant armor sql I created. I have chance at 2, mindrop at 0 and droplimit at 1 since I would like a rare drop rate wit no more than one item. But the items are dropping at an incredibly rate. I had 4 pieces drop off of 6 kills. Not sure if I have something set up wrong or if the code needs to be fixed. Under the old system the rates were pretty accurate.

New system works fine on my test server and I is live on PEQ also. Post your SQL.