Loot Table Problems

[ChaosSlayer]

Trev after thinking about it I don't think anything is wrong with current approach.

you roll a number
you check number of vs first item range, if satisfied- number is applied, if it fails you move to next number, etc
as long as you do not reroll, this system is prety mcuh identical to my if statements, you jsut have apply diffirent mechanics.

taking my table from above.
you go like this

rolled X (let say 96)

if X<51 then A else
If X <66 then B else
IF X<91 then C, else
if X< 101 then D
end if
end if
end if
end if


and yes you ONLY move to next value IF first comparsen has fail- but that oen kind of obvious. If first range is 1-10 and you roll 9 - thats a valid number for the range. If you roll more than 10 - then you failed the comparecen and compare vs next range etc


in SHORT the system works AS LONG AS NUMBER IS NOT REROLLED!! - thats the part which MAY BE BROKEN

[trevius]

Yes, that way works too, which is basically exactly the same as what you already posted.

The thing I think you aren't understanding is that the current system works like this as far as I can tell:

X = $random 0,99
If X > 9 then A else
Y = $random 0,99
If Y > 9 then B else
Z = $random 0,99
If Z > 9 then C else
X2 = $random 0,99
If X2 > 9 then D else
Y2 = $random 0,99
If Y2 > 9 then E else
Z2 = $random 0,99
If Z2 > 9 then F else
X3 = $random 0,99
If X3 > 9 then G else
Y3 = $random 0,99
If Y3 > 9 then H else
Z3 = $random 0,99
If Z3 > 9 then I else
X4 = $random 0,99
If X4 > 9 then J else

So, it randoms each time and if it doesn't equal less than that percent, then it randoms the next on the list and so on. So even if the last 5 on the list would have randomed less than the percentage setting, it would always only select the first item in the list as the drop and ignore anything after that. If I was betting money each time this was happening, I would want to be first on that list because the lower on that list you are, the greater the chance is that someone else will "win" before you and block your chance at winning.

[cavedude]

Your A-J example is a perfectly acceptable way of fairly picking a value. Assuming each of the 10 values have an equal chance of being picked, then they each have a 90% chance to fail their roll. The odds are strongly against any of them from being picked, that's what makes it fair. Provided the order of the values always remains the same, the "magic number" that needs to be rolled for a winner to occur is the same for each value, and finally and most importantly failed rolls are not removed from the pool then this system will work fine. In a way actually, the last value has a bit of an advantage in situations where a winner must be picked, because if nothing was picked above it, it has to be picked even if it was going to fail its roll. After all, odds are we'll get to that last number every 10th try

Now, this system works best if each value has an equal chance of being picked. If not, then the values must be listed in order from lowest probability to highest. If EQEmu does not do that, then we have an issue.

[ChaosSlayer]

Trev: ok I see what you mean

Cavedude, IMHO to avoid unnesesary complication why not substitute current system with something with more straight forward which does not depend on which order items listed in?

the value X should only be randomed ONCE, the all ranges can be put in a list ANY order (default so to speak) and made correspand to a range value in the list.

let say you have 5 items on the list: 10%, 25%, 5%, 20%, 40% (no need to sort)

the list then woudl look like this:
A(10)
B (A+25=35)
C (B+5=40)
D(C+20=60)
E(D+40=100)

now you roll your X 0 to 99, and let say you end up with 77.
Now you go into the list and see which range 77 falls into, lookign at gaps in manner of:
is X < A? if yes then A is true, else :
.......is X<B if yes then B is true else:
ETC

this looks way more straigth forward to me not to mention you save CPU time by only rolling ONCE

[KLS]

Assuming each step is required to fail before the next step then yes those at the final steps will have a lower chance to be triggered.

If you have an item list of 10 items all at 10% drop rate assuming trev's situation as described:

Item# | % chance to get to this step
1 | 100%
2 | 90%
3 | 81%
4 | 72.9%
5 | 65.61%
6 | 59.05%
7 | 53.14%
8 | 47.63%
9 | 43.05%
10 | 38.05%
No item | 34.87%

If you're item 10 and you're only getting to even roll 38% of the time even though you have 10% chance to roll just like item one. You're only getting the opportunity less than half as much. Clearly you wont drop as much, and also despite having 10 items at 10% drop rate on the slot you would not actually ever get 100% drop unless the last one was 100%.

Of course this is with how Trev describes it, I haven't taken the time to actually look at how it's implemented.

That said if it isn't currently a single roll system for items that share probabilities it should be.

[ChaosSlayer]

well yeah, i don't mind some items droping less than the others but only if they suppose to be more rare than the others =)
otherwise setting up % is complitly pointless =)

[trevius]

r = 10 (the total count of items in the table for this example)
totalchance = 100 (the total of the percentages in the table for this example 10 items each with 10% chance to drop)
thischance = 10 (the chance this particular item has to drop in this example. They are all set to 10 so it is the same for all)
found = true/false (this is set to true once an item is "found" to be the drop when running the while loop)

