Curse

MisterB · Jun 04, 2009, 07:12 AM // 07:12

#3 is true. See linked thread. Results can be repeated, and my own experience has shown that increasing killing speed decreases drops. There may be something like a merchant value/time figure that determines whether a loot scaled drop is assigned or simply vanishes, but that is simple conjecture on my part with no basis in fact.

Longasc · Jun 04, 2009, 08:01 AM // 08:01

There is definitely something to theory #3.

You can test it almost everywhere, killing a large group often yields only very few drops at all, while killing them one by one gives you a drop almost for every mob.

Now I would like to know if green and gold drops are exempt from this phenomenon?

LeoX · Jun 04, 2009, 09:51 AM // 09:51

I've heard of the theory of AoE/fast killing of multiple groups to drop less for a long time now, and I still think it's true.

I've experienced it lots of times too, often when I solo UW.
I've been using builds to kill 1-2 groups at a time, usually gets me average ecto and a few whites.
Builds which you rack up 4+ groups, there usually is 1 or no white drop at all and ecto make themselves rare.
Then not long ago I used a build where I killed each Smite on it's own in a group, and if you've just followed what I've said, you'll have guessed that I got several ectos. Although that run was really too long, so I think the best way is AoE, but don't tank more than 2 groups.

AoE on one group is the best way imo.

Sword Hammer Axe · Jun 04, 2009, 10:55 AM // 10:55

Well killing many foes fast seems to affect the drop rate. I have verified that on my different farms. Of course I can't be sure but I haven't been falsified yet.

For instance: Raptor farming. I go out to kill all the raptors as fast as I can and useually get around 4-6 items. Then I try killing them 1 group by 1 which useually gives around 8-15 items. And as such it goes on no matter how many times I try.

Hydra farming: If I pull as many hydras as I can and kill them all at once: 10-15 items throughout entire skywards reach. If I go slowly: At least first bag full.

However I have not been able to verify whether it affects gold drops as well, since it has always been completely random for me.

glacialphoenix · Jun 04, 2009, 11:39 AM // 11:39

Quote:

Yesterday I tried to get the thropies for the traveler, did 3 wipes of the hydras. Got 1 gold item, no purples, no cyans, a handfull of white and a handfull of coin drops. I think the area is overfarmed right now and won't drop claws anymore.

Tried today with 600/smite. One NM run yielded me all the 10 claws I needed, and I got another 6 in HM before dying to rubberband and lag. I'm not sure if it's keyed to you overfarming it, but the number of people who run in and out of the instance killing hydras shouldn't affect it.

Chico · Jun 04, 2009, 10:47 PM // 22:47

Quote:

Originally Posted by glacialphoenix

Tried today with 600/smite. One NM run yielded me all the 10 claws I needed, and I got another 6 in HM before dying to rubberband and lag. I'm not sure if it's keyed to you overfarming it, but the number of people who run in and out of the instance killing hydras shouldn't affect it.

Bolded for emphasis. Me overfarming it? Highly unlikely. I got 1 claw total. Last night I tried again and also got 1 claw (but did only 1 run HM). Ended up buying the claws. That was on a char that was unused for over 6 months and not even any other char on my account had gone anywhere near prophecies (except for LA). I think my necro is hexed for life with 'crappy drops'.

