As far as the question on mobs loot tables being generated when creating the instance, I think this is not the case at all. It can be proven in KZ with Aran. Unless its been fixed, if you kill him during drinking a soft reset will respawn him and you can actually loot him twice in 1 week. This happened to my guild before and we did not receive the same loot.
I can also confirm that loot is not tied to Raid ID. We killed Netherspite twice within one reset (killed him in a banish phase or something, came back the next day and his trash and he himself were back) and got different loot the second time.
[...]
3) The PRNG is seeded with a timestamp.
[..]
Actually, we don't know that. And I'd be surprised if it was a straight timestamp they used for seeding. It's usually a very bad idea to use timestamps without any modificiation. A commonly used trick on smaller applications is to use the timestamp with some combination of the ProcessID, eg <seconds since 1970-01-01> mod <processid>.
Either way, the most important thing of any seeding algorithm in any game, is that the player can in no way influence what the seed is going to be. Which I'm fairly certain that Blizzard knowns and has designed WoW with that in mind.
I think there's some miscommunication about what is meant by "when the instance is created." My understanding is, instance creation happens again every soft reset, but when the instance is created it's completely filled out with mobs. This is in opposition to it mobs being persistent through soft resets via raidID, which is what you two (dragosal and anedris) are talking about. It is also in opposition to mobs being created dynamically when you get within draw range, which is the main point. The open question is about 'events' where the boss spawns upon some activated event rather than being a persistent mob--do they actually spawn, or do they simply become visible?
Most bosses are spawned upon instance creation, as you can /target them from miles away. Though there are a few who need a trigger to spawn(Kael'thas 25, Hyjal bosses, Reliquary, etc.). Although i'm not too sure about BT bosses, i'll need to check next reset if i can target Illidan from Naj'entus' room, but I do know all of the BT bosses are targetable from the center room with /target.
Most bosses are spawned upon instance creation, as you can /target them from miles away. Though there are a few who need a trigger to spawn(Kael'thas 25, Hyjal bosses, Reliquary, etc.).
Hmm.. about Kael'thas, shouldn't he (and Lady Vashj) be spawned on create now? I haven't been inside either TK or SSC though but the patch notes said you could do Vashj and Kael without killing all the other bosses, which should mean they are there from the start?
And also, not that it really matters. For all we know they are there on create, but moved to a black void or otherwise hidden from us until we trigger something that makes them appear.
Actually, we don't know that. And I'd be surprised if it was a straight timestamp they used for seeding. It's usually a very bad idea to use timestamps without any modificiation. A commonly used trick on smaller applications is to use the timestamp with some combination of the ProcessID, eg <seconds since 1970-01-01> mod <processid>.
Either way, the most important thing of any seeding algorithm in any game, is that the player can in no way influence what the seed is going to be. Which I'm fairly certain that Blizzard knowns and has designed WoW with that in mind.
The reasons I state it up with the "things we know" is that there's a blue post that actually says that, in some detail. Drysc posted here. He does use the language "I believe," however, so it may still be speculation.
Not that it really matters, as it's something that's completely out of the control of the player to influence, whatever the case. Even if you knew exactly what seeded the PRNG, and could somehow influence the initialization of it to the exact value you wanted--or could know the exact series of values that would come from the PRNG given a known seed--there are still too many variables to know your loot.
The best approach to cherrypicking loot is to not force the system to give you what you want, but to reset the system until it does.
Considering I'm hearing that the first gate opened yesterday, would it not be a prime opportunity to test these theories out?
I suppose this would be heavily dependant on whether or not you can see if the Twins are up when you zone in (or within a reasonable sneaking distance). If that is indeed possible, now would be the best time to start reset/linktesting. The following is a possible test:
0) Start by finding out all items that are linkable from the Twins' drop table, and conversly, all that are not.
1) Pair people up, and have them zone into a fresh instance, one pair at a time.
2) As each pair goes in, have one go up to the point where they can get a target lock on either of the Twins. At this point, begin to test all the unlinkable items.
3) After all items have been confirmed as linkable/non-linkable (the second person is idling in the instance to hold it through disconnects), this pair's job is complete.
4) Repeat steps 2-4 for the next pair. Hopefully perform this with a relatively-large sample size, as in 20-30 pairs. Alternatively, you could test this with fewer pairs, making use of soft-resets to reset the whole instance. You would need some sort of indicator that you've successfully reset the instance, however, to verify this.
I'm assuming that many of the items are already linkable, because they can be traded in for something different. This, unfortunately, makes the job much harder, as it's possible to do this test 100 times, and even IF the theory is correct, not see any proof/disproof of it because the items on the loot table always end up being the items that are already linkable.
Just throwing this out there, I'm sure there are other theories and test that could be validated with an opportunity like this.
Have at it, and don't like this opportunity go to waste! We probably won't get another like it until WotLK.
Actually, we don't know that. And I'd be surprised if it was a straight timestamp they used for seeding. It's usually a very bad idea to use timestamps without any modificiation. A commonly used trick on smaller applications is to use the timestamp with some combination of the ProcessID, eg <seconds since 1970-01-01> mod <processid>.
I would wager that over 90% (actually, I'd probably bet 95% or more) of applications simply do
Then one can at least attempt to verify whether or not the respawning of a boss has any affect on it's linkable loot table at all.
I'd say that with the amount of guilds that are attempting them, we could at least gather in a little bit of data on this. If no change is apparent across many (note: subjective) trials, we can conclude that the respawning of a boss has no effect on it's visible loot table.
[E] Unfortunately, if no change is apparent, it neither proves nor disproves that loot is generated upon boss spawn.
However! If linkable loot does change, the implication is that not only is loot determined on boss spawn, it is also actually generated upon boss spawn, and that respawning a boss does in fact regenerate it's loot table.
[E2] I'm going to go out on a limb and speculate that resetting a boss does in fact regenerate it's loot table. I have nothing to prove this with, but circumstantial evidence points to this being the case. See the above references to killing a boss multiple times in one reset, and receiving different loot. The only thing that makes me question this is that there's a very good possibility that killing a boss is an entirely different chain of programmatic events than merely resetting it, beyond the obvious, of course. That is to say, respawning a boss may or may not delete the existing mob structure, before creating a new one, whereas killing a boss most likely does.
I would wager that over 90% (actually, I'd probably bet 95% or more) of applications simply do
srand(time(NULL));
Your average "I need some random numbers in my program I wrote on an afternoon", is quite different from a professionally developed MMORPG. Or so I hope at least. :>
I'm confident that Blizzard's developers thought this one through all the way and made sure it really was as random as computers can make.
Your average "I need some random numbers in my program I wrote on an afternoon", is quite different from a professionally developed MMORPG. Or so I hope at least. :>
I'm confident that Blizzard's developers thought this one through all the way and made sure it really was as random as computers can make.
It's an MMO, not a Monte Carlo numerical simulation. Making it as random as can be made is completely unnecessary; the period of any decent generator (or, indeed, most bad ones) will be so far above the number of drops as to make it irrelevant.
Your average "I need some random numbers in my program I wrote on an afternoon", is quite different from a professionally developed MMORPG. Or so I hope at least. :>
I'm confident that Blizzard's developers thought this one through all the way and made sure it really was as random as computers can make.
While I don't know how Blizzard does RNG it's not as if it matters. Because there are so many different threads getting random numbers, it's impossible to get any coherence from the data you get back.
That said, IF they wanted really good numbers, there's no need to do it yourself anyway. There are enough devices which deliver perfect random numbers in any amount you want. I think the swiss company Omnisec has some available and plenty others also.
It's an MMO, not a Monte Carlo numerical simulation. Making it as random as can be made is completely unnecessary; the period of any decent generator (or, indeed, most bad ones) will be so far above the number of drops as to make it irrelevant.
It's not your average home brewed program either. The points I was trying to make was that their server code won't look something like:
int main( int argc, char **argv )
{
InitServer();
srand(time(NULL));
RunServer();
};
It's not your average home brewed program either. The points I was trying to make was that their server code won't look something like:
int main( int argc, char **argv )
{
InitServer();
srand(time(NULL));
RunServer();
};
You know, I'm willing to bet that it does. It's a game and it doesn't require any ridiculously complex random number generation and is simply not worth the effort to make it better. srand() is plenty good enough for Wow's intended purpose.
You know, I'm willing to bet that it does. It's a game and it doesn't require any ridiculously complex random number generation and is simply not worth the effort to make it better. srand() is plenty good enough for Wow's intended purpose.
To be completely honest, I doubt that it does. If they put the thought into it to use IBAA as the PRNG over the default OS PRNG, I doubt they're just seeding it with time. Drysc (I think) posted that he "believes" it's seeded with a timestamp, so it is entirely possible it's just time(NULL), but you I would think they care enough to put at least a little salt into the seed.
However, all of this is almost entirely moot anyway. IF you knew exactly what the seed was, and what the exact PRNG was, you'd still not be able to predict rolls with any kind of accuracy unless you knew EXACTLY what rolls were being carried out (or how many) at any given time.
And if you knew that much, you probably have more access than you're supposed to, and it'd be entirely easier to just "fix" the loot generation to whatever you want.
It seems like a fair number of people are choosing to ignore the fact that it doesn't matter how complicated the random generator is. The roll is server side... and if we can assume server populations, on average, of 1,800 at any given point in time... 10 million accounts, 221 servers for US, assuming same count for EU and Pacific, 15,000 accounts per server on average, assuming 3 hour average per day per account, and conservatively 1/2 is accessing the RNG in some way at any given point in time, even if just to choose the next direction of that 'randomly' wandering mob within draw distance, there is probably 90-100 RNG requests per second.
If you could determine the seed, or reset the seed, and actually watch all the generated numbers (before truncating) scrolling by, you have to have something set up to generate the action you are trying to do in a smaller time frame than 10ms to be able to grab the next number before the next server request for it. And that is conservative. 1 ms is probably more accurate. Either way, sheer connection latency will doom that. You would have to have a connection of 4ms or better to meet the 10ms window (4ms to get to you, 1ms to process, 4ms to get back... 5ms latency would put it over.) 0.4ms to meet the 1ms window. And even that is assuming a steady rate of RNG requests for an extended period of time. The constantly changing population count logged in on any server is enough to compact or expand this window quite a bit.
Quite a feat indeed.
There isn't any need for a more complicated RNG. The stronger the player base and activity, the more secure the RNG is. Try being the only one on a private server first, and then what's the point?
On the related note, about linking. I have been working on a mod, that part of it watches events from non-players that are in range. I was having trouble with it last night, so remove it's filters last night during Illidian, and I noticed that 2 hostile NPCs by the name of 'Blade of Azzinoth' registered in the mod with SPELL_CAST action and a destination of 'Flame of Azzinoth'. This occured when the flames spawned at the start of phase 2, and was their sole action.
I do not know for sure what impact this had, but I do wonder if this has something to do with the sudden ability to link the Warglaives during the Nhilum first kill. It is more likely a GM pulling up the item, but food for thought if not.
To be completely honest, I doubt that it does. If they put the thought into it to use IBAA as the PRNG over the default OS PRNG, I doubt they're just seeding it with time. Drysc (I think) posted that he "believes" it's seeded with a timestamp, so it is entirely possible it's just time(NULL), but you I would think they care enough to put at least a little salt into the seed.
However, all of this is almost entirely moot anyway. IF you knew exactly what the seed was, and what the exact PRNG was, you'd still not be able to predict rolls with any kind of accuracy unless you knew EXACTLY what rolls were being carried out (or how many) at any given time.
And if you knew that much, you probably have more access than you're supposed to, and it'd be entirely easier to just "fix" the loot generation to whatever you want.
I really think you're overestimating the importance of randomness in this game. It's not the space shuttle atlantis, it's just loot generation. srand(time(NULL)) is more than adequate for this purpose. The only requirements for their RNG should be the following:
1) Not able to be influenced by players
2) Should generate all numbers with approximately equal probability.
That's it. srand and rand are fine for this, although they might even go so far as to use rand_s from newer versions of the CRT. Either way, it's a non mission critical application, and I really don't think cryptographically secure random numbers are a very high priority. Speed, however, probably is.
I really think you're overestimating the importance of randomness in this game. It's not the space shuttle atlantis, it's just loot generation. srand(time(NULL)) is more than adequate for this purpose. The only requirements for their RNG should be the following:
1) Not able to be influenced by players
2) Should generate all numbers with approximately equal probability.
That's it. srand and rand are fine for this, although they might even go so far as to use rand_s from newer versions of the CRT. Either way, it's a non mission critical application, and I really don't think cryptographically secure random numbers are a very high priority. Speed, however, probably is.
I would agree with you, except for the minor detail that a Blizzard rep has explicitly stated that they use the IBAA PRNG, unless they've shifted to something else. I would dig up the link, but 1) I don't have time at the moment, and 2) I believe it's already been posted.
PRNGs nowadays are made with an eye towards runtime too, so it's not like there's a particularly compelling reason not to use a cryptographically secure one. Despite being effectively unbreakable for logistical reasons, the fact that it decides most aspects of game balance and economic stability means there is at least a just-in-case justification to make sure it's extra unbreakable, especially when the computational cost of doing so is not significant.
It occurred to me that this theory can still probably be tested on almost every realm with Ashes of Al'ar. Most servers still have not seen an Ashes of Al'ar drop, and with Kael now being unlocked right when you zone in the instance... If it does work, then grats on every server seeing an Ashes of Al'ar drop within the next 7 days
But everyone in the realmpool bringing one with him in his inventory might unlock it. So not really doable.
Kil' Jaeden will be the main test, as he is as far as we know not spawned and does spawn in at the start or during the encounter. At which point his loot table should become available and if we expect that noone kills him right at the first day, there won't be any outside server interference.
All there is left to do is wait for the last gate, scan before the first guild spawns him. Scan after he has been spawned and compare. This will give the answer.
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.
Not sure if this has been said before but this is wrong! Im not sure about the exact drop rate so ill call that X% for now. The first time your raid zones into BT after a reset the loot table is created automatically by the server, hence the glaives have an X% chance of being there when you kill Illidan, THIS DOES NOT STACK! The next reset does not make the % chance of a glaive any higher, it will always be X% every reset, this is why guilds who have downed Illidan 50+ times have still not gotten any, it is always a fixed % chance, there is no mulltipliar to increase it.
So in your example of 15 kills at X% the chance of getting one glaive is still X% at each kill
*X% in this case is pretty low, 0.1%~3% from what ive found online and its seperate for each glaive, in theory its possible for both to drop (havent found anything that says otherwise but this could still be wrong)
Oh and its not statistics as your thinking of it, its more % probability without any outside interferance
04/05/08, 4:49 AM
Similar Threads
