◊ Shalas

Despite the name, this is not true. While the GUID generation algorithm does a very good job of avoiding collisions, there are still only 4294967296 possible GUIDs, nearly all of which can never be generated by a specific computer.

 

Belakor

It seems as if I'm misinformed anyways, as I was under the impression from this thread that the GUID was something assigned to a mob, a generated "tag" if you will with it's assigned loot. As to killing a boss twice in one week, you're not supposed to be able to kill anything faster than it's instance's reset timer; other than that that's either a bug or an exploit. As for the Ashes of Al'ar...those are EXTREMELY rare, much rarer than the Glaives, I would chance to say. I never said that getting 3 Glaives in 4 Kills (3 in the first 4 out of 6 overall kills) is impossible, it seemed that there was a serverwide rumor coming from informed sources that people in said guild were zoning into BT early in the morning to "claim" the instance ID. In regards to trash...a boss in an instance and a trash mob are something completely different. Trash mobs can respawn outside of the instance reset timer, where as a boss *should* not be able to.

On the other hand...would it not make more sense for a mob to just be "assigned" loot as it spawns, when it despawns, it's erased, and then when it respawns, gets another "assignation", and when the boss mob is killed, it just pulls that loot from the server, and puts it on the corpse?

 

Narugh

Actually there are 2^128 possible GUIDs in the common implementations. Which is quite a lot more..

[EDIT] Just as an example to show how big that number is (UUID is more or less the same as GUID): "This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs."

 

◊ Shalas

Err, right, 32 characters, not bits. However, there still aren't 2^128 possible GUIDs. With the GUID format used for COM, 11 bits are constant, and 4+ bytes are often used to store data about what the GUID is used for. You also don't need to generate every GUID to get an overlap -- with 93 random bits, you'd only need to generate 140 trillion GUIDs for a 50% chance of a duplicate. There will probably never be a duplicate COM GUID generated, but it's not impossible.

In WoW's case, the GUIDs are only 64 bits, with at least 12 of them reserved. NPCs are identified by thier mob id, some flags, and a 24 bit spawn counter. I have no idea how to go about guessing how frequently mobs get spawned, but 16,777,216 is low enough that I'd be surprised if it didn't roll over at least occasionally, and I don't think it's that horrifically unlikely that at some point a duplicate GUID has been generated (i.e. somewhere above a 1.0e10^-3% chance).

Of course, the chance of a mob you actually care about having the same GUID multiple times is essentially zero, making this all pretty pointless.

 

• Intermission

edit: I wasn't reading the last page, my bad.

 

Tanoh

To be honest it doesn't matter if the spawn counter rolls over, which it should do 16 milion is not a whole lot of mobs. The GUID for NPCs contains the NPC number, so in order to create a collision there has to be two of the same mob type in the same place when a rollover occurs. Even if "mob 1" and "mob 2" will have the same spawn counter, their GUIDs will still not be the same.

It could be entierly feasible that Blizzard realises this very tiny vulnerability and made a check for it, the WoW server has to keep track of all mobs that are alive (and corpses of the dead) either way, it would be easy to just check and make sure you never assign a GUID to a new spawn if there already exist one.

 

◊ Cadfael

The way I read Slouken's posting regarding the mob GUID, the counter-part is a monotonic increased integer and resets when the server restarts.

I don't think there's a chance for a collision. The system is probably in place forever (how else did the client always distinguish several same name mobs ?) and the info just now made available to us since 2.4.

EDIT: Napkin math: If the counter is 2^24 and we have a spawn each second then there won't be a rollover unless the server runs more than a half year without reset: 16777216 / 60 (seconds) / 60 (minutes) / 24 (hours) / 30 (days) = 6.47 months.

 

◊ Shalas

One mob per second is probably a massive underestimate -- I doubt there's ever under 50 people actively leveling on any non-dead servers, which would be enough for a mob a second while ignoring the other several thousand people online. If spawn counters are per-battlegroup the time required would be under a month, but if there's even the slightest danger of a rollover I'm sure the code can handle it by now (although it'd be pretty funny if that was why no-downtime maintenence didn't work).

