 |
| Welcome to Elitist Jerks |
We're testing some new features on the site regarding OpenID registration and coordination with gamerDNA. If you experience any issues with registering an account, please take the time to fill out a report and send it to this e-mail address. We would appreciate any assistance you could provide in making sure everything is functioning as intended. Thanks!
If this is your first visit, please be sure to check out the FAQ and the forum rules. Users must register to post and new registrations are subject to a one day "mute" period to get acquainted with the community.
|
10/29/07, 5:17 PM
|
#151
|
|
Von Kaiser
|
Originally Posted by Cadfael
A blueposter long ago said once that they are using IBAA as RNG and each process has its own RNG, sharing it with everyone running on this process. However it may very well be that each instance is its own process and thus you really have your own RNG which gets instantiated when the instance spawns. If there is a problem with seeding at this point, you really can get into some trouble from a statistical viewpoint.
|
I'm aware that I'm stepping on shaky ground with mere anecdotal reference and conjecture, but I can't remember ever being kicked/disconnected out of an instance without everybody else on our realm being kicked/DCed as well -- unless it's based on connection issues on my side, obviously. To me, this leads to the conjecture that most likely, instances share a common process, since by now, I'd expect to have seen a process crash vs. a full instance server crash.
Also, it seems to me that it's just good design to have everything that needs random numbers to sip them from a common pool, especially in a case like WoW. Because, as you have pointed out indirectly, the more different sources tap into the RNG pool for different purposes, the less important it actually gets how random your numbers really are -- because the sequence of random number requests is random in itself, depending on hundreds of players hitting buttons on their keyboards, client-server lag, etc. To me, this sounds almost as good a RNG source as the proverbial RNG box that monitors radioactive decay. 
|
|
|
|
|
|
10/30/07, 12:38 PM
|
#152
|
|
Von Kaiser
Undead Priest
Al'Akir (EU)
|
I can definitely confirm it is possible for individual instances to go haywire, while the zone itself remains up.
We had a TK instance last week seemingly crash on us, locking our characters running into Kael'Thas, whilst guild / zone chat was still working, with other groups continuing normally.
It took 3 hours and several GM's to kill the raid and port the bodies to the instance door - but thats by the by. It's a pretty rare occurance, but it does seem to happen.
|
|
|
|
|
|
10/30/07, 3:28 PM
|
#153
|
|
Von Kaiser
|
My working “on spawn” theory involves a MobID field. I use to be an application modeler for VB applications a few years ago and each mob having its own unique ID tag seems normal to me. I would also not be surprised if “on spawn” the MobID was given a property that contained a RND that correlated to predetermined loot table positions.
For example, when Ragnaros #56745 spawns he is given a LootRND property of let’s say “12345478912271”. When he dies the corpse does not need to generate the loot it simply runs the query to gather each item from the loot list. One way to do it would be to break the RND down to seven 2 digit numbers used to determine loot. I’m behind on database performance but an “equals too” query is usually faster than a conditional query and both would be faster than calling code to /RND and select the item. We hammer the /RND less by just giving the MobID the property on spawn.
So we grab itemID at position 12 on Loot Table A (legs 1), 34 on Table A (legs 2), 54 on Table C (epic 1), 78 on Table D (epic 2), 91 on Table E (legendary chance), 22 on Table F( trash drops), and 71 on Table G (trash drops).
I think with the last patch the MobID maybe available to the client for mods like Omen to tell the difference between 2 mobs of the same name. If this is true, my theory could be proven by being able to see that number before and after this server crash or soft reset events.
This system hides the property for LootTag and the Loot Tables for that mob from the client so we can’t “peek”. This also allows them to build generic loot tables and just have mobs pull from that shared table. The RND could be 16-32 characters or use some sort of quick math to generate the same number each time out of one 16 digits long but still correlate to a 99 or 100 position loot table. I bet the RND in that property is even used to determine the silver value on the fly. (300 copper + last 3 digits ) = 301 to 1299.
When we soft reset an instance, I think boss mobIDs are saved to the RaidID. If we kill that MobID and the instance does not get flagged that he is dead. He is later spawned with a new LootTag. The relationship between the RaidID and the “saved” MobID objects could generate these situations depending on the type of error is occurring. On server crashes, we see the exact same loot because the MobID and lootTag have not changed. When we kill Shade of Aran 2-3 times in the same RaidID, we are getting new MobIDs and LootTags each time because they relationship to the RaidID is not getting updated. I wonder if when those situations occur if they see in the raid data a Raid ID with 3 shade of aran kills or if some of them simply got lost in some sort of overrun error or write error and they might only see the one that made it.
I’m rambling. If there is a way to record the MobID now though, it would be cool to see if the same MobID generates different loot. If the MobID persist the whole week on the same boss and other such things. Not that it matters to the mental goal of wanting to be able to predetermine the loot since the LootTag property and the correlating Loot Tables are not accessible without finding a DB hole to drill and I’m sure that would get attention of their legal department if you have a subscription or not.
Last edited by Jitta : 10/30/07 at 3:35 PM.
|
|
|
|
|
|
10/30/07, 3:38 PM
|
#154
|
|
Von Kaiser
|
Since many of you are looking into loot drops and the rarity of items, has anyone else faced limited Hero drops for teir 5?
It seems like we end up with Double champion, Double Defender, Champion and defender, but only singles for hero drops. Its almost a joke as our teir 5 pieces are going for 700+ dkp and defender/champion in the 200 or less dkp range.
Its almost as though the table seems alphabetic and Hero just doesn't come up as much for each category and that doubles are rare due to their placement.
|
|
|
|
|
|
10/30/07, 3:59 PM
|
#155
|
|
Glass Joe
|
Statically it's hard to see a pattern with such a low sample to pull from making it very easy to cry "Tinfoil Hats! Another Blizz conspiracy uncovered!"
I think a better test would be to get on private wow servers and dig into how loot drops are calculated to give a basis for the theory.
|
|
|
|
|
|
10/30/07, 4:49 PM
|
#156
|
|
Great Tiger
Tauren Druid
Al'Akir (EU)
|
Originally Posted by chadcook1999
I think a better test would be to get on private wow servers and dig into how loot drops are calculated to give a basis for the theory.
|
At the risk of sounding like a noob: there are private WoW servers?
Wouldn't that kind of thing be rather, hm, illegal etc? But all the data one could mine... sweet, forbidden data. Damn, this would be one of them difficult moral dilemmas.
|
|
|
|
|
|
10/30/07, 5:03 PM
|
#157
|
|
Great Tiger
|
Originally Posted by Sackobones
Since many of you are looking into loot drops and the rarity of items, has anyone else faced limited Hero drops for teir 5?
It seems like we end up with Double champion, Double Defender, Champion and defender, but only singles for hero drops. Its almost a joke as our teir 5 pieces are going for 700+ dkp and defender/champion in the 200 or less dkp range.
Its almost as though the table seems alphabetic and Hero just doesn't come up as much for each category and that doubles are rare due to their placement.
|
And we no longer get champion, by the way.
And the reason for this is not because the table is alphabetic, it's because loot is random.
We're gonna keep writing it over and over.
People want to see patterns in things that don't exist. Listen to a sports handicapping show and you'll hear some nonsense like "In games played after a Monday night game, the Cowboys at 14-4 against the spread when they are a home favorite of 3 points or more."
If you search long and hard enough you can create a fake pattern to fit anything you want to explain.
Of course, when the Cowboys fail to cover that weekend, the handicapper isn't explaining how his 14-4 "sure thing" just went to 14-5. Similarly, when you draw Hero 9 weeks in a row -- and many guilds have -- it's not because they inverted the alphabet.
|
|
|
|
|
|
10/30/07, 5:43 PM
|
#158
|
|
Don Flamenco
|
Long live Champion! For us:
Leotheras 15 kills
15 Champion gloves
Kael'thas 9 kills
11 Champion chests
1 Defender chest. lol?
Vashj 12 kills
12 Champion hats
Karathress was normal, 11 in 16 kills. Void Reaver, lower than expected, just 7 in 16 kills.
|
|
|
|
|
|
10/31/07, 10:00 AM
|
#159
|
|
Co-starring: The Egg
Blood Elf Paladin
Azjol-Nerub (EU)
|
Originally Posted by chadcook1999
Statically it's hard to see a pattern with such a low sample to pull from making it very easy to cry "Tinfoil Hats! Another Blizz conspiracy uncovered!"
I think a better test would be to get on private wow servers and dig into how loot drops are calculated to give a basis for the theory.
|
I'm pretty certain those wouldn't accurately present what happens on a real WoW server; the private servers are reverse engineered based on the things a WoW client expects to receive, and so they wouldn't accurately recreate things which happen purely server side.
That is, mobs on private servers drop loot, and the code to show which loot is on the mob to the client is probably basically the same. But the actual calculation used to determine what each mob drops is going to be different; that's because that part of looting is calculated exclusively server side.
|
|
|
|
|
|
|