Slashdot Mirror
Bethesda Investigates Shivering Isles Bug
Gamespot reports on a glitch in the recently-released Shivering Isles expansion to Elder Scrolls IV: Oblivion. It's unclear at this time if the Xbox 360 version of the title also has it, but on the PC side of things a game-breaking snafu can arise after 50-120 hours of gameplay post-Isles installation. "The bug apparently starts affecting the game as soon as the expansion pack is installed for the PC version of Shivering Isles. The problem arises because the game generates a huge number of identification numbers internally for objects, and once the allotted space for those numbers becomes exhausted, newly created objects will disappear from the gameworld and the game could simply crash ... It appears that the more frames per second the game runs at, the faster that space of identification numbers fills up."
This happens in World of Warcraft: The Burning Crusade as well. It occurs when a character casts too many beneficial spells in a short period of time. Blizzard is reporting that it is a Buffer overload.
"By the time they had diminished from 50 to 8, the other dwarves began to suspect 'Hungry.'" -Gary Larson
Hey, this kinda reminds me of the time Slashdot hit the comment limit in its database.
Reviewing just the first hour of video games.
I'm armpit-deep in Oblivion these days, and Niner bought me the SI expansion for my birthday.
When I saw the announcement about the bug, I tested it for myself, and it is very real. Happily, there is a community-produced script patch that disables the problem.
Interestingly, the root cause of the problem isn't so much the broken scripts that consume ObjectIDs, but rather that some intelligence was baked into the ID instead of it being just a raw counter.
The ObjectID is prefixed with "FF" and the remaining bytes are the counter values. When the counter hits FFFFFFFF it rolls over, and the "FF" prefix no longer applies. *That* is the problem - the game code no longer recognizes the ObjectID as valid without the FF prefix.
It seems that the code that generates the next ObjectID is smart enough to skip IDs that have been assigned; hacks that reset the ObjectID counter back to FF000000 appear to do the right thing. If the counter had no prefix, the bug wouldn't affect the game - the counter would roll over, but any objects that had been around since the start of the game (with low ObjectIDs) would be properly skipped and all would be well. Unless you managed to have FFFFFFFF objects extant in the game world, there'd never be a way to run out.
Happily, my counter was at FF4xxxxx so my game save is OK. I feel for the guys who discovered they were at FFFxxxxx.
DG
Want to learn about race cars? Read my Book
It is caused by the exaustion of IDs in the low 24 bits of the ID. The field was intended to roll over back to 0 since the majority of the IDs are only needed temporarily. Unfortunatly they bugged the implementation, failing to preserve the 8 high bits (normally FF) in all rollover cases thus generating much internal confusion.
The problem was exascerbated by the new guard scripts which really burned through the IDs fast.