I believe the concept is that it doesn't matter what other people are able to link. If you are unable to link something and then are able to and the only difference is having zoned into the instance where that item drops, then a likely reason is that it has been loaded on the server cluster cache because a boss is going to drop it.

Sunwell will be the perfect time to test this. Walk into SP and start trying to link Brutallus drops (make sure someone else is there and not clicking links to avoid any soft resets while you constantly crash). If you can safely link two of his items and none of the others (discounting tier pieces) then there's a good chance that loot is loaded on a server cache as soon as it is loaded on a raid boss.

Of course you have to make sure that no one else on the server is going into their own SP and ruining your pristine field...

No, WoW does not use timestamps to select loot, it uses a random number generator (which may be seeded at is inception with a timestamp): WoW Forums -> Is Loot determined when the moster dies?

I havent read all of this thread, but I just wanted to comment on something many people seem to ignore, or just not think about.

Yes, there may be these instance seeds based on a timestamp (or whatever crazy theory you have). But they are a SEEEED in a number generator. If you plug that same seed in multiple times, you will get multiple results. It's simply to start the RNG process, as far as I understand.

So even if you could create that same seed over and over again, be it a raid leader, a timestamp, or which non-combat pet you have out, it still will not influence any loot drops in any controllable manner.

I admit I have no knowledge of how these systems, or WoW's in particular handle the random generator, but surely what I said above makes sense.

Getting loot from instance or outdoor mob isn't anyway different from each other. The most people have witness this before by server rollback. I recall several times when I have looted some items and server has roll backed resulting loose of items and mob spawn again where it was killed. Killing same mob again results different items. Same principle most likely is used on instances.

So, each time dungeon soft resets, server creates loot table to bosses that are available when you enter. If you clear half instance first day and come back another it has different loot table generated than before. By doing like this, you save valuable storage space by not holding hundreds null instance loot tables etc more than few hours until dungeon reset by itself.

Like it was posted by blue, when person enters instance and "create" it, loot is randomly rolled and I think its impossible to determinate any way what some creature holds. It would require cracking blizzard server database and I wouldn't recommend to do that.

Sorta. A non-quantum deterministic RNG is just an algorithm that takes one number in, and spits another number out.

Consider this (very simple, not-very-random) algorithm:

1) Multiply your seed by 86
2) Perform modulo 100
3) Return new number.

Input: 43, * 86 = 3698 % 100 = 98, which is your new "random" number.

Every time you put 43 in, you get 98 out. Now, RNGs typically work by using the last generated number as the input for the next number, so the next time we call our random function, we get:

98 * 86 = 8428 % 100 = 28

And the next time:

28 * 86 = 2408 % 100 = 8

So, you seed the RNG with 43, then the next 3 random rolls are always 98, 28, 8.

Typically, you want to see your RNG with a number when you first start your program. The classic value is an integer representation of the timestamp (number of seconds elapsed since Jan 1, 1970 is a common one). This produces a different seed each time the program is run, and thus, a different series of numbers.

Thus, the best way to game the loot system would be a) /random until you get the seed you want, and b) zone in. However, this assumes that:

a) Blizzard doesn't re-seed the RNG with the timestamp on instance zone-in
b) The instance server contains the same memory space as the non-instance server, so both servers share the same random seed, or the instance server's seed is initialized based off of the world server's last random number value.
c) Nobody else causes anything to happen that invokes the random number function between the time you roll your seed number, and the time you zone in and the loot tables are initiallized.

One thing about timestamp-based seeding: It doesn't work like "It's 5:49 PST on Wednesday" - instead, it generally counts either seconds since system boot, or seconds since epoch (traditionally Jan 1, 1970). Thus, even zoning in at the exact same time every week would not reproduce that RNG seed.

Not quite correct. First, it's a Psuedo-random number generator, not a true number generator (true RNGs don't have seeds anyways). If you put the same seed into two identical PRNGs, you will in fact get the exact same string of values, for as long as you desire to evaluate the PRNG algorithm.

The actual randomness comes from when you sample. If you plug the same PRNG seed into two WoW servers, and let them run, they will start exhibiting divergent behavior as on one server someone is using those seeds to determine rogue poison procs, and on another to determine the loot off deadmine mobs.

