Talk:Anti-farm code

Something doesn't make sense here. If time between kills affects drop rates, how can the timestamp drop generation note be true as well? ···  Danny  Pew   Pew  19:32, 16 September 2009 (UTC)
 * Well, Drop generation and drop assignment are two different things. The loot is generated when you enter the zone, but the drop assignment seems to be done at time of kill. This is of course only based on my observations, I've tested the loot generation theory a while back. My brother and I did always get the same rare loot (not loot scaled, so we always get itsince we played solo), but the oher drops were randomly assigned, so we did not always both get the exact same non rare (loot-scaled) drops. Zophar 15:40, 17 September 2009 (UTC)


 * Hmm. I guess that makes sense. I was thinking specifically about Vaettir farming, where I never noticed a large decrease in the number of drops, but I reconsidered my drops and realized that the only things that might not have been dropping were the very things I wouldn't bother picking up - white items. ···  Danny  Pew   Pew  19:42, 17 September 2009 (UTC)

Player Tests
This needs clarification. The second statement contradicts the first statement. How does time between kills affect drops does it increase the rate of drops with an increase in time between kills or decrease the drop rate?
 * There are several factors if you want to calculate the optimal amount of items per time and they are both mentioned in the player tests. In first place it is the time between kills. If decreases rapidly if this is low. From then you have the time it takes to setup, the amount of kills you can make etc.. If you only have 30 percent change to get an item if you kill per 5 seconds you will get 60 items and 200 kills after 1000 seconds. If you have 80 percent change to get an item if you kill per 10 seconds, you will have 80 items and 100 kills in the same 1000 seconds. (Not looking at a few of the other factors) There is an experimental curve to be determined and based on that you can calculate the optimal killing speed. --[[Image:User_Karasu_sig.png|19px]] Karasu (talk) 21:11, 1 November 2009 (UTC)

Nicholas Gift trophies
This rule needs to not apply to those items. It will severely cut down on the time it takes someone NOT INCLINED to spend their game time farming to get their 5 Gifts and will drop that farming market off the face of the planet, good riddance. I'm tired of getting 2 trophies, then 1, then 0, then 0... I feel like I'm watching someone being auto-attacked under SoA. 141.165.170.184 20:45, 29 April 2010 (UTC)
 * I think the point of Nick was to cater to the casual farmer. You still spend a couple of hours over the time of a week farming for the items, or longer if you want to sell some items later, but it's not something that everyone wants to do. Datrulegend 21:18, 29 April 2010 (UTC)
 * I was under the assumption that trpohy items were not included in the code... I've farmed tons of area's and always seens the trophy items continue to drop even when my other drops have fallen to unworthy.... 65.6.156.101 11:26, 30 April 2010 (UTC)
 * Actually, I think nicolas is one of the proofs of many players farming the same area--84.196.119.34 22:48, 2 February 2011 (UTC)

Minute delay "resetting" drop rate?
I saw on another page that If you were to wait about a minute after entering a location, the drop ratio would in fact be similar to normal. Here is my source. I think it could fall under the third * under player tests, but it may be beneficial to define if this too is indeed a valid method to "reset" the drop rate. If true, I think it could mostly help boost the individual players that farm such items, like Nick's requested item of the week and all, along with helping the run-of-the-mill farmer.--Neithan Diniem 05:30, 10 June 2010 (UTC)
 * I think this might also be affected by the part of the code that seems to reduce drops when too many are being killed per allotted time. By waiting, it reduces the number of foes being killed per time. It is something I noticed as well, sometimes I'll leave my character for several minutes or just AFK for hours outside of the outpost, and always yields better drops per run.  -- Lania Elderfire [[Image:User Lania Elderfire pinkribbon.jpg]] 06:13, 10 June 2010 (UTC)
 * I would be interested to see this in some sort of data form. If we could decide on a way to track drops prior to pausing and then post pausing this could be semi-validated. Anyone with more data-experience have any input? Siris / talk  06:24, 10 June 2010 (UTC)
 * The only way I can see this working is if a person sync-entered an explorable a few times near a boss, and after drops decline one wait a minute before killing said boss. That would provide for a controlled environment for experiments... Wish I knew this when I did all of those raptor farms... --Neithan Diniem User Neithan Diniem Sig.png]] 15:01, 10 June 2010 (UTC)

