I have bad news for all the people trying to use loot links to see what a boss drops - the presence of an item on the server or battlegroup is not the only thing that determines whether or not you can link it. Long time players may remember that at release, green +damage wands were better than epics for most casters. The drops got nerfed long before TBC, but they left existing wands as they were. I have a warlock alt that is still wearing one of the old school +damage wands, and when I try to link it only white text comes up. Attempting to link it repeatedly gets me booted.

Those wands were never better, the wording was just different. People thought that because it didnt say "up to" it was better which was not the case. It did used to be the case in beta, but they changed it long before launch.

Shadow wrath wands (and similar) were still better than pre-AQ40 raid drop wands simply because the raid drop wands lacked damage. [Dragon's Touch]

You misunderstood why they were better. It's not that they worked differently, they were just hilariously overbudget. At level 58, I got a wand on my priest that had +31 healing on it. The best wand in the game pre-TBC was [Wand of the Whispering Dead], which still didn't have as much healing (although the stats made it a bit of an upgrade).

With patch out this theory is almost 100% confirmed. Within a couple of minutes of servers coming up, someone on server zoned into Sunwell. I was on a lvl 1 since it wasn't Korgath, and was able to link 2 pieces of loot off brutallus, kalec and the twins.

You mean you were only able to link two pieces? Did you try reseting your raid ID and seeing if you could link more?

Just going to try and eliminate the obvious option, were these pieces of loot that you can exchange for a different piece of loot using Sunmotes?

Ah, I just assumed people were talking about text wording as that's what 90% of questions about those wands pre-tbc were about. I didnt play a caster at all pre-tbc so I totally forgot about the wand situation.

EDIT: Wand wielding caster, gogo pally.

You can link anything that's also shared with the trade in off of the boat at the Harbor.

We've been doing multiple attempts on Kalegocs now

[Dragonscale-Encrusted Longblade]
[Fang of Kalecgos]
[Band of Lucent Beams]

Have not shown up yet. These are the items you should be "fishing" for.

Granted, random loot is random, so there's a chance that they haven't shown up on Kalecgos' table in our wipes yet. OR it might be possible his loots not changing.

Are you resetting the instance after every link attempt? If the theory is correct and you don't despawn him, his loot will never change.

He disappears after every attempt, like Illidan does when you fight.

The theory went that Warglaives appeared during Nihilum's attempts because he was despawning each attempt and such.

Surely We're not the only ones working on Kalecgos at the moment, can anybody else weigh in? >_>

Edit: We killed him, got Legguards, maybe the instance does have to reset and it's not just the despawning of the boss that does it?

Ya they were not the turn-in items or rewards, were actual drops.

Just to clarify, are we generally assuming that this loot generation is tied to that night's instance only? I ask this because our guild recently bought a Council + Illidan clear for some HoD from another on our server, and we ended up getting a MH Warglaive drop. I believe they had just killed Mother, and the instance had yet to soft reset, so I would assume that we still had their loot table. The comment had been made in guild chat that if they had stuck it out and tried to kill him that week, the glaive would've been theirs, but I'm not sure that this is the case, since they probably would have been doing it the next day after a soft reset. Any thoughts on that scenario?

On a side note, our guild managed to be very shortsighted, and we didn't have a single rogue/warrior in the raid who needed the MH, so it ended up going for a free-for-all bid, resulting in this: http://i31.tinypic.com/103eueo.jpg. I think if we had thought it through better, we could've at least /rolled for an alt to come in or something.

I skipped a couple pages in the middle, Ive been able to link warglaives on my realm for a while now and no one on it has come close to killing Illidan... so I assume some information gets shared across realms from battlegroup/arena players? Wouldnt that somewhat taint these tests

All this talk about "seeding instances" or "seeding a mob" is fundamentally misunderstanding what a seed is. When the server comes up, it's RNG gets seeded exactly once, most likely with the number of milliseconds that have passed since midnight on 1/1/70. It is never seeded again -- there's no need to, because once it's seeded you have an endless stream of random numbers to work with.

Assuming the other information in the thread about servers only having a single RNG is true, then every bit of non-determinism affects every other bit of non-determinism. Not only is what loot you get affected by what other mobs loot is, but it's affected by every crit/non-crit decision, every time a random damage value for a weapon hit is picked, etc, for every person on the server, as well as how many of these things have happened since server startup.

With a good RNG, there's simply no way to predict the next number except knowing the original server-startup seed and knowing the exact quantity of random number requests that have happened since server startup when the mob in question is spawned. And there's absolutely no way anyone can know that.

So, please, everyone stop talking about "seeding" happening at any time other than server startup. That's not how it works.

"The comment had been made in guild chat that if they had stuck it out and tried to kill him that week, the glaive would've been theirs, but I'm not sure that this is the case, since they probably would have been doing it the next day after a soft reset. Any thoughts on that scenario?"

It would've all but certainly been theirs. The loot Illidan has is almost certainly determined when you spawn Black Temple. Once you are using a Raid ID of a spawned instance, it's the same loot that would've been there no matter who killed Illidan, no matter whether there was a soft reset. At least that's the best understood version of how it works. There is some notion that the "thereness" of Illidan is somehow relevant to his loot table, but that's surely not the issue.

I suppose there exists some question as to whether bosses spawn their loot rolls upon the kill or not. In that case, no, it wouldn't have matter if they killed Illidan; it only matters that you do at the time you did. But it doesn't actually seem to be the case it works that way. That said, you still can't "find warglaives."

There's no reason to assume that there's only one PRNG involved. Nothing about WoW from what we can observe suggests that they've set up a centralized PRNG for each server cluster which each machine makes requests to. It'd also be a somewhat stupid design that'd be terrible for performance with no advantages other than the ability to switch to a real RNG sometime in the future.

Well, that's why I said "Assuming the other information in the thread about servers only having a single RNG is true" (I remember seeing something about that in this thread but I can't seem to find it now). They wouldn't necessarily have a single PRNG for each server cluster, and I didn't say that they did (why increase internal network traffic for random numbers?) -- I said they'd most likely have a single PRNG for each server. The salient point is that it's unlikely that they're using separate PRNGs for loot determination and hit/miss rolls and mob spawning and everything else, so everything is likely affecting everything else, and the PRNG is likely being hit thousands of times a second, if not more.