So basically while the WoW number generator is technically a deterministic PNRG, so long as you share that PRNG with other people you're sampling it at effectively random intervals, making it a truely random system. The characteristics of PRNGs (particularly, the analogue of independence of events in true RNGs) ensure that a very small amount of randomness in sampling is sufficient to ensure effectively complete randomness of sampled numbers.

That's a completely academic consideration, though. The question at hand is whether it is possible to determine the result of a sampling before you permanently lose the option to re-sample.


EDIT: (followup to antiarc's reply) Note that if every 43 is followed by a 98, it's a crappy PRNG because events are not independent. Every time you saw a 43 you would know the next N events. This is generally solved by (eg) having a similar system carried out behind the scenes to 4 digits, but only reporting the first two, effectively giving each reported "43" one hundred possible types of 'true' 43 it could be, each with its own different target. Of course, in this case the next two or three numbers would be sufficient to characterize its current state. Cryptographically secure PRNGs (which blizzard uses) have an unreasonably large interval required to uniquely identify the seed--generally larger than the data capacity of the internet.

These tables can't be like this. We've had 4 kills on Illidan and random stuff that has dropped goes like this:

1st kill: [Cursed Vision of Sargeras] + [Cowl of the Illidari High Lord] (double armor)
2nd kill: [Faceplate of the Impenetrable] + [Zhar'doom, Greatstaff of the Devourer]
3rd kill: [Black Bow of the Betrayer] + [Crystal Spire of Karabor] (double weapon)
4th kill: [Memento of Tyrande] + [Stormrage Signet Ring] (ring + trinket)

So as you can see we've gotten double armor (1st kill), double weapon (3rd kill) and trinket+ring (4th kill). I'd say there is 3 tables on Illidan; Tier, Random stuff (weapons, non-tier armors, rings, trinkets) and Glaives.

This has been discussed before, there're most likely one table per drop; that is 5 tables for illidan. Something like this:

[tier]
[tier]
[crap] (50% on random loot)
[crap] (rest of random loot)
[glaives] (big chance for empty, small chance for either)

This guarantees that two same random epics cant drop, while two same tier pieces can drop.

Moreover, loot is generated on drop, so link-trying wont help any bit in attempt to find out loot. Try zoning in raid zone on fresh server and query for some certain drop (quest drop most likely exist as you can link them via available quests).

Furthermore, "time stamp" referred earlier is probably unixtime, it's pretty certain that wow backend doesnt run on x86 or am64 or other "desktop" hardware (according to job descriptions etc)

Sheesh, I didn't think of the possibility to roll double random items with one randomstuff-table. Indeed, this makes more sense like this.

There are also those superstitious beliefs that always develops, like for instance that you need to kill all four adds to get max chance of the caster trinket to drop from Hex Lord, or trap Illidan every time for Warglaives.

One thing that was suggested from the beginning of this thread that I haven't seen addressed much is whether the cache clears on server restart. I would expect that if it was and one were to log in immediately after the servers came up, you'd be unable to link anything even slightly esoteric. While its possible that Teebu's is generated in some mob's loot somewhere on the server, just looking for the epic drops from level 60 dungeons should generate issues. Perhaps the best one to look for is the [Chromatic Carapace] which is unlikely to exist even for those who have looted in. [Pristine Hide of the Beast] would be another option.

I just find it extremely difficult to believe that the item cache is cleared when the game restarts; it would seem to use up a lot of needless processing to refill the list every one to two weeks. On the other hand, if every item that come into existence in the game needs to check the cache to see if its there already, I suppose the additional time to add it to the cache is tiny compared to the number of requests.


Kill all of Garr's adds first to increase your chance of getting bindings!

Latency will also add an effective extra random value to this, depending on the precision of the Timestamp. Even if the Timestamp was restarted after every server reboot, you still most likely wouldn't be able to zone in at the exact same time causing the exact same loot to be created, due to the fact that latency will mean the server might very well progress your request just a second sooner or later.

As others have said though, it's more likely that a single PRNG function is called for all random numbers WoW needs, and due to the fact that there's probably a very large (and very varying) amount of requests made to this function per second, the results of any individuals requests are basically going to be random for all intents and purposes.

Correct, and I absolutely stand by it. Because it's absolutely correct as a practical matter. And thank you for your most excellent illustration of my point.

Illidan drops:
2 Tier 6 Chest Tokens (Any, can be the same)
1 Caster Loot
1 Melee Loot
1 Warglaive (sometimes)

Thesis: How the loot tables work

This is really the nice thing about WoW or any MMO in terms of RNG. Some level 12 hunter killing worgen in Silverpine influences whether Illidan will drop warglaives for your guild. His pet gets a crit just a microsecond before your raid leader steps into BT and then four hours later your rogues are crying because "it never fucking drops for us". Blame that pet then? Or blame the millions of calls to random() which came before that?

If you think back long before MMOs, back to the time of single-player games on a network with a shared highscore table, for example Hack. Those games were often seeded with the lower 16 bits of the unix time() function. Which meant that, since you'd likely have the source code, you could calculate a list of seeds to give your game (your personal instance) optimal starting conditions. Then it was just a case of spawning several games whenever the timestamp would provide a good seed and saving them for later play...

The OP has an interesting idea, because he realises that a better thing than somehow 'influencing' a RNG is to let it reroll. This is presuming the Illidan who eventually drops the glaives doesn't recreate his loot table on wipe, and that you can even find a battlegroup with no glaives in the item cache. The problem is that if you do find a workable usable trick to guessing what a mob will drop, then won't it just be nerfed/hotfixed immediately? Otherwise what was the point of Blizzard making it random in the first place? And if, as has been suggested, in WotLK more mobs will show the weapon they will drop, won't they be forced to limit this to non-raid mobs? Otherwise you spend Tuesday/Wednesday evening spawning lots of raid instances until you get the perfect set of drops for your group?

Agreed. The people here that say "keep /roll ing until you get the number you want then zone in" are missing this point. By the time your brain has registered the number returned, the server has already moved on to the next few hundred numbers.
Check that player's attack table...
Check this mob's attack table...
Check if that potion just increased the alchemy skill...
Generate the damage value on that attack...
etc...

Processor speeds on common desktops are running 2.5 to 4 million calculations per second.. even if a fraction of them are for the PRNG, actually predicting the sequence and acting on it is simply beyond human reaction/control times.

If Blizzard does indeed do this, at an attempt to add more life into the world, I am sure they will be working on a solution to prevent reset-farming. One easy method is doable similar to ZA, where you get saved before you have a chance to see any of the boss drops.

And remember, there are tons of drops that are desirable from dozens of bosses out there that don't have an visual representation, so an image change would not indicate yes/no on those particular drops.

Would guilds even kill Illidian if they knew he wasn't going to drop a warglaive? I think so. After-all, there are only so many rogues/warriors in any 1 guild that would use them. The rest of the raid needs upgrades too.

Actually, just the opposite. The assumption is that Illidan would indeed generate a new loot table with each respawn (each wipe). The idea would be if you were to SOMEHOW have the perfect set of circumstances, and had a server without the glaives in the item cache, then began wiping until a glaive could be linked, that he would drop the glaive if you killed him that time. It's a neat theory, but pretty much an impossible set of circumstances.

I'm still of the opinion that it wouldn't work. While we know that loot drop is determined on mob spawn, I don't think an item counts as "seen" by the server (and is thus linkable) until that bosses death occurs and it become a lootable item. Still, no real way to test that idea until sunwell, and even then it would be a difficult undertaking considering that you'll have to consider every sunwell instance on your battle group could be creating linkable loot.

You're right though, even if this does work I'm sure they'll fix it. Still, it's an interesting discussion to try and suss out a reasonably unknown mechanic.

Hmm, you bring up an interesting point. Now that I think about it, I've never seen or heard of a boss (BC or Pre BC) dropping duplicates of a random loot piece (excluding Tier pieces). Has anyone seen anything negating this theory?

Extensively discussed, widely accepted, and has its own thread.

As was linked earlier:
Thesis: How the loot tables work

It is well-accepted by now that loot is generated when a mob spawns, not when it dies.

Preemptively linking proof before we get another "link a survey" fiasco: WoW Forums -> Is Loot determined when the moster dies?

I agree, this is one of the nice things about it. So nice that, before the recent Blue post confirming "loot is generated when the mob spawns," if I wasn't in a run and something I wanted dropped, I would shrug it off under the viewpoint of if I had been there, the RNG would have been in a different state, and loot would have been different -- so I didn't really miss anything. It really was nice to not resent missing a run with this philosophy! But, alas, the blue post did come out, confirming that the loot is determined well ahead of any influence I could have in-instance. There does seem to still be an open question of soft resets vs loot, but it is deterministic enough that I'm back to ruing when something drops and I'm not there to get it.