Disputing "timestamp" test results
The "First (few) foe(s)" and "Time between kills" seems probable and it should also be easy to gain substantial statistic evidence to back it up. But I strongly dispute the "timestamp" theory. I have tried (several times) to set two computers up beside eachother, on the same (wired) connection, with an identic character on each account and I have made sure to enter the same area at the exact same time on each account. I have then slowly and deliberately killed the same mobs simultaneously on each computer and I have NEVER experienced drops to be even remotely similar. And even if anyone tries to tell me, it's because I have to enter at the EXACT same millisecond on each account and thus claim that the game calculates full drop tables for every instance in the game 100 or even 1000 times each second, then I will call the bogus card on this whole theory. Can anyone provide screenshots of the actual drop assignment to back this far fetched theory? --Manassas  10:17, 14 October 2010 (UTC)
 * Millisecond actually does matter, but not because the game is calculating drops 1000 times per second. What it likely does is use the timestamp as a "seed" for what's called a "pseudo-random number generator (PRNG)."  Randomized numbers in a computer application are traditionally spawned using PRNGs - which are typically fairly complex mathematical equations that produce a wide array of highly-varied (but evenly distributed) results over time.  To work, however, they have to be "seeded," which means simply given a number to start with.  So, for example, a PRNG seeded with the number "3" and asked to produce 4 random numbers would read in the numbers "3", "4", "5", and "6" and produce, for instance, "81", "288", "0", and "12," and will produce those same results EVERY TIME it starts with the number "3."  Using a precise-to-millisecond (or even nanosecond) timestamp as the initial value fed to a PRNG is quite common, as it ensures the PRNG is nigh-impossible to "rig" and produces superbly and absolutely random results without affecting game performance (since one beauty of the algorithm is that it's not doing any extra work no matter how precise the timestamp is). Even better, this timestamp value is usually calculated, to the millisecond (or more), by the operating system... so it's not only possible to use it to seed the PRNG, it's the most convenient and best-performing option realistically available. --guest 19:41, 22 October 2010 (UTC)
 * Okay, so in that case it's nigh impossible to reproduce because milliseconds count and server lag even at best is about 30ms.... I think that note should be removed. I think the only way to test if this actually exists or not is to have the Anet Developers answer the question... --Lania  [[Image:User Lania Elderfire pinkribbon.jpg]]19:57, 22 October 2010 (UTC)
 * Quite difficult, but apparently not impossible. The first forum link shows two guys managing to do it not once, not twice, but three separate times.  He mentions they repeatedly entered it until they were pretty sure they had it synchronized (using nearby spawns as a guide).  With 30ms margin of error, repeated attempts, and coordinated effort, it does make sense that it's testable.  It's not absolute proof, but I think coming up with a way to repeatedly cause drops (and chest spawn locations, spawn layout, etc) to synchronize is pretty strong evidence towards the theory. --guest 20:14, 22 October 2010 (UTC)
 * It's bogus --Manassas  [[File: User Manassas Mannysig.png]] 10:36, 27 October 2010 (UTC)
 * "It's bogus" isn't much of a counterargument. Have you read the thread in question? --Irgendwer 16:53, 27 October 2010 (UTC)
 * Random numbers in video games are never random because a computer is unable to generate numbers independent of anything. To create a "random" number, it is derived from a non-random variable, usually time. Tool-assisted speedruns are a good example of this. Each frame that passes will cause a game to behave differently, and speedrunners make use of it by optimizing random enemy movement, random encounter intervals, loot generation and the like. GW is probably not that different. Of course, enemy behavior is not randomly generated but things like weapon damage, block chance, and drop generation may depend on the amount of frames pass. Unfortunately, with 30ms of lag it is nearly impossible to be certain.  Koda  [[Image:User_Koda_Kumi_UT.jpeg‎|19px]]  Kumi  17:21, 27 October 2010 (UTC)
 * They could be random if ANet is using a hardware entropy generator. A geiger counter next to a few pieces of depleted uranium is the cheapest method, but you can have all sorts of fun with silly quantum effects if you've got the money to spend on hardware. I have heard rumors and seen videos of people receiving the exact same drop rates, so I'm thinking this is the result of one of any of the following facts:
 * 1) The only confirmed occurences were bugs. This is perhaps the most likely explanation.
 * 2) ANet, after discovering players could 'hack' the drop rate by entering simultaneously, updated the drop table seed (be it a RNG, PRNG or whatever else) to use an alternative method than time of entry, or altered the input to include more variables (milliseconds, microseconds, etc).
 * 3) The drop table implementation was redesigned entirely, or has a new component which obscures data. If the original videos with identical drops were shown before the introduction of loot scaling, it is possible that loot scaling and the raw drop table are two separate subroutines, each quite possibly using different seeds. For instance: if the raw drop table is calculated based on the time of entry but the loot scaling is calculated by the time an enemy dies, it is reasonable to expect one party to get different drops than another.
 * Those are just my guesses. If you like, I can ask Joe to dig around for the drop tables in the source. –Jette 17:42, 27 October 2010 (UTC)

A long time ago
A long time ago, me and my bro went into urgoz and had 1 person suicide on the mobs, other pick up loot. this earned about 1k a run. however, after 6 or 7 runs, a message popped up saying mobs dont drop loot anymore