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.

People are born with excellent seeds, and some are burdened with terrible, terrible seeds. Gurgthock is one of the latter. Ask about our venomous totems!

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.

A lot of people with a bit of out-of-context computer science knowledge harp on the fact that defeating the RNG should be "possible," which is true. It is probably not, however, a tractable problem, or one that's going to be solved by some random experimentation.

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.

Since we know something happens to handle faction specific drops, we know at least some part of the loot generation occurs at instance creation or loot time.

There are several mob types that display weapons equipped if they're going to drop them (ex: gray weapons overriding the default weapon model on some casters in BS). This rules out the complete loot table being generated at loot time.

To me, this suggests that at least some of the loot table is generated on mob spawn (instance creation).

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.

Badge of the Swarmguard, why do you mock me so? :(

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.

There is (was) thread on SA - http://forums.somethingawful.com/sho...0&pagenumber=1

Former GM answers the question, and mentions than with GM interface he can see what items a mob will drop.

Which is exactly what I was wondering about, hence this thread. If we observed enough instance-creation times, and compared them to the loot that drops, eventually (maybe) one would be able to determine loot by waiting to enter an instance. It wouldn't have to be reseeded, just executed. Or maybe it would need to be reseeded...

The way I understand RNG stuff is kind of like this:

User requests random number
RNG takes time of request, plugs that into the formula as the seed
RNG does its thing on the seed
RNG gives semi-random number

Or

RNG gets an initial seed of something, usually based off of time
RNG starts doing its thing based off that seed
RNG starts something like that wheel on The Price is Right
User requests a random number
RNG puts its finger on the wheel
RNG spits out number

Personally, I have no idea which model is used on blizzard's end, but that's why I'd like to test stuff!

That SA thread is pretty good, gives a good starting point for a bunch of ideas. Now if I can only find a GM willing to send me a copy of his client I'll be all set. :D

For some reason, only recently I can't view GBS anymore and can only look at CGM :<

Like Drauk said, a former GM said that GM's can see what loot will drop. Thus the loot is not determined when the boss dies.

There is no such thing as a seed or you would be able to control what loot you got. I am sure that all bosses loot is determined at random when the new instance ID is created. Please shit heap this conspiracy shit.

Regardless of when the loot is generated, you cannot predict the loot that will drop unless you know the following details:

- The type of PRNG used (there are many, and some are "better" than others in terms of randomness.)
- The value(s) used to seed the PRNG.
- Whether it's a server-wide PRNG, instance-wide PRNG, or something else. (One could easily have a PRNG class that you instantiate and seed for every instance creation and such like.)
- The method by which the number stream in the PRNG is mapped to an item. (The precise values of the loot tables, the mechanics of the loot table system.)

Given that the information for details #1, #3 and #4 are something Blizzard will never tell you, and that #2 is almost impossible to determine, you cannot hope to reverse engineer this. The client is not provided sufficient information to reverse engineer these sorts things.

The best we can hope determine is whether the PRNG in question is truly random or biased. This can be done by examining the drop frequencies of items with a (supposedly) known drop frequency. For example, we know that any given tier 2 chestpiece has a 2 in 8 (or 1 in 4) chance of dropping off Nefarian. If we go to a site like allakhazam and look at the statistics we should see some sort of distribution around 12.5% for each robe.

And sure enough, with a few %age points of variance, we see that. Now, I'm not going to break out the stats text and datamine allakhazam to determine how significant that variance is and what the implication is for the true randomness of the PRNG. (The existence of a skew is expected, regardless.)

I suppose, someone who was really determined, and had really good information from a single sever (including timing data of when the drops occurred) coming from a large number of guilds across a large number of attempts might be able to reverse engineer the PRNG if they had a remarkably strong grasp on statistics. But you're essentially getting into code-breaking level of difficulty here, and the data source required for this just doesn't exist.

A seed is what you feed an RNG to make it random. if you don't seed your RNG... its not going to be random.

There are no "static" seeds, aka: player A has a seed of 1234809 forever..... its more likely another random number, or the time in seconds created at some point during server startup that changes during weekly maintenance.

there is no way to predict what loot you get, but there is only a finite amount of loot for you to get... some loot will drop often, some not at all, as the RNG is a fickle master.

Considering that its probably down to milliseconds either way, I don't think that's possible.

We are talking symantecs. I realized that there has to be a seed but I was talking static seeds.