The While Loop:
k = random integer between 0 and 9 (10 - 1) in this example. This is randomed for the total number of items in the table

thischance = the drop chance % of the randomly selected item from the table
drop_chance = random percentage from the totalchance (100 in this case)

If drop_chance < thischance, it will drop this item

So, it should be randomly selecting an item from the list. Then it should be picking a random number from 1 to 100 in this case. And if the random number is less than the percentage drop rate on the particular item, it should be dropping that item.

That is, if I am understanding this correctly. That does sound about right, but judging by what other players and myself have seen, it seems like the system still isn't exacly as random as it should be. I am still checking into it to see if I can figure out if there is a reason for it, or if I have just had some really insane odds in some cases. I apologise if I am making an ordeal out of something that isn't an issue. But, if there was an issue, it would definitely be worth correcting considering that a large portion of the game is based on loot

[ChaosSlayer]

Originally Posted by trevius

That is, if I am understanding this correctly. That does sound about right, but judging by what other players and myself have seen, it seems like the system still isn't exacly as random as it should be. I am still checking into it to see if I can figure out if there is a reason for it, or if I have just had some really insane odds in some cases. I apologise if I am making an ordeal out of something that isn't an issue. But, if there was an issue, it would definitely be worth correcting considering that a large portion of the game is based on loot

well Trev you need to take few things into account when you say that "people are noticing". On LIVE when you would try to evaluate chance of mob droping something if you go to Allakhazam and pull up say mob which during course of EQ has been killed over and over for YEARS then yeah you could make a conclusions, but just a dozen kills you don't get much of statistic. Another important thing is the size of the loot table. If raid boss can drop as many as 20 items say all with equal chance, after 100 kills you not even scrathing a surface to reliable statistics. (btw you can give said boss a x20 loot multyplier and see how many times any given item gets picked)

For example on LIVE Aten Ha Ra has a loot table of 15+ items long and can drop up to 6 items at once (x6 multyplier essentialy). One guild has reported that out of 26 AHR kills (that over course of 2 years, and basicly 26*6=156 Random rolls) they got Leggins of Judgement total of ONCE. On my own first AHR kill I got lucky - she actualy droped them for me =)

There was another instance with one of PoP gods (can't recall which) and specific weapon that guy could drop. One guild reported that in 2 dozens raids they NEVER got it, yeat another guild reported that 3 of them droped on a single kill once.

essentialy if 2 items have equal chance of been droped, thats only a CHACE not a garantee. You can flip a coin all day long and get all "tails" =)
While statisticly you should get a 50/50 split, there is ZERO garantee that it will happen for sure =) But speaking pure math, as ammount of atempts approaches infinity, the probability slowly starts falling in line with predictions

[trevius]

Here is the code that KLS was mentioning where the loot is actually being picked to be added.

void ZoneDatabase::AddLootDropToNPC(NPC* npc,int32 lootdrop_id, ItemList* itemlist) {
	const LootDrop_Struct* lds = GetLootDrop(lootdrop_id);
	if (!lds) {
	 //   LogFile->write(EQEMuLog::Error, "Database Or Memory error GetLootDrop(%i) == 0, npc:%s", lootdrop_id, npc->GetName());
		return;
	}
	if(lds->NumEntries == 0)	//nothing possible to add
		return;

//Removed code for pool looting which isn't applicable to this example

#else
	//non-pool based looting

	int32 r;
	int32 totalchance = 0;
	for (r = 0; r < lds->NumEntries; r++) {
		totalchance += lds->Entries[r].chance;
	}
	uint32 thischance = 0;
	unsigned short k;
	bool found = false;
	
	while(!found) {
		k = MakeRandomInt(0, lds->NumEntries-1);
		
		thischance = lds->Entries[k].chance;
		unsigned int drop_chance = rand() % totalchance;
#if EQDEBUG>=11
			LogFile->write(EQEMuLog::Debug, "Drop chance for npc: %s, total chance:%i this chance:%i, drop roll:%i", npc->GetName(), totalchance, thischance, drop_chance);
#endif
		if (   totalchance == 0 
			|| thischance == 100
			|| thischance == totalchance // only droppable item in loot table
			|| drop_chance < thischance	//can never be true if thischance is 0
			) {
			found = true;
			int32 itemid = lds->Entries[k].item_id;
			
			const Item_Struct* dbitem = GetItem(itemid);
			npc->AddLootDrop(dbitem, itemlist, lds->Entries[k].item_charges, lds->Entries[k].equip_item, false);
			
			break;
			//continue;
		}	//end if it will drop
	}	//end loop
#endif

I am going to read this one over a few more times and see if I can figure out a better explanation of what I think is going wrong and hopefully a fix for it. I don't mean to stir up issues about this, but I do think something seems to be off. I am almost postitive that certain things will have a much higher drop rate even if all items in the table are equal. The way that I stated that KLS cleared up is how I currently am thinking it works. But I will read it over again to make sure. This was my guess as to how it worked even before checking the actual code, but looking at what I have posted here I think that might be correct.