Ah, but see, what I'm more interested in is 2 separate RFC instances, logging them both. You go in one, and log everything, and he, at the same time and while not in your group, also zones in and logs everything. Then, you check for collisions.

[N]Language is confusing. Instance (capital I) = RFC, BRD, BT, etc while instance (lowercase) = your (or your groups') Instance.

See, if it's tied to your player, you'll have plenty of collisions. If it's tied to the instance's process*, there should be collisions every time you reset all instances, regardless of which Instance you zone into. If it's tied to the player, it should be the same as the preceding example.

My reasoning is, each time you create a fresh instance (by reset), you're spawning a new process when you enter it. This new process could care less about any of the other processes on the server, and starts from scratch, with a counter of 1. However, to preserve some memory on what's spawned and what isn't, each Instance (see below) that you enter between resets is actually part of the same process, if it's tied to your player/group in some way. You own that process, you could say, until you reset it, in which case you get a new process.

Example: You enter RFC, and spawn all the NPCs. By the time you leave, you have incremented the counter to 0x300. You hoof it over to BRD, and proceed to wipe out the entire instance. However, the counter remains started at 0x300 for BRD, because you haven't reset your instances yet. You get reassigned the same process to handle BRD this time. By the time you're done in BRD, however, the counter is now in the realm of 0x1500. So, you zone out, and reset the instance. You zone back in, and this time, you get a new process, as the old one was wiped out (and consequently, your queue of reset times has one entry). This also reset RFC, so after you clear out BRD, you head back into there, without a reset. Again, you're reusing the same process, so your counter there starts from 0x1200.

Now, this obviously implied that the counter is tied to either your player, the process handling the Instances, or both. See, it appears that the two are tied, to both keep track of what you've cleared in what Instance, and to save on server resources. It is possible to pass off ownership of the instances you own, by creating a group and giving someone else lead, and then leaving it, but this is essential what using the instance reset option does. However, you're now orphaned in an instance that doesn't belong to you; to handle this, the server ports you out.

*By process, I'm assuming that every instance is it's own process. Not the Instance itself, but the particular one you're in. Here's where the language gets confusing: Basically, each instance of an Instance is a process of it's own. Understandable? =\

Torq, perhaps you could use "dungeon" instead of "Instance?" Also, I highly doubt that resetting instances would start your player's counter over at 0, because that would give you the same seed every time you zoned into an instance.

That would probably be better terminology, yes.

And, no, it wouldn't. There's absolutely no definitive proof that the "spawn counter" is in any way linked to the "seed" of the instance. In fact, they're probably completely unrelated. The spawn counter is merely a way of referencing mobs; it has nothing to do with loot generation or even mob generation (in the case of randomized packs).

Besides, we already have confirmation that the seed is a timestamp, at least in part. So even if it was something as simple as "timestamp^counter" you'd still have a different seed every time.

I did just that, me and a friend both ran RFC simultaneous and combatloged it, I then checked for collisions and didn't find any. Sadly I deleted the combatlogs for it, but I'll force him to make another run.

I'm very convinced that the spawn counter is in no way at all tied to the player in any way, nor does it reset during the week. The reason I got so low counters was that I was going into an instance just a few minutes after the server had started for the week, it's entierly possible I was in the first instance on my server for the week. I've seen no proof or even suggestions that the GUID would be assigned based on player interaction. I did RFC with my hunter after I did it with Tanoh, and the hunter's GUIDs were always higher than those Tanoh had. Which makes me convinced they are a straight incremental counter that's reset on maintenence.

How the GUIDs are assigned by the server is a cruical step, how this is done is well hard to know without looking at the code. If I were to guess (I'm working as a developer after all, albeit not at all with MMOPGs), I'd say there's a basic thread safe function/separate process/system for it. Basically they just iterate over all the mobs in the zone and go "I want a GUID for <this>.", and get one that's unique. It's actually possible to check if one complete instance is spawned or if the instances are spawned simultaneous. Which I'll also look into when I convince my friend to do another RFC run. Just enter at the same time and check the spawn counter of the first mobs. If they're spawned simultaneous they should be close, if they're spawned in sequential order then one of the instances should always have a lower spawn counter than the other.


But the most important thing: I see no reason at ALL why GUIDs should be tied to what loot they will drop. It would be a very stupid system. I'm sure there are hundreds of variables on the mobs that we can't see, it would make absolutely no sense at all to base the loot on one that we can see and hence sort of influence.

To be honest, the GUID generation is probably much simpler than we're giving them credit for. I.E. It's probably as simple as:

The GUID is more like a handle to the object, or a way of referencing an object. In Diablo II, we had something like this for retrieving objects:

I'm assuming a similar system is at work. In our case, it'd just be the whole monsterGUID that we see, or possibly just the npc identifier and the counter. Hell, I'm assuming since there seem to be no collisons between monster types within the same instance, it might just be the counter in and of itself. The reason we see the whole thing as (flags)(npcid)(??)(counter) or however it's structured is because that contains all the necessary information about a mob that the interface/lua needs.

I'm sure the actual handle (what's provided in a movement packet, for instance) could just be the counter, which may be the GUID in it's entirety. All appearances point to the entire list of units being deallocated when you zone out of an instance, and an entirely new one being built as you zone in. Obviously the server would provide you with the whole thing once, to populate that list, but from then on, it only needs the npc's id to tell your client to which unit any particular action refers.

And I completely agree that loot is in no way tied to the GUID, other than in determining which drop table to use. I.E. the npc identifier, that says this is a Ragefire Trogg. However, that's something that'd be completely carried out on the server itself; and considering we have no way of changing what an npc is, we can't influence it either, so it's entirely a moot point.

So please. Use some common sense, and stop trying to link GUIDs and loot. They're unrelated, they never have been, and never will. You're exploring down a dead-end path.

I appreciate that I'm probably going to get attacked for posting this anecdotal information, but I figured it may be of some use to some of you guys working on this.

During massive server issues on Sunday night on Frostmourne (multiple world server down/instance server down/server restart) there were 4 guilds inside Black Temple actively raiding. Three of these continued on after the server sorted itself, and the 2 Horde guilds both got a Mainhand Warglaive off Illidan whilst the Alliance guild hand an offhand drop.

Fast foward tonight and the 4th guild, being mine, kill Illidan and in the process get an offhand Warglaive thus making me a very happy rogue but also left me trying to figure out the incredibly low chances of having 4 Warglaives drop in one reset with the seeming coincidence of them going to the 4 guilds that were doing BT when the massive server disruption occured.

Perhaps its just a massive coincidence and a case of random numbers being random, just seemed strange to me.

We did a TK PUG/alt/guild fun run the other day on an off-day just cause and after we killed Al'ar I said to the raid leader, "You did remember to program the instance for the Seventh Ring of Tirsfalen" (which our paladin tank desperately had been wanting and had been going on about since we haven't run TK in many months). Two pulls later, he had one. Roquefire, it's not worth attacking you, but it's worth reminding you yet again, people see patterns when interesting things happen. They call these "coincidences" or they say "it can't be coincidence".

