Items toward bottom of loot table not dropping fix

[govtcheeze]

Edit: see posts below for full fix

[govtcheeze]

see diff file below

[killspree]

Nice work!

[Doodman]

I've not looked at nor played with the loot table code at all, so take this with that in mind.

Are common, rare and ultra rare loots in the same loot table? If so, then wouldn't the more common drops be at the begining of the table and favored like they were?

Perhaps there is a bug in there making the ultra-rare drops impossible to drop, but I just want to make sure that making this changes does not effect the drop rate of common vs rare.

[sotonin]

No that's not why the system was made like this.

Each individual item has a chance value that is set. That is how you determine how rare or common an item is.

example:

the mob drops 5 items.

you want all items to drop fairly the same except for a rare item.

item1 = 24
item2 = 24
item3 = 24
item4 = 24
item5 = 4

This makes the first 4 items have a 24% chance to drop. the 5th item has a 4% chance to drop.

This is how it was clearly designed to work, but with the current system it does NOT work this way because of why govt explained. its looping through all items. Which is a terrible way to do this.

There is no common vs rare deciding factor except how you set the mob to be. if you open up a looteditor you'll see this. There are 2 values on the loottable for the mob.

Probabilty and Multiplier.

Probability is just how it sounds. if set at 25 the mob should drop an item 25% of the time. the other 75% drop nothing.

Multiplier is how many items the mob CAN drop, (when he does indeed drop something)

Then each individual item in the lootdrop entries has a chance associated with it. if there are 10 items you divide 100 by 10 and give each item 10% chance. Or modify it accordingly for rare drops.

The way it is now. Regardless of how many or few items you have. The first 2 items in the table are ALWAYS attained most of the time. (if multiplier is set at 2)

The system was designed to give the world builder flexibility in percentages to make things drop more common or more rare. but the system is throwing it out the windows by forcing all the items near the bottom of the table to be very rarely or never dropping, regardless of if you wanted all items to drop at the same ratio.

[govtcheeze]

Actually sotonin, I found out it does NOT roll a strict yes/no for "will something drop":

	for (int32 i=0; i<lts->NumEntries; i++) {
		for (int32 k = 1; k <= lts->Entries[i].multiplier; k++) {
			if ( (rand()%100) < lts->Entries[i].probability) {
				AddLootDropToNPC(npc,lts->Entries[i].lootdrop_id, itemlist);

For each item that can drop, if it passes the rand() test it will add an item to the mob (if it also passes the check for the item in addlootdropnpc). If the for and if statements were reversed, then it would be a strict yes/no for "will stuff drop".I know I said this doesn't happen when we talked about it, but I was looking at the wrong code

In the current system, using sotonin's example, item1 is ALWAYS tested to see if it drops, since it is first in the array. item4 is only tested if FOUR other tests fail...this is not truely random itemization. Now imagine this in a loot table with 80 items (which a lot of sebilis tables are)...items toward the bottom have a significant mathimatical disadvantage, since 70+ checks must fail before the item even has a chance...and then it still has to pass it's own rand() check.

This system keeps rare items rare, since the item must still pass the second, individual item chance test. The only difference is items near the beginning of the loottable are not more likely to drop.

[govtcheeze]

The only thing I worry about are loottables that are not set up correctly...where multiplier is greater than the total number of items in the table. This will cause found to never be set to 1, and cause an infinite loop.

I think this will fix it, but defintely needs some testing (currently at work, not able to test ATM):

In function

const LootTable_Struct* Database::GetLootTable(int32 loottable_id) {:

			loottable_array[loottable_id]->Entries[i].lootdrop_id = atoi(row[1]);
			loottable_array[loottable_id]->Entries[i].multiplier = atoi(row[2]);
			loottable_array[loottable_id]->Entries[i].probability = atoi(row[3]);

+			if(loottable_array[loottable_id]->Entries[i].multiplier > NumEntries);
+				loottable_array[loottable_id]->Entries[i].multiplier = NumEntries;

			i++;
		}
		mysql_free_result(result);

[Doodman]

Okay, sounds good.

Like I said, never looked at the loot table stuff. Looks like a good fix.

[monalin crusader]

What lines are all these? I would love to impliment it but i dont know where.

*EDIT*

NM i found it its at 521 in loottable.cpp

[govtcheeze]

Has anyone had problems running this? I just got a report from PEQ that this was added (with other code updates) and it became unstable. If it was a piece of this code, would like to track down the problem and fix it

[cavedude]

I know this doesn't help any, but I have been running this code for a bit with no problems and my compile isn't even close to stock CVS. Perhaps it was one of the other changes they made or possibly a clash between multiple changes.

[monalin crusader]

I dont know if this has anything to do with this but alot of times WHENEVER i compile something it becomes unstable i'm not sure why but if i compile source i just got it becomes unstabe but i also noticed my compiler is adding about .20mb of data withought changing the source. Part of the reason i think it does this for ME is because i'm using the Introductory Version of C++ 6.0 because it was the only thing i could afford.

[fathernitwit]

hey,

I made a patch file out of this thread:
http://eqemu.psend.com/files/loottables_fix.diff
applies clean to 7-31-04 cvs.

it fixes a typo in the Database::GetLootTable mod as well.

[fathernitwit]

In reply to myself...
I did some testing with the project eq folks, and foudn that the code in this thread has some major flaws. So I rewrote it a bit.

The patch linked in my previous post has been updated to a version which I believe works much better.