I've actually thought about this a few month ago, but could never test the following steps due to my server warglaive population. Now WoR posted about 40% drop rate for a certain guild this comes up in my mind again.
You need to meet following conditions:
- Server restart - item cache cleared
- Noone with glaives logged yet or it has never dropped
If we meet this 2 conditions server will disconnect us whenever we try to link warglaives in chat.
Loot is generated upon mob spawn (blue confirmed)
If you think about this for a second all you need to do is keep spawning BT instances until warglaives can be linked in chat - that would mean this particular instance contains one
ps. That would also explain why our server had warglaive link on the 1st Nihilum kill, yet they haven't got the drop - some other spawned instance ID had warglaive
p.p.s. I realise it is a game mechanics abuse borderline, if you find this post inappropriate feel free to remove it
Warglaive links were available because the glaives can be targetted during phase 2 as some kind of perverse joke on rogues/fury warriors in unlucky guilds. But as first in line for warglaives in my guild, I wholeheartedly support any attempt to ensure a drop.
On a side note regarding raid ID's, I've been watching my guild's ID for the past few weeks and each Tuesday when we clear out Hyjal and head into BT, our raid IDs for the two instances end up being the same. i.e. this week both instances are ID 2372642, last week they were both 2370020. Does anyone else notice this happening?
The warglaives are in their own loot table, with about a 5% drop chance. In 15 kills, the chances of getting 1 warglaive is about 46%. The chances of 2 warglaives is 21%, 3 is 9%, 4 is 4.6%, 5 is 2.1%, and 6 is 0.98%.
Since there are more than 102 guilds killing Illidan, statistically speaking, it's perfectly expected that one of them got 6 warglaives in 15 kills.
Our current theory is by the way that the worser the kill the better the loots! Discuss!
I wish this where true
Sadly our best kill so far dropped our first Glaive ...
Although globaly this kill might have been realy bad when compared to the other kills that day ?
Is the "worseness" just compared in the realmpool or on the continent ?
Maybe its a revard for having the "worsest" kill last week ?
My theory revolved arround sacrificing certain classes to the Mob in the right order ...
Originally Posted by Antiarc
The warglaives are in their own loot table, with about a 5% drop chance. In 15 kills, the chances of getting 1 warglaive is about 46%. The chances of 2 warglaives is 21%, 3 is 9%, 4 is 4.6%, 5 is 2.1%, and 6 is 0.98%.
Since there are more than 102 guilds killing Illidan, statistically speaking, it's perfectly expected that one of them got 6 warglaives in 15 kills.
So this statisticly proves (again) that loot is truly random and not in any way seeded
On a side note regarding raid ID's, I've been watching my guild's ID for the past few weeks and each Tuesday when we clear out Hyjal and head into BT, our raid IDs for the two instances end up being the same. i.e. this week both instances are ID 2372642, last week they were both 2370020. Does anyone else notice this happening?
The instance ID is your raid ID which is somewhat bound to the person with the (L) at the time of instance spawning. You can easily manipulate this by for example disband the raid and let someone else reinvite before going to BT after Hyjal. It should actually suffice to just give the (L) to someone else before the first person steps into BT.
We used to switch L's a lot back in MC and BWL times in order to try to mess with the loot generation (trying to break streaks).
Philosophical question: Even if that would work what Elhana suggests; does the loot change when you wipe at Illidan and he de- and respawns ?
Philosophical question: Even if that would work what Elhana suggests; does the loot change when you wipe at Illidan and he de- and respawns ?
We'll be able to tell in 2.4. If his GUID changes, chances are good that his loot table did too (since, at that point, it's a new instance of a mob object, by all indications, and from the design that's been hinted at, something in the object constructor is responsible for loot table generation). I'd be willing to bet that the GUID does indeed change.
Originally Posted by Glik
So this statisticly proves (again) that loot is truly random and not in any way seeded
Of course it's seeded. Non-quantum computers can't do truly random number generation. However, the seed is really very likely to just be whatever the value of the last random number the server generated is. Given the population of a server and the number of random numbers being generated at any given time, gaming that number is effectively impossible.
Most "loot conspiracies" boil down to the fact that you run 25-man raid instances once per week, which is 52 samples per year, and even in a 2-chances-per-kill-to-drop scenario, 104 samples is a piss-poor number for drawing statistical conclusions from.
Drysc revealed just about as much as you're gonna learn from this post. However, finding a way to control the loot generated is obviously still very difficult.
Loot is generated when the mob is created, not killed.
There is a variable that determines the loot the mob carries.
The variable according to Drysc is a time stamp.
The mobs aren't actually created until someone enters the area.
Now obviously there are varying degrees of control that we can or cannot possibly control as players. However, if the time stamp is in seconds for example, it'll be next to impossible to always time something, as server time doesn't display seconds, and I imagine that since mobs are based on the server this would be the most accurate scale. If the time stamp is in minutes that's another story. There are many mobs that can be player spawned to test this theory by simply spawning the same mob at the same time every day. This is a crude simplified way of doing it mind you, because there are still other variables to consider.
Another such variable to consider is if the time stamp for the loot itself changes. Does it change hourly? Does it change daily, does it change weekly with every server restart, that's another important test. if you have 2 groups kill a mob that spawns at the same time at say 6:47(I RNG'd this :P) and they get the same loot, and then have them repeat the process the next and day they get different loot, it would be impossible/pointless to determine when the item you want is on the time stamp you need.
In addition spawning monsters in an instance is also a question to consider, do ALL mobs in an instance spawn upon creation, or do you have to get to certain parts of the instance before they spawn, for example is Sumpremus and all of the dragon riders up when you're fighting Naj? Is Mother Shazz and the Council up while you're taking down Teron/RoS/Bloodboil? These are all things that need to be tested and experimented with.
All that being said, I doubt you'd find people to find the time to dedicate them selves to such precise testing. >_>
Even knowing all of this, there's still probably no way to force loot generation. To quote Robert R. Coveyou said "The generation of random numbers is too important to be left to chance."
I had always been under the impression that loot was based on instance ID. Mostly from anecdotal evidence pre-BC of a raid getting the exact same drops from MC two weeks in a row under the same ID and bosses dying and then getting reset due to a bug or server reset and dropping the exact same loot.
If GUID can be seen in 2.4 and changes at every wipe it would seem incredibly easy to just start tracking which ones drop warglaives and clear to Illidan one night and let a rogue (who is probably the only one interested enough to do this) continually start and reset him until you get one proven to drop a glaive and then just sit in the instance until the next day. I know I'd be willing to stay up all night one night if it meant I'd get one the next day. (assuming the raid didn't then blow it and wipe)
Edit @Emeraude - Once you're in the temple proper (past Supremus) you can do a /target [insert boss here] to any boss in the dungeon, so they are all spawned by that point at least. Hyjal, however, certainly operates under different rules.
We'll be able to tell in 2.4. If his GUID changes, chances are good that his loot table did too (since, at that point, it's a new instance of a mob object, by all indications, and from the design that's been hinted at, something in the object constructor is responsible for loot table generation). I'd be willing to bet that the GUID does indeed change.
I actually expect the GUID to be always the same for exactly the same mob. Meaning, Illidan always having the same GUID as well as, say any named mob's GUID. Has there been any explanation what exactly the GUID is ?
Generally only one single specific mob can be up at any one time, so there's not necessarily a need to change GUIDs of mobs. What can happen I guess is that there is a corpse of a named mob and the named mob is up at the same time. Hm, if PTRs go up again that's one thing I want to test out.
This is somewhat of an intrigueing post for me since i'm waiting for a MH Glaive.
But can anyone actually confirm that a piece of loot that normally couldn't be linked, can be linked between boss spawn, and the killing of a boss? Currently this is the piece of information that is the crux of this theory, and what stands between people getting on demand warglaives, and not.
The chance of being able to find out through linking, even if it works, is pretty slim. Items can be linked under the following two conditions:
- Someone on your server has the item(s), and this person has logged in since the last time your server went down.
- Someone in your battlegroup with the item(s) has participated in a battleground or arena match since the last time your server went down.
Having killed a boss that can potentially drop an item does not necessarily mean you can link all items the boss can potentially drop. I speak from experience with trying it out here, we were the first guild on our server to progress in Black Temple and Hyjal, and I was incapable of linking the [Tide-stomper's Greaves] after our first few High Warlord Naj'entus kills (They have also never dropped for us, much to my annoyance).
I would imagine that the loot *is* actually generated when the mob is killed. The decision of what loot will drop, however, is made when the mob spawns. Basically when the mob spawns, the time of birth is saved, and that is then used to seed the rng that generates the loot when the mob dies. From a programming point of view it wouldn't make much sense to introduce new items into the game world, unless there is a chance that they might actually be seen by players (i.e. the mob can be looted).
Warglaive links were available because the glaives can be targetted during phase 2 as some kind of perverse joke on rogues/fury warriors in unlucky guilds.
Does anyone have a solid evidence of being unable to link MH before Illidan 1st attempt and weapon being present in server cache after the fight?
Originally Posted by Chicken
Having killed a boss that can potentially drop an item does not necessarily mean you can link all items the boss can potentially drop.
If you'd been able to link all items possible, then it would render my idea useless - I expect an item to be loaded in server cache whenever it gets into mob lootlist.
I agree chances are slim as I stated at my 1st post I can't check it on my server reliably, because we got atleast 12+ glaives and it is hard to expect them all offline while you do this.
Based on the blues saying loot is created on boss spawn, it is very likely that mobs that spawn different forms or IDs of itself generate new tables as they change. A good example of this would be C'Thun who should generate a new table everytime he went into phase 2. I can't imagine a loot table being associated with his phase 1 form. Quite possibly this applies to Illidan as well when he changes between Demon and Humanoid forms.
I actually expect the GUID to be always the same for exactly the same mob. Meaning, Illidan always having the same GUID as well as, say any named mob's GUID. Has there been any explanation what exactly the GUID is ?
Generally only one single specific mob can be up at any one time, so there's not necessarily a need to change GUIDs of mobs. What can happen I guess is that there is a corpse of a named mob and the named mob is up at the same time. Hm, if PTRs go up again that's one thing I want to test out.
We'll be able to tell in 2.4. If his GUID changes, chances are good that his loot table did too (since, at that point, it's a new instance of a mob object, by all indications, and from the design that's been hinted at, something in the object constructor is responsible for loot table generation). I'd be willing to bet that the GUID does indeed change.
Without needing to wait 2.4, the question about whether or not the GUID of the NPC changes on despawn has already been answered:
3) Given a raid and a raid boss, if the boss despawns due to either a wipe or boss mechanic, would the GUID change?
A monster has a single GUID from spawn until death (or despawn). When it respawns it gets a new GUID.
So I guess that yes, after a wipe the boss would get a new GUID. If this would generate a new droptable though, remains to be seen (and I am afraid we won't be ever able to check this as players).
Chicken you could test it by trying to locate a server where at least one guild is progressing through BT, but didn't kill Illidan yet. Log into the server before the weekly reset, and try to link it.
One reason the Warglaive could be linked, could be because a GM that was following Nihilum's raid, touched the item in any way, triggering it to get into the server's cache... Maybe just browsing through the loot list and making bets what they would get...Who knows?
More technically, another reason could be because the Illidan's script uses the Warglaive's itemId to retrieve the actual weapon model that Illidan wields during the fight. From memory, they seem to be identical, only slightly scaled, and since they are dynamically attached/detached to the mob's model during P1->P2->P3 transitions, just like a player wielding weapons, it's a realistic possibility. It also explains why it could be linked after they attempted him, since when he's not engaged, he doesn't wield the weapons...
Speculating about the loot generation based on what happened during Nihilum's kill doesn't make sense unless we can assert that it holds true on other servers...
Regarding the randomness. There are actualy Quantum Random Number Generators available as PCI cards. Using quantum states, the numbers are truly random, and can be delivered with bitrates up to 16 Mbps with the best technology today (see e.g. quantum random number generator, QRNG, True, TRNG)
Additionally, I know from talking to some of the people behind that company, that their largest customers are infact online gaming companies, but whether that is online poker games or similar, or games like WoW I don't know. It does however illustrate that the technique is commercially viable and there is a chance they are used in WoW as well.
The GUID from the combat log for the 2nd boss in two different copies of the instance (a week apart).
This is as expected, otherwise 2 different people in 2 different instances at the same time would be fighting the same mob, which wouldn't work, obviously...
More interesting would be to check if triggering a boss reset, more specifically, one like Illidan, where the mob actually "vanishes" for a few secs while reseting, would trigger a new GUID. This would mean that the loot would actually changes after each wipe, which would create a whole new wave of jokes when wiping!
Based on the blues saying loot is created on boss spawn, it is very likely that mobs that spawn different forms or IDs of itself generate new tables as they change. A good example of this would be C'Thun who should generate a new table everytime he went into phase 2. I can't imagine a loot table being associated with his phase 1 form. Quite possibly this applies to Illidan as well when he changes between Demon and Humanoid forms.
Mobs spawning as entities are very different than the form you see those mobs in. Nobody can say that c'thun phase 1 and 2 are 2 different entities. Nobody can say that the illidan entity doesn't spawn as soon as you zone into BT for first time. RoS phase 1-3 are infact there all the time, they are just hidden entities. RoS encounter doesn't really spawn after you start it. It's not technically elegant to calculate such things during encounters, as it will eventually increase the server side lag, as the server will be under pressure to calculate extra variables in a very short amount of time. That issue is one of the reasons that you see loot lag or spawn lag in games like EvE-Online.
Generally though I believe that instance mobs and the information related to them are all generated and saved as soon as raid instance is created. Blue did say that instances are different. Such a mechanism is needed to ensure the capabilities of blizzard to make instances in which only maximum of X amount of certain item should drop, yet those drops can be from any random mob.
The mobs aren't actually created until someone enters the area.
(snip)
Another such variable to consider is if the time stamp for the loot itself changes. Does it change hourly? Does it change daily, does it change weekly with every server restart, that's another important test. if you have 2 groups kill a mob that spawns at the same time at say 6:47(I RNG'd this :P) and they get the same loot, and then have them repeat the process the next and day they get different loot, it would be impossible/pointless to determine when the item you want is on the time stamp you need.
(snip)
A time stamp will almost certainly be sub-second accurate. The easist way to do this would be to use the OS C function "clock" that returns the number of clock ticks elapsed since the program was launched, in the time unit "CLOCKS_PER_SEC", which on a win32 platform this is usually 100 (1/100th of a second).
I would be astonished if any system using time stamps for RNG were using a lower resolution time stamp than that.
This is as expected, otherwise 2 different people in 2 different instances at the same time would be fighting the same mob, which wouldn't work, obviously...
As far as I know, each instance runs on its own process so there is no technical need for this. Instances are essentially their own world servers. Since you can't ever be in two instances at the same time with your char nor is anything you do inside an instance relevant for the "outside world" this doesn't need be so.
More interesting would be to check if triggering a boss reset, more specifically, one like Illidan, where the mob actually "vanishes" for a few secs while reseting, would trigger a new GUID. This would mean that the loot would actually changes after each wipe, which would create a whole new wave of jokes when wiping!
Visibility changes don't necessarily have anything to do with the mob object itself. We will see that soon enough though.
Briefly, WoW uses IBAA to generate pseudo-random numbers. The generator is seeded once when the server process is started (presumably from a time stamp or similar data) and then used for all events in that server process until reboot. That would mean that events in a Deadmines run on the same server can affect whether or not illidan will have a warglaive. Of course, IBAA is meant to be a cryptographically strong random number generator, so even knowing a series of random numbers, you would not be able to predict the next. You can in particular not influence seeding through in-game events, since seeding precedes any in-game events.
My understanding is also that not all mobs in an instance (or outdoors zone) may spawn immediately when you enter the instance, but only when you come within a certain range, and this is why you can sometimes see mobs casting self-buffs as you approach. That is aside from mobs that are spawned by player actions, such as the opera house in Karazhan, or the Lurker Below, and presumably do not exist (along with their loot tables) until they actually come into existence.