When nothing interesting happens, they don't say anything. The world has trillions of independent events every day. Most of them pass without notice. It's not really exceptional when a number of things converge at once and make for an interesting pattern. If 10 servers crashed during BT and 20 guilds were running it and 14 of them got Warglaives, well, now we might be onto something. Your anecdote is a good anecdotes, and congrats to all the looot winners, but, no, it isn't of use to the people working on this. I wish it were, but it isn't.

I don't know if anyone else can relate in this regard, as I'm not sure if it was just a Blackrock server problem, or a universal issue.

Back in Vanilla days, from MC through to Naxx, alot of guilds would experience severe lag in heavily populated raid zones. With the majority of raiding guilds on Blackrock operating within the same timezone, there would often be times where a dozen or so raids would be clearing the zone simultaneously. This resulted in alot of downtime. In our case, it became an acceptance that we simply wouldn't bother with Thaddius until after ~10:00PM, as several other guilds had left the zone by then. We had always assumed the cause of this lag was due to the vast number of loot tables being generated upon every mob/boss death. Maybe it was just our shit server, or maybe it was another unknown cause.

One point of note is that it hasn't happened in The Burning Crusade. Could be the reduced raid sizes. Could be the implementation of more efficient code. Could be hardware upgrades. Could be that they changed from a "generate-on-death" loot table to a "generate-on-spawn" loot table. Could be alot of things.

There were a lot more lag in raids pre-TBC, at least from my perspectice and it seems like others agree. There's a whole lot of things going into causing server lag. As we know next to nothing about Blizzard's setup it's pure speculation, but generating loot is only a few random rolls. Compare that to whenever someone hits, gets hit, casts a spell, etc, at least one random roll has to be made in some cases two or more. All that has to happen in real time whereas the loot generation (if it's indeed done at spawn time) would happen while you're at the loading screen.


Back to the topic at hand, I've been busy with other things and not had time to do more testing with GUIDs. I'll try to get some time for it in the next few days.

Our first kill was with wipe to parasites during or close to victory speach. A shamie did ank and apears alone in front of ilidan in the kill SC. This was on a tue and he did not spawn back and needless to say I was pissed at GM for "investigating" insated of deciding to give loot or spawning him back so we can kick his ass for good.
Anyway in few days we did get loot from the GMs and did not get any glaive. That was 15 kills ago and we still have to see one drop for us.
So no pitty from the GMs for "close" kills. I would assume they just see the loot the mob had on him and give it

Well, looking at all the major news sites (world of raids and mmo-champion) it appears that Kil'jaeden's loot table is not linked to killing him, at least. Look like his entire loot table went live at the same time he did.