Anyway, back on topic. Doesn't 'sync zoning' simply proves all of the OP theories wrong?
Sync zoning is something any gw2x user can try to reproduce and was confirmed multiple times.
Sync zoning also proves my 'crappy drops' hex theory wrong (unless I can't sync and others can). It would mean that I lied or that I simply had bad luck while zoning.

Back then · Jun 04, 2009, 11:10 PM // 23:10

The drops work exactly the same way as Soul Reaping does now. There is a limit to amount of drops that will drop over a certain period of time.

For example, say the cap is 3 drops every 5 seconds. If you kill 100 enemies at once with AoE, you'll get 3 drops. if you kill 3 enemies every 5 seconds, you're more likely to get closer to 100 drops (although sometimes mobs simply drop nothing).

You can probably find out exactly what the number is by doing repeated farms of mountain trolls, using AoE methods and single methods.

Chthon · Jun 05, 2009, 03:06 AM // 03:06

Quote:

Originally Posted by Chicken Ftw

^This, but in more verbose format:

http://www.guildwarsguru.com/forum/s...php?t=10329475

This is correct.

The TLDR version is: There is a cap on vendor-sale-value/time on drops. Whenever you get a drop that puts you at or over the cap, loot scale will kick in and prevent you from getting any more non-exempt drops until enough time has elapsed that you are under the cap again.

Quote:

Originally Posted by Chico

There was a thread about syncing while entering an area. A necro and a monk would sync and once successful both got *almost exactly* the same drops. Same drops, with same mods, same chests, etc. except an off chance for 1 item being not exactly the same. What that proves is that it doesn't matter how you kill em, drops are assigned the moment you walk into an area and they can be sync'd.

This is not correct. The unimportant lesson from the synch experiments is that the seed for the PRNG is derived from the time when you enter a zone. That shouldn't be any surprise to anyone with even a basic education in computer programming. The important lesson to be learned from the synch experiments is that **something** is causing a slight variance in what should be identical drops. The explanation in the link above explains where that variance comes from, and does so in a way that is consistent with all of the data gathered in the synch experiments, and others as well.

lambda the great · Jun 05, 2009, 05:56 AM // 05:56

I tried this on spiders a week back. I balled them up and killed them with AoE and I got a total of 4 drops from them. Did it again with the same bar killing one by one, almost every spider dropped an item.

Gigashadow · Jun 05, 2009, 07:46 AM // 07:46

Quote:

Originally Posted by zwei2stein

Hmm, interesting.

I saw "sync zoning" research, but has anyone bothered to run those experiments too?
Also, were drop researches proofed against sample-choice fallacy?

The sync-zoning theory is almost certainly sample choice fallacy, which is something you see a lot regarding MMO loot. I remember many years ago players got this into their head about WoW loot, and once the idea caught fire, there was no putting it out until a full investigation was done.

The theories people have made up for Guild Wars regarding sync zoning assume things such as, the game has a personalized random number generator that is seeded when you enter the zone, so that if two people "sync enter" different instances of the same zone at the "exact same time" they will get the same drops. However, I will show that this also makes a lot of other assumptions.

If you think about it for a moment, you will see some big holes in the argument. First, you aren't going to be able to "sync enter" with someone on the granularity of any of the system timers, which is in at least milliseconds (e.g. GetTickCount()), which are what is typically used to seed random number generators.

Second, there is no good reason for the game to constantly re-seed its random number generators. If you have one random number generator per thread (not per process, otherwise you will just cause contention), then you seed them when the server process starts up, and not again after that. And in fact, the more unrelated game-related things you use those per-thread random number generators for, the more "randomized" they become. So your combat swings, loot drops, etc. would be interspersed with other things the game is doing (that reside on the same server box).

If the Guild Wars server is as efficiently coded as the client seems to be, it is high unlikely to be wastefully allocating one thread per instance. It is probably using I/O completion ports instead, if it is on the Windows platform (maybe it's not), so you would then have one random number generator per thread.

Third, even if you assumed that two players entered the zone at the exact same millisecond, AND that the game has a per-zone random number generator just for you, you would then have to be identical characters, and behave identically to your partner in every way. You would have to agro the mobs in the exact same way, from the same direction and distance. If you were playing a necro, and he was playing a monk, you will be using different types of abilities, using the random number generator a different number of times for the encounters. The mobs would die at different rates, and use different skills on you. By the time you're looking at loot drops, you have exercised the random number generator a different number of times from your partner.

You could then say "OK, maybe the game's combat and AI use a totally separate random number generator from the mob and chest drops." But there is no good reason to design the game that way, the point of random number generators is to be as random as possible. Or, you could say "Well, maybe the loot for every mob in the zone is pre-calculated first and assigned to mobs, before anything else happens", and maybe that part at least is true, although you still have the other issues.

Player "proofs" that random number generators are not random almost always turn out to be selection bias. There are some notable counterexamples though, that are due to game bugs, such as the Wi flag, and Warhammer Online's contribution rating.

note: I am just talking about the concept of sync-joining to "game the random number generator" to get identical loot, not loot drop rate scaling (there is abundant evidence that the latter does exist).

zwei2stein · Jun 05, 2009, 08:28 AM // 08:28

Quote:

Originally Posted by Gigashadow

...

Actually, I assumed this:

If instance creation is expensive process, devs could opt for prototype/cache pattern. Instance is created infrequently, stored to cache and if someone enters it, they get copy or clone of stored instance (something much cheaper to do).

In this case, it would be well possible to sync to "same" instance with some luck.

squiros · Jun 05, 2009, 09:39 AM // 09:39

nobody uses tick count. everyone uses seconds, at the very most. making syncing rather easy. seeding is almost instantaneous. it's a recursive -linear- function. meaning it can be done instantly, dozens of time, for almost no cpu cycles whatsoever. there are many good reasons to reseed - better randomization for one. it doesn't need to open a thread. . . it's simply a function call. since the random number generator generates predictably. . . it doesn't matter if you're a monk, a necro, or a cell phone. if you cast SS, SoJ, or favorite_five. the numbers are already generated.

"the default measurement of time, for most API's is seconds. the current time is actually the total amount of seconds that have passed since midnight of january 1st, 1970. the is pre-made, and included in time.h standard library. to get the time, you use a predefined class. a class is a collection of data. when your character is created is based on that as well.

int player_loot_seed = srand( time() ) ;

the resolution is SECONDS. time returns a class time_t. srand takes a time_t class. so if you zone in at the same second - which is well within most server lags, it's synched. it has to be the same second, obviously, not just within 1 second. "

instancing is not expensive. each enemy is probably a few bytes at most, creating their placement requires a struct reference and an origin.

on another note, AOE may seem to have less drops. it seems possible that drop rates are tied to the amount of times a character has farmed that area. so the more you enter, the less you get. aoe SEEMS to generate less drops because aoe results in faster farms, and consequently, more instances of the area being farmed. killing 1 by 1 will hit this farm flag later, resulting in what appear to be more drops.

Tenebrae · Jun 05, 2009, 10:27 AM // 10:27

Anyone who did keg farm and sliver farm can tell that the #3 is the right option. When 20 foes die at the same time , calculations are limited and tend to be applied to all of em. Sometimes i get nothing but a non-loot scaled drop and sometimes i get 7 golds , 5 drops , and money. As far as i can see , experience is the proof . Dont get me wrong , i believe in "luck" , Fate , coincidence , whatever you may call it but when happens 90% of the time .... its like a "rule" to me. So ...

Quote:

Originally Posted by Gigashadow

The sync-zoning theory is almost certainly sample choice fallacy, which is something you see a lot regarding MMO loot. I remember many years ago players got this into their head about WoW loot, and once the idea caught fire, there was no putting it out until a full investigation was done.

Player "proofs" that random number generators are not random almost always turn out to be selection bias. There are some notable counterexamples though, that are due to game bugs, such as the Wi flag, and Warhammer Online's contribution rating.

note: I am just talking about the concept of sync-joining to "game the random number generator" to get identical loot, not loot drop rate scaling (there is abundant evidence that the latter does exist).

Long post but soz , i dont think so. Drops are decided when zoning , even the chest ones , and i really believe they are assigned to mobs so it doesnt matter the order you kill em. Check this farming post by 2 bros , same house, same farm , diff profs and diff skill bar.
http://www.guildwarsguru.com/forum/s...php?t=10225077

for me , they prove that "theory" you mentioned.

zwei2stein · Jun 05, 2009, 11:31 AM // 11:31

Quote:

Originally Posted by Tenebrae

Long post but soz , i dont think so. Drops are decided when zoning , even the chest ones , and i really believe they are assigned to mobs so it doesnt matter the order you kill em. Check this farming post by 2 bros , same house, same farm , diff profs and diff skill bar.
http://www.guildwarsguru.com/forum/s...php?t=10225077

for me , they prove that "theory" you mentioned.

Did anyone trustworthy actually duplicate their test?

Regardless of that, there is no doubt that loot is generated per-area. There used to be bug with chests stacking stackables (in 8 man party, someone would bet two elite tomes, last person would get nothing from chest), proving that look 'bag' was already generated.

Quote:

Originally Posted by squiros

nobody uses tick count. everyone uses seconds, at the very most. making syncing rather easy. seeding is almost instantaneous. it's a recursive -linear- function. meaning it can be done instantly, dozens of time, for almost no cpu cycles whatsoever. there are many good reasons to reseed - better randomization for one. it doesn't need to open a thread. . . it's simply a function call. since the random number generator generates predictably. . . it doesn't matter if you're a monk, a necro, or a cell phone. if you cast SS, SoJ, or favorite_five. the numbers are already generated.

Sorry, but "LOLNO". This is game development. Everyone uses milliseconds. They do, because they need to track sub-second events. Hell, I have not seen used flat seconds in last 4 years, everything is in ms. Regardless of that:

Reseeding will *not* give you more random numbers. It will give you honorable mention in dailywtf.
Seeding from result of random is thing worthy of dailywtf submit.

Btw: Any autoattack would invoke random number call. it would. hence, even exactly same build would result in different sequence because player is gonna be autoattacked different amount of times per mob.

Quote:

Originally Posted by squiros

instancing is not expensive. each enemy is probably a few bytes at most, creating their placement requires a struct reference and an origin.

There is huge performance between lots of calls needed to init big structures from configuration and just doing memcopy.

Tenebrae · Jun 05, 2009, 12:00 PM // 12:00

Quote:

Originally Posted by zwei2stein

Did anyone trustworthy actually duplicate their test?

Regardless of that, there is no doubt that loot is generated per-area. There used to be bug with chests stacking stackables (in 8 man party, someone would bet two elite tomes, last person would get nothing from chest), proving that look 'bag' was already generated.

Did anyone trustworthy actually PROOF that thread is fake ? . How can i know you or anyone is trustworthy ?

My point is not the "drops are generated when you zone" matter , is that is possible to sync it . Anyway , whay are you SO sure that they ALWAYS use milisecs in EVERY seed ? maybe zoning is an exception. I highly doubt that ppl in that thread synched it to milisec level

EinherjarMx · Jun 05, 2009, 02:22 PM // 14:22

Quote:

Originally Posted by samerkablamer

Many people who keg farm, myself included as i used to keg farm, will tell you that killing all foes at once does nothing. It is purely random. One time i killed the north group of 30 or so foes, and I got 12 golds and 2 black dyes from one group. Insane drops, but that is because they are random. The reason that it is random instead of aoe effects drops or single target effects drops is because then people would exploit that part of the game in order to get the most drops possible.

Drops are random.
They have tried to be proven to an equation or theory, but after many attempts, people always say that it is unclear.
There is no pure way to know just how many drops you will get, and people that think they know are stupid, and people tat spend hundreds of hours trying to figure it out are wasting their time

once i got 2 r9 vspears from a HM slayers chest

pics or never happened

bad person · Jun 05, 2009, 03:56 PM // 15:56

Quote:

Originally Posted by Longasc

There is definitely something to theory #3.

You can test it almost everywhere, killing a large group often yields only very few drops at all, while killing them one by one gives you a drop almost for every mob.

In my experience, it's not an issue of killing all of them at once (or close to it) but more how long it takes you to kill once you zone. My prime example is from farming bandits in pre - there are 8 bandits and if I run there directly after coming out of Ashford Abbey and us an AOE skill to kill them I get very few drops. However, if I zone from the Abbey and just sit there for a couple of minutes (let the wolf walk around until it's not visible on radar) and then run and kill them with the same skills (and just as quickly) I get a drop from every one just about every time.

It may work differently in pre, but I wouldn't think the underlying code would be that much different.

tmakinen · Jun 05, 2009, 04:20 PM // 16:20

Quote:

Originally Posted by bad person

My prime example is from farming bandits in pre - there are 8 bandits and if I run there directly after coming out of Ashford Abbey and us an AOE skill to kill them I get very few drops. However, if I zone from the Abbey and just sit there for a couple of minutes (let the wolf walk around until it's not visible on radar) and then run and kill them with the same skills (and just as quickly) I get a drop from every one just about every time.

You have independently rediscovered the entry effect

Because drop values in pre are so low, once you sweat off the initial malus the drops won't trigger the cutoff level regardless of how fast you kill.

In my opinion the loot scaling mechanism is currently adequately understood. Those who claim otherwise just haven't bothered to go through all the evidence.

Chico · Jun 05, 2009, 07:55 PM // 19:55

I had never heard of the entry effect. It does explain quite a lot of things and proves wrong quite a lot of theories when put together with the sync zoning experiments.

squiros · Jun 06, 2009, 08:56 AM // 08:56

nobody uses milliseconds for seeding random numbers. a few odd functions may need it, but that hardly applies to the topic. silly undergrads =)