I'm quite interested in finding out a method of reverse engineering the random element of WoW. Is there any kind of mod that will record as many variables as possible for when loot is found or when rolls are made? I have heard from several sources that loot is determined at the mob's spawning (or when the instance is created, for raid-type things), but what determines this? Class, name, gear, level, time of zoning in, time of raid creation, number of members in the group?

Even something such as recording the times of a standard /roll would be useful, perhaps even turning rolling for items into a timing game of skill instead of a game of chance.

If we could get a mass of data about it, there could eventually theoretically be a way to determine loot before a boss dies. Maybe. Maybe I'm just exhausted from staying up too late.

It's random.

My money is on the seed being srand(time(null)).

Programmers are lazy like that.

This wouldn't surprise me at all, but again, when is that called? Raid creation? Zoning in?

If there were a way to tell, perhaps my raid could find a time to zone in/make the raid so we don't get 12 cenarion/felheart melts a night.

time(NULL) returns the number of seconds since January 1, 1970, and as a result is highly unlikely to produce seeds that produce similar results every 86400 seconds (and if it did, a difference of just one second would give completly different results).

It'd be much, much harder to make loot not random than to make it random.

I'm fairly sure it'll be something like

srand(time(null))
when the server is started, to set the seed.

Then whenever a boss dies, as soon as it dies, it will call
rand(some number)
to determine loot.

Because it seeds once at the server start you cannot determine the seed - and all the random numbers generated for all the player/mob events use the same RNG so you cannot reverse engineer the pseudorandom number without knowing every single event on the server.

Why would they do it this way? Because any other way would be more work, honestly - and this approach provides good random behavior for the server. Why allocate memory to generate the random seed at the beginning of the instance when you can simply do it when the random number is required and save the bookkeeping and memory. All this talk of 'seeding' an instance and whatnot is almost certainly superstition.

And, of course, it's unlucky to be superstitious.

Seems the horse is not quite dead yet. Tin-foil hats ON!@

My guess is, server startup. And that's it, there is no conceivable reason to muck with it after that. Here's a sample PRNG. Richie, perhaps you could explain to me why a PRNG with a non-repeatable sequence of 2^19937-1 (which is a very, very, very, very big number) would be reseeded with non-random data every time a guild steps into MC after reset.

You know those times when you skip a raid, for whatever reason...then after the raid you browse the dkp site for drops...and of course the item(s) that you really wanted did drop that night. And some guy probably got it for cheap.

So...can you argue that the loot would have been exactly the same if you had been there that night? Or would you say that the random roll of loot or whatever you want to call it is affected by modifiers in such way that the loot had been more or less different? That if you had run though the instance with them, you had killed Nefarian 2 minutes earlier and all that, would the random still have been exactly the same?

Based on my reasoning to these replies here and in other similar threads, I would be inclined to assume that yes, it would have been exactly the same loot if I had been there. I'd hope that wasn't the case though...

Upon instance load. Due to the way GMs track and manipulate lost/mishandled/unlootable items it can only be done by having loot data consigned to the specific ID of that zone and not your actual lockout timer. GMs can see in advance the drop tables of any boss when your particular shard of BWL/AQ is created, and should they need to reset your timer for whatever reason the loot is rerolled. There have been comments made verifying this in the CS forum that I'm too lazy to brave the search function to unearth.

This would be a horribly inefficient method; the most sense is to make the rolls when the enemy dies. It doesn't make any sense to pre-compute loot, because now you're storing all this data that may end up not even being used.


As for when the seed is set, it is almost definitely when the server starts up, it takes the initial seed from there, and never resseds so long as the server is up.

There is absolutely no way to reasonably figure out what is going to drop, because their PRNG will be spitting out hundreds if not thousands of numbers every second. While it is true that if you start at a seed, every roll after that will be in a sequence, given that the seed will vary and that there is no controlled way to predict the sequence, there's absolutely nothing you can do.

Lost and unlootable items are handled by the simple expedient of examining the audit trail created by the item database. Every item that is created is logged - for a game as big as this one, such and audit trail is almost mandatory. This is the reason the GMs want the approximate time of the kill when you claim a despawned or unlootable boss - the audit trails must be massive and the kill-time narrows down the search.

This is a vastly simpler approach than generating the entire instance item drop set up front when someone enters the instance. In fact, I cannot see any advantage to pregenerating all the loot - so I have no idea why they would spend the server resources to do this and keep track of it all.

As to the faction specific loot tables, when an item drops, you simply examine the faction of the player who tagged the mob and index the appropriate loot table.
Which explains the silly bug where lucifron was tagged by the drillborer disk damage shield, which doesn't have a faction, and then the GM saying that the log file showed Luci dropped no items, just gold. If the loot was generated up front, there would be no way for the disk to affect the loot table.

I'm not sure people realize quite how staggeringly complicated it would be to itemize and store every mob in every instance ever created, instead of simply running a couple of rand() calls and a faction if() check on every kill. Considering that it provides absolutely no advantage over the late-generation at kill time, I find it very hard to believe bliz would go to all the trouble to do it - it's months of dev time - not the kind of thing you'd do by accident.