Also, on the subject of random loot being random; my guild's first two kills now have included MH warglaives. We plan on killing him for a third time to tonight, so we'll see if the streak still holds.

I suppose this is a possibility, which would point to loot being determined (and possibly rerolled) every time he is respawned.

[E] So I guess, to make your hunters happy, you better kill him the first time you can link the bow :P

You are assuming a lot. The loot can be easily made random or not. Since the tools are in hand of Blizzard you are in fact assuming that they made the loot random, which can be true ... or not.

Since the numbers and data from boss kills can't provide us with a suficient amount of information to extrapolate some valid theories, I will resort to something else.

We all had quests to gather x or y items. Often, I got myself borred to farm same mobs and log off with the quest unfinished, only to return in another day and get quick few of the items needed in the first kills.

I belive this can be reproduced by more players and we can get a valid conclusion. Get a gathering quest, kill for a while, stop before finishing it and calculate the drop rate. Return 1 or 2 days later and count the drops from first 5 / 10 / 20 mobs.

This will prove that random is not actualy full random, and that Blizzard is influencing the loot in function of several factors which we are still to discover.

Memory and perception introduce sample bias. How many times have you logged off in annoyance and come back later and still had a shitty drop rate? The answer is: a statistically consistent amount, which appears less so in hindsight. Go ahead and try your tinfoil hat study. I'm glad you're willing to propose an experimental verification. Expect verification of random drops.

Things to control for: For each sample, make sure to run either the same number of mobs, or the same number of drops, preferably the same number of mobs because the same number of drops biases the drop rate towards lucky streaks. If your mobs have a level range try to either only kill one type, or at least track them independently.

This is at a slight tangent to the current discussion, but might spark some debate:

I've been playing about with data gathered by many different players on the daily fishing quests. Essentially, how many catches it took to gain the quest fish. This article - Random Catches - explores how the data is distributed, and gives some insight into just how much variability is in "random". Whether those patterns apply elsewhere is unknown, but I'd wager they do.

The distribution appears to tail off to infinity, and tails off fairly slowly. It's so annoyingly inequitable, I'm amazed they've got away with it for so long. It is also technically possible to never be able to finish the quest, which would be a broken game mechanic, if the odds of that happening weren't so infeasibly low.

You're dealing with time-to-first-success for independent events with a low success probability. That means you're dealing with an exponential distribution, and your curve fit should take the form . This distribution has non-zero probability for arbitrarily high time-to-first-catch, which should be obvious simply from the fact that the catch attempts have independent success chance. This is a property of loot distribution in general, not just fishing, and is not correctable without actually hard-coding in dependence on number of attempts.

At no point, obviously. Assuming you knew the chances going in, and the environment around you isn't changing (ie: WoTLK doesn't come out, making your goal pointless, or Sunwell doesn't open giving you other things to spend your time (assuming perhaps that you don't have enough time for both), etc..) then the choice about whether to kill Illidan again or not never changes: there's always the same chance of reward and the same cost (time) you have to pay for that chance.

Now at some point you might just say: well this is as much time as I am willing to put into this game, or this repetitive act is now too boring to contemplate, etc. But from a cost/reward perspective, nothing changes.

Of course if you take Sunwell out of the picture nothing changes. But if you add Sunwell back in things do assuredly change - there comes a point where you decide that you will get more out of another progression day than you will out of clearing BT for all those last remaining items that refuse to drop.

I assume that (and other decisions like that) is what he was referring to. Obviously, if you have nothing else to do with your time, it's worth killing Illidan. The question only becomes interesting when you have something else to do with that time.

Sorry, this has probably been posted somewhere in here, but asking again anyway:

We know that loot spawns when the mob is created. But what happens on Illidan when you wipe? Illidan despawns then respawns at his normal location again. Does this mean that his loot table also resets?

Since 2.4 we get the mob's GUID and it changes between wipes. So the Illidan mob is a fresh one with assumedly fresh loot table.

This obeservation is covered in this thread.

Changing the GUID doesn't mean we'll get new loot though. It might, but we won't know until Blizzard tells us how they're doing in detail. And I doubt that will ever happen.

The loot for all bosses, regardless if they respawn or not, could be decided upon instance creation and stored on the server tied with an instance ID or raid ID.

There's just way too many possibilities and no way to test them.

I found this pretty interesting and it got me thinking about Blizzard's choices in drop rates. Obviously, the drop rates are pretty well known just through how many times we've actually killed all the bosses (and armory now gives a rough guess). I'd be curious to know what exactly goes into the chance of x dropping vs value of x. Are the warglaives, with such a low drop rate, really worth it? I'd almost say it's raw item value: the chance of an item dropping versus how good the item is.

Basically, I'm curious to know if Blizzard even considers itemlvl vs chance of dropping. The Warglaives are fantastic weapons, but are they so fantastic that you clear all of BT just in the hope that they might drop?