I don't see any vulnerability, small or otherwise. There's absolutely no potential benefit from linking loot to mob guid, and I highly doubt that Blizzard would go out of thier way to make the loot generation system both more complicated and less random. It might theoretically be possible to force a mob to have the same GUID multiple weeks in a row (if two weeks in a row you're the first person online and are standing exactly on A'dal, he might get the same spawn counter), but then what? You dance around with glee at how you beat the system? The only possible bug I can think of related to duplicate GUIDs and loot is that mob GUIDs are probably used to track raid loot drops. As a result, if another guild on your server killed Illidan and got a Warglaive one week, if you could create another Illidan with the same GUID that week and killed him, the original loot results might get used (or it might just associate the results with your raid, meaning you could get a GM to transfer the Warglaive to one of your players). Barring some way to generate mobs very, very quickly at a controlled rate to force and overflow, actually doing this would be impossible, though.

 

Tanoh

Yes, it is a straight sequential counter, and yes it probably has been around forever just hidden from us until 2.4.

One spawn per second is counting it very low imo, all mobs in the world will get one, even in instances(*). There's an awful lot of mobs in the world, and players, and even other NPCs goes around like maniacs killing them which will cause them to respawn with a new GUID and an increased spawn counter. It's still quite a lot of spawns per second to fill it in a week though, 16777216 / 60 / 60 / 24 / 7 =~ 27.740105.

There are, unless I screwed up the count, 63 "normal" zones in the world (ie, not battlegrounds, not arenas, not raid, and not an instances). Say there's an average of 250 mobs in these zones. I have no idea about this number, certainly some zones are huge while others are relativly small and not many mobs in them. It's just a nice round figure, and let's also say that these 250 mobs are killed on average once every 10 minutes, again in some zones there's a lot more killing going on than in others. That gives us (unless I screwed up my 1st grade maths):

63 * 250 * 6 * 24 * 7 = 15876000

Which is quite close to the 16.7 milion max. I think it's not unthinkable that the number will be reached by a big server with a lot of people running around leveling, grinding and otherwise just killing stuff. In which case it has to be able to roll over.

Though in closing, I have to say that this diversion into GUIDs has nothing to do with the topic at hand. I'd be very surprised if there was a way to tie the GUID to what the mob would spawn, it would mean that the seed would somehow be the GUID. Which is just an awful way to do it, and something I'm certain that Blizzard's developers didn't chose.. Nor do I actually believe the topic to start with, but that's another issue.



(*): I have no idea how instances are handled, if the GUIDs are assigned by the "instance server" or the "main server". And also, in that same line of thought if the continents are handled different and there can potentially be two mobs with the same spawn counter, but one being in Outlands and one in Kalimdor.

 

duvar

I think we need to get back to the original question that this is being discussed for. The question was if a mob's loot table was somehow derived via a deterministic algorithm from it's mob guid. Using this you could, for example, figure out the guid of a mob that had good loot, then keep attempting to generate a mob with the same guid until you got the same guid again. In light of all this info about server resetting, guid composition, etc there are obviously a couple of problems with this:

1) Once you found a good loot dropper, 16,777,216 of the mob would have to be spawned before the good loot dropper would spawn again.

2) If this were the way it worked, there would be no such thing as drops like Ashes of Al'ar. This has about a .1% drop rate, from a mob which can only be killed once a week max by any given guild, and where literally multiple server resets can go by on any given server before it drops, if it ever drops.

To clarify point 2, if the counter is sequential, then after a server reset you could always be guaranteed that if you killed the N'th Kael, you would get a mount. This number couldn't possibly be high at all, because if it was too high nobody would ever have gotten a mount. Look how often server resets happen, and how infrequently he's killed. Yet still from time to time various servers see drops.