A blue poster said long ago that each process has its own PRNG, see here: WoW BlueTracker: Roll Hacks

I assume an instance is either its own process or at least a different process than the outside world.

It's not that hard to think of a scenario where loot generation would be from a "clean" RNG. One is the following situation:
1) Each process creates its own RNG
2) Each instance is a seperate process
3) Mob creation/loot generation order is deterministic

None of these seem impossible to me. There's no reason to share a RNG between processes. IBAA isn't reentrant so each worker thread may even create its own RNG (although I can't imagine random number generation consumes enough time that its nessesary). If they aren't shared, it's entirely possible that there is no random noise from combat/etc. There's so many different ways that it could be implemented that we can't safely assume anything at all about the implementation.

What we know:

1) Loot is determined at mob spawn.
2) WoW uses a PRNG, IBAA to be specific, as of last information.
3) The PRNG is seeded with a timestamp.
4) Each server process has it's own PRNG.

Now, from here on out, it's speculation.

This we've been told, and have to accept as truth. However, we do not know if loot is created on mob spawn, nor do we know that respawning a boss mob actually creates a new mob, or merely reinitializes the existing one. Just because the GUID you see on your client changes doesn't mean the underlying structure on the server is a new one.

For instance, when a creature is spawned, it's "loot list" could be populated with item IDs that are randomly pulled from it's loot table. Given that these are only the item's ID, the item itself has not been generated, and therefore does not appear in the server's cache. This would save on resources, as an item ID is only a single 32-bit integer. Do not confuse this with an item's GUID, which from what I know is a combination of the item's ID and attributes.

Lemme pause here to elaborate on this from some stuff I learned back when I used to play with a previous Blizzard game, Diablo II. Blizzard was nice enough to provide us with a copy of a large portion of their server code, including that for item generation and for the storage of item structures. The item as you see it on the client was referenced by a GUID, that referred to that particular item. People assumed this was an item's global identifier, but it was not. Future patches and the release of the dupe-removal system implied that items actually contain a separate, unique identifier (we'll call it a UID) that determined an item no matter where it went (though the code for this was not included in the local server code). Because the duplication methods in place usually involved the same item being "copied" from place to place (as in buying it from a vendor multiple times), each copy of the item retained this UID no matter where it went.

So, back to WoW items and the GUID that you see. This is most likely NOT the UID of the item. This would be generated on upon the actual creation of the item itself, and stored only on the server, where you can't see it. If they learned anything from D2, they would know that this is invaluable in detecting duplicate items that result from certain strains of duplication methods.

