Talk: Drop rate

Archives

/Archive 1 ~ February 2006 - September 2007

Drop rates for simultaneous kills vs killing one at a time.

Is it possible that killing several monsters simultaneously (ie with an AE damage skill) will generate less loot per kill than would killing one at a time? I could swear that I was getting Clovers much faster with my minion master build than with my AE damage spike build even though I was clearly killing the same large number of monsters much much faster with my AE damage spike build. If so why would there be a better reward assigned for killing one at a time than en masse? Is this a glitch/limitation of the loot assignment system or is it by design?Morbid Mordecai 02:55, 16 March 2008 (UTC)

Other people have seen similar things, it may be imagination, or it could be a weird bug.Entrea Sumatae [Talk] 02:57, 16 March 2008 (UTC)

Best way to check is to just pound out raw data. Repeatedly take the exact time it takes between the first one and last one dying and then record all drops, and then use a slower farm and do the same thing. If after a lot of testing the slower one got more drops with the same number of enemies, then you have an obvious case there --Gimmethegepgun 03:02, 16 March 2008 (UTC)

I know exactly what you are talking about as I have experienced the same thing and experimented with it a bit. I used my 55hp monk with SoJ being the main dmg skill. I would aggro a group of around 10 Hydras, and they would all die close to the same time. Once dead I would only recieve 3-5 drops, and they were usually of poor quality. Next I only aggroed groups of 1-3 Hydras, and low and behold I would receive 1-3 drops. Now that wasn't proof enough for me, so I emptied out my inventory and started again. This time I saved any drops that I got and tallied the totals. In HM farming Hydra's just outside Augry rock, aggroing groups of around 10 hydras, I picked up 24 drops, with aggroing 1-3 on the same run I didn't have enough room for all my drops...and the quality was waaayyy better. I plan to compile my next few runs and try some different areas. I have already done a couple of areas, but not enough to feel comfortable with the result, even though it was following the same pattern. My opinion...DO NOT FARM GROUPS LARGER THAN 1-4 MONSTERS AND YOU WILL RECEIVE MORE DROPS. More data to follow in about a week. --Chevy 00:18 3 April 2008 (UTC)

The Project + Drop type "Nothing"

From this page:

"Nothing: There is a chance that a creature will drop nothing. The probability of this happening early on in an outing into an explorable area is high and drops quickly as players delve into the area and kill more monsters. This seems to occur most when repeatedly solo farming the same area, some of the first 5 or so kills each trip will yield no drop."

Should this be noted in the numbered list for droprate? Is there some rule players contributing to the project should follow when gathering data? Constant rezoning and repeated killing of the first few monsters in a zone might not give accurate data... but maybe worrying about such cases is being too picky.

--76.234.23.19 09:59, 21 March 2008 (UTC)

Interesting point, but we have a lot of data already, and if we add a nothing collom we would have to collect it again to make sure the stats are fair RT | Talk

Polymock pieces?

What category are they in? Or is this not included in the data? Wondering where the best place to farm a polymock piece would be. The base ones aren't doing anything useful for me.

Inaccuracy in data-gathering method.

Apart from Guild Wars, I play an mmo called Lineage 2. And in that game I started tracking an item called "mysterious cubic" (an item you can use once a day to create 1 of 10 different items randomly once every 24 hours). I've been tracking this items rewards for 8 months now, every time I open it i put the rewards into an excel spreadsheet, I'm up to nearly 2000 uses (i have multiple cubic's).
Anyway. A few days ago a member of the clan I play with got the best item from it, and he told me about it so "I could add it to my research spreadsheet". There is of course a huge problem with that, I don't have all his other uses, adding this 1 piece of data would make the overall rates less accurate.
And when I opened my 1st 4th year birthday gift today and put it into the appropriate drop rate page, it got me thinking, how much more likely is it that people will do that if they get a good(gold/purple) item rather than a normal(white) one? I think that's a (possibly major) flaw in the data gathering, rare items get an inflated rate because people are more likely to report them than the normal white "trash"
For birthday presents it might not be a big deal, seeing as 1/year/character is already a pretty rare occurance. But for something like chest drop rates, or the Wintersday dungeon with the polar bear mini, people are much more likely to say something about their 1 awesome drop than their 99 useless ones.
Any thoughts? Viruzzz 15:53, 5 May 2009 (UTC)

Well, as a general rule of thumb, players should only post information on drop rate only if they decide beforehand. So, before I open the Shiverpeak Chest, I should say to myself that I am going to "record this down as drop rate information". If I didn't say that to myself, then whatever I open should not be recorded. This way, all recorded informations will be intentional. I think the wiki already encourages contributors to do this? Liadis 14:02, 25 May 2009 (UTC)

Time on Map

Question Does time on map make a differnce? Could someone get thier sin and do some 1 hour 2 hour 3 hour drop table, see if that improves ecto drop rates.

2nd level data

Some time ago I added 2nd level data to a few drop rate charts, and other than possibly triggering a few added rows here or there, nothing happened...

So, I'll try to describe how I did it from a link on my personal page. Lots of heady stuff involved, and I'm no statistics major or anything, so I don't even try to use all the correct terms (failed just now looking up the big important one categorized as 'method'. Sadly the built-in stat functions of spreadsheets fail at the task, so there's a fair chunk of equations to cover too... Yamagawa 15:05, October 17, 2010 (UTC)

Link for the page. Hope it helps. Any errors in the method are mine. Yamagawa 21:45, October 17, 2010 (UTC)

2nd level data, round 2

I've added a few templates into user-space that will calculate bounds for drop rates. They are:
{{DropRateLowBound|hits=1|tries=5}} -> 2.032
{{DropRateAverage|hits=1|tries=5}} -> 20
{{DropRateHighBound|hits=1|tries=5}} -> 64.04

The only reason I could name to omit leaving this out of our standard tool-kit is performance. I'm not sure if the functions qualify as 'exceedingly expensive' from the CPU side, but they arn't exactly 'light-weight'. On the plus side media-wiki by default will cache pages, so a given use would only need to calculate it each time the page (or a template in it) is changed, not each time the page is hit. I could code these as an extension, but there are tradeoffs there. I could change these to use a hard-coded confidence interval of 95%, which would let me cut out a good third of the math). Should I move these changes into the standard template hierarchy, or would a different solution be desired?

The upper/lower bounds use the Adjusted Wald formula as seen here: http://www.graphpad.com/articles/CIofProportion.htm For instances when no drops are seen ({{User:Yamagawa/Zero Drops/Templates/DropRateHighBound|hits=0|tries=50}} -> 5.8155079116972%), the bounds are calculated by taking the standard odds=(1-rate)^(tries) and solving for rate using confidence for odds. All results are rounded to 4 places (might still have problems rounding 0 to 4 places, but such outcomes should be rare and appear only early in the process of gathering data). Yamagawa 19:47, 15 December 2010 (UTC)

Templates moved to the standard template space. Yamagawa 18:35, 17 December 2010 (UTC)