Lastly, this whole method is too complicated. Occam's Razor is usually right. Why oh why make such a complicated system where they go through all these hoops to generate this guid, then go through a bunch more hoops to use this guid to generate a loot table? Why not just, oh i don't know, roll a dice to generate it? I've played a lot of MMOs in my time, and in every single one, people have all these visions of complicated loot systems involving times of day and directions that characters are facing, alignment of stars (literally), blah blah. It's a dice. They roll it when the mob spawns. That determines the loot table. If you want to discuss whether or not despawning and respawning of a mob (e.g. on a boss wipe) changes the loot table, be my guest. But you have to ask yourself why you even care, because that goes absolutely nowhere towards helping you figure out how to influence the drops and if anything is a minor implementation detail that is only interesting for the sake of knowing random trivia.

 

Prinsesa

On the subject of random loot being random:

I used to be a very active poster on the official Defense of the Ancients (DOTA) forums.

One of the more "controversial" abilities on that game was an ability called Multicast. It was a passive ability that gave the Ogre Mage hero a 15% chance to cast his Firebolt spell 4 times in quick succession. If you bought an item called the Staff of Aghanim, the ability would be "upgraded" to a 20% chance to cast his Firebolt spell 5 times.

When I say controversial, I mean discussions involving it were pretty much like loot discussions over here (or the infamous Onyxia Deep Breath). Every time a new version of the game was released, someone would always say "Ogre Magi seems to be Multicasting a lot more, was he buffed?" and someone would always respond with "random is random, you just got unlucky".

This went back and forth for quite some time until someone actually set aside a couple of hours of their time to cast Firebolt several hundred times, log the results on Microsoft Excel and come back to the community with: "Hey, I'm getting more like 30% Multicast rates, what gives?"

With this impetus of data, other people started their own independent testing, and soon we had a couple dozen people all casting away, eventually coming up with tens of thousands of casts, which was statistically significant enough to rule out dumb luck.

As it turns out, there WAS in fact a bug with Multicast: Because of how it was programmed, having the Staff of Aghanim gave you two chances at a proc - once for the 15%, 4 cast version and another for the 20%, 5 cast version.

What's the point of my story? The community would never have been none the wiser if nobody actually went out and tested the spell. If you're going to say "Illidan seems to drop his Glaives a lot more", try to at least approach the question with a little preliminary data.

Ask other guilds how many Glaives they've seen from x kills starting from a given date. PM other on this forum, get numbers from them. If you come up with figures that do not jive with previously established statistics, THEN go ahead and ask the question. It just doesn't do to say "I think it was buffed, from other guilds and different servers" without specifying how many more Glaives from how many guilds and how many other servers.

I apologize if this is off-track, but I just felt the need to chime in. I used to be That Guy (tm) who would respond with "random loot is random" at the drop of a hat, but seeing the rule disproved in front of my very eyes has since taught me to look at it both ways: Never be too dismissive, but have a basis before challenging established knowledge.

"We do want Sanctuary to be the tanking seal"

- Ghostcrawler

 

◊ Cadfael

@Tanoh and Shalas, the 2^24 counter exists once per mobtype. This means that you'd need to spawn 1 Illidan per second to make the GUID roll over for Illidan-mobs. It has no influence at all for Lady Vash mobs, which you'd also need to spawn one per second for over a half year to make that one counter roll over, etc. Really, it's just not going to happen, you can't make the GUID roll over until the servers remain up really really long and you'd need an insane mob creation rate.

On page one of this thread there is an example how the GUID looks. Only a small part is the counter that increases, the rest is flags and the mob-type ID.

Err no, that wasn't really the original question. The mob GUID thing is a small side discussion based upon the question if a respawn is actually a despawn/destruction of the mob (and thus very probable its loot table as well) and creation of a new mob. And as we know that loot gets determined on creation, this would create new loot. Now with 2.4 we can see indeed that the mob GUID does change, so we can expect that each time this happens, loot has changed.

The original question is, if we can predict what is going to drop if the item is not in the server's cache, thus is unlinkable and we let the mob spawn, which should populate his loot AND the server's item cache, thus letting us link an item suddenly. This thesis should now become testable as soon as someone puts the M'uru encounter into the phase where the final entity that is eventually being looted springs into existence on a given realm with no M'uru loot in the realm pool yet. And once more as soon as Kil'Jaeden becomes available.

 

Torq