My theory on this is that for every item created, it follows a 3-step process. First, the item ID is determined when the mob spawns. Second, when the mob is killed, this ID is retrieved and looked up in the server's item cache. If the item exists in the cache, it spawns a copy of that item with a new UID, and this is the loot you receive. If the item does not exist, it pulls it from it's database, inserts it into the server's cache, and then spawns a copy of the item as loot. With this model, you could think of the item cache as being a server's "template" for an item, and each particular item being an "instance" of the item. The item "master" would be the database from which the server pulls the template for the first time.

Unfortunately, I can't prove this is how item creation works. It's just a working theory based on what I've seen. Disproving this would be (relatively) easy. If you isolate an item that does not exist in the server's cache, and then cause it to appear in the server's cache by resetting an instance repeatedly, then you have proved that the item is actually pushed to the cache on mob spawn.

You could possibly prove this theory by getting lucky with loot drops: Determining that an item does not exist in the server's cache, and then receiving that item upon that particular kill of the boss. You would have to ensure that this item still was unlinkable prior to every boss attempt, in the case that the mob's loot table is actually regenerated upon respawn.

A third test could be used to determine if resetting a boss does indeed refresh it's loot cache, but it would be dependant upon disproving the 3-step method of item creation. If you can indeed link loot after repeatedly resetting an instance, the next step would be to reset the boss without resetting the instance in an attempt to determine if different loot is now linkable.

Not much to say on this point, it's relatively self-explanatory.

Again, mostly self-explanatory, but this timestamp could be epoch time, system tick count, some combination or variation of the two, or something else completely.

The exact quote from the blue post was "Each server process has it's own unique random number generator..." Unfortunately, This could mean a few things, as well. For one thing, we don't know if an instance is a single process with multiple threads, or multiple processes AND multiple threads. This could imply that at any given moment in a raid, you could either have one or many PRNGs affecting the outcome of your actions.

Edit: We also do not know if a soft-reset of an instance creates a new process or not. I would assume that any instance with no players inside would be suspended for a while, and then it's state archive and the process terminated after a half-hour (hence soft-reset time of a half-hour). If the process it terminated after a certain length of time, when the instance is reopened (entered by a player), the server would have to create a new process for this instance, and load the state from it's cache to repopulate the instance. If it indeed does create a new process to do this, the assumption would be that a fresh RNG is created.

How much information is cached is applicable to the first point: Perhaps only the state of bosses is saved, meaning that a soft-reset could actually create an entirely new loot table for every remaining boss/creature in the instance. Signs may actually point to this: Take an instance that crashes just after a player loots a mob. The player knows the loot that was on that mob, but when he loads back in, the instance has soft-reset (or even just partially rolled back). Upon killing that mob again, the mob drops something else. There could be special cases for bosses, but this could also be verified on a bosskill/reset before loot distribution, followed by a rekill of the boss with a different loot set.

Just my thoughts. I really enjoy the math things, and considering I used to play with this sort of thing back in my D2 days, it brings back good memories

A few posts behind but I found this SS laying around that is quite interesting:

http://en-raptured.com/pics/new/25/aran.gif

Picture is grainy, but it gets the job done.



As far as the direction in which the bulk of this thread is concerned, until patch 2.4 GUIDs were always present yet hidden from view as far as the fundamental structuring of WoW is concerned, or at least I would imagine they certainly have. I really can't see Blizzard changing the structuring of how NPCs are spawned and allocated in patch 2.4 and I think it is fairly safe to assume that WoW NPCs have always been spawned and organized in this manner, the same is true for non-visible raid IDs (pre-1.8 or 1.9).

The reasoning behind the 'revealing' of identifiable Unit IDs is probably strictly for the user end for meter addons, so the default UI could find units for the new combat log (seeing as the default UI is effectively an addon), or some other mythical dragon-slaying related reason we may not really see until future patches.

That being said, a correlation between the GUID and the loot table is probably all horse-hockey. Barring an extremely large conclusive sample (running WC 5000 times, for example) I would be fairly certain that the information server-side relevant to loot is simply not available to the user. Even if conclusive data were discovered linking the two, that information would only be useful for the instance/encounter in which it is gathered until a related algorithm is discovered.


I really hate getting on the random loot is random bandwagon, but in regards to GUID-loot relationships or even probing the server for relevant loot data, I think the theory is way off-base. All bosses which have a despawning mechanism would easily subvert the pre-determination of loot, all bosses who's loot tables become available mid-attempt probably won't be reset on a hunch, and any variable in loot which can be skewed (be it the items already existing on server or the appearance of one mid-attempt) will result in inconclusive information.