I highly doubt the mob GUID is in any way linked to it's loot generation, but here's a simple test:

When a server comes up from maintenance, log on, go to a very unpopulated area, and kill 50 (or 100, or 1000, depending on your patience) of x mob. Log each GUID of each mob as you kill it, as well as what it drops.

Next week, when the same server comes back up, go kill the same mobs. If no one is touching them, more than likely you'll be getting nearly the same GUIDs for all the mobs you're killing. Again, log their GUIDs and what they dropped. If you start seeing the same things on the same GUIDs, you've shown that the GUID is indeed part of the equation.

Otherwise, you've not really proven anything, to be honest. Sadly, we already know a timestamp is involved in the loot generation process somewhere.

If you think about it, if your goal is to create "random loot," would you use the sequentially generated GUID of the mob that drops the loot, or the pseudo-random numbers you get out of the PRNG you set up for that very purpose?

Regarding mob GUIDs, it's actually very likely that the server starts from scratch every time it restarts. It could be process-dependant, even, so zoning into a fresh instance may well start the GUIDs from 0 or 1. I say this because the GUID is just the handle to the mob, and a mob is isolated to one process/instance (how many mobs do we know of that can change instances?) so it only needs to be unique to that process.

I do find it interesting they're using sequential GUIDs for mobs. Granted, there isn't much you can do with mobs in the way of predictive manipulations, but in the way of items, weird things can happen if you know the handle of an item before it drops. Maybe not in this game, but that was the case in a previous Blizzard title.

 

duvar

Sorry, my wording was poor. My "original" wasn't really referring to the original post of this thread, it was referring to the "original" (at least I think) post that spawned this tangential discussion about GUIDs being tied to loot tables. See the very first post on this page, by me, in which I quoted the post I'm referring to.

Regardless, imo the actual original (of this thread) question is as answered as it's ever going to be unless a blue chimes in -- drops cannot be influenced (actually a blue has already chimed in with exactly that, but I guess it's not enough for most people). There's always a miniscule possibility of anything, but if so come to the thread with overwhelming evidence, not "hey we got 3 glaives in 5 kills, we might be on to something!" Moreover, even investigating how to influence drops is detrimental to the community. If it were ever discovered how to influence drops (which at this point I think it is pretty safe to say is not possible, even for the developers) someone at Blizz would eventually catch onto this, and make sweeping changes to the way loot is generated so as to prevent it from happening in the future. And then not only will we be back where we are now, but everything we already know about how the loot system works will be invalidated, and we probably will not be able to learn nearly as much about the new system as the current one.

 

Tanoh

That's not true, the spawn counter is global. Probably unique per instance or something though, but it's definitly not as you described it. To prove it I made a little trip into Ragefire Chasm with /combatlog active and killed "enough" mobs (up to and including the first boss) and then made a small perl script to parse the data. Here's an exert of the results:

If you want to see the whole output it's available here: http://pastebin.com/f44cc46fa

You can clearly see that the spawn counter (second column) does not reset when it changes mob type, it's a straight incremental.

The script is available here, http://pastebin.com/f5c735884, if anyone wants to use it for something. :>

 

skari

You also give the Hint here that the ID does not count the hole World or also Instace ID, because several Mobs would be killed while you where testing ;-)

 

Tanoh

Hm? I went there pretty much right as the server came up after a maintenence (Wednesday is maintenence day in the EU), it's highly possible that I was in the first Ragefire Chasm instance created. I saw a worm with 00002 as spawn counter before I started logging.

 

skari

May be you have to do the same Test with a Friend in another Ragefire ID and kill the same Mobs. Then we can see if this ID is handled for zones or IDs.

 

Torq

I would hazard a guess that it's unique to the instance you're in. Given that each instance is probably it's own process, the fewer things that are shared between processes, the better.

What would be interesting to find out is if a soft-reset actually restarts the spawn counter or not.

 

Tanoh

Did some more testing. A friend of mine and me each did a RFC clear up to and including the first boss at the same time. We got different spawn counters on all mobs and I found no collisions. I also did a clear of Scarlet Monastery: Library, and found no collisions in either three places. It seems like the spawn counter is indeed global, at least on instance level.

While writing this I tried checking the outside world for collisions. I ran/flew around in Tirisfal Glades, Isle of Quel'Danas, Netherstorm and observed people fighting, and fought some of my own to get as many GUIDs as possible.

I did find two collisions.

So it does seem like the instance counter is separate from the world counter. If I had more time I'd run around more in the old world and checked, it could be possible that the counter is separate for each continent. The counter for outland is quite high, and it's only been ~7 hours since maintenence.

eg:

It's not tied to specific instance.

I did RFC and then SM earlier:

Notice how the SM GUIDs ("Scarlet Beastmaster" and down) starts at a higher number than the last in RFC ("Voidwalker Minion"). I didn't kill the whole of RFC though, but it's enough to prove the point.

 

Torq

So perhaps it's tied to your instances. Though, those numbers are rather high for sequentially going from instance A to instance B (~9000 mobs is too high for just RFC and SM, all wings combined). Could be tied to THE instance, rather than your instance, as well. Could you check for collisions between your and your friends' RFC clears?

 

Tanoh

I doubt it's in any way tied to me as player.

I did compare the data and found no collisions when we ran RFC side by side, but now I've lost the logs by being a bit overzealous with the old rm. I can probably poke him to do another RFC run when I see him on.

My theory: The spawn counter is counted per server. The instance server has it's own counter separate from the real world counter. I happened to be the first in any instance on my server when I had 00002, it's possible there was a 00001 and a 00000 also, and I just missed them, or that they're reserved and not used.

It makes sense, at least to me . You can't see what's going on in an instance if you're not there, you can't see what the players in your party are fighting and/or targeting, or what's hitting them etc if you're on the outside. Hence there can never be any collisions. Player GUIDs are totally different and unique per battlegroup (probably).

 

Daedalix

This got me thinking... everytime I've run an instance with Trash Drops for the first time with a guild (such as BT, MC, BWL, etc.) I've almost always gotten some the first time the guild goes in. Literally the first few pulls ensures a trash drop. But seldom afterward. When I first ran TK we got trash epics on the first couple pulls. Now we clear the whole thing and might not get one. The first BoE epics on Azgalor (the server I rolled on release) were found in the first SM, BRD, etc. runs that were done. Two separate but related ideas (increased drop chance on the first few mobs a player sees and increased drop chance on the first few mobs on that server/instance) that I think spawned the "loot seed" controversy back in the day.

Anyone remember when Dire Maul came out? How many Quel'Serrar books did you see in the first few runs? My guild saw 3 in the first day. Good luck finding one afterward. Even with all the people running it (EVERYONE was in DM the first week) that's simply not statistically likely. Doubt anyone else saw the same rates, but it's bugged me since then why we got so many that first day. Random, probably. But seems more likely to be weighted to me.

It very well could be that Blizzard, either as an artifact of their own QA/testing methods or as a bone to bleeding edge raiders, increases quality drop chance in the first round of kills and then relaxes to a set % from there on out.

Entirely anecdotal, no testing done, just one man raiding for 3 years noticing a pattern. Interesting theories. It's nice to see some math finally put to this myth after so much speculation.

 

Barkskin

Is it quite possible that Blizzard has a looted item population ratio that needs to be met? Possibly dependent on the server's population size vs players logged in an instance. Or maybe just if server has X amount of players, X amount of specific item must exist on realm. This would be to ensure that all servers have an equal amount of goodies available to playerbase, thus meaning you couldn't claim some servers received special treatment (gotta love a QQ heavy population).

However, this would only benefit loot acquisition if the server resets during maintenence and doesn't remember what players existing have already in their possession.

 

Maledict

Sob.

Or maybe, maybe, it's just random luck. The clue was in . If you can't provide maths or at least a working theory about this stuff, you really need to think about why you're posting. We all have crazy loot streaks that don't make sense, some stretching over many years. We look for patterns where non exists - but without either some testing, or a working theory that can be tested, it's not adding anything to the discussion beyond "here's some more random loot drops".