Time-Space Broke in FOnline2, Now Nobody Plays It || EscapeRoom

FOnline2 - the oldest continuously running MMO built on the fan-made FOnline SDK recently reverted the server to an older backup, destroying the player base in the process. What caused the reversion? Time-space had broken.

FOnline2 was using an unsigned integer to store its tick variable - the amount of in-game seconds that had passed since the server had first launched. Events and NPC movement is tied to these ticks. After X amount of ticks, new encounters appear on the world map. After X amount of ticks, NPC Y moves to position Z. After X amount of ticks, an elevator runs out of power.

Integer overflows are responsible for Gandhi infamously being a nuke-happy dictator. And in FOnline2, it completely broke the game.

Because cooldowns for items and player skills are tied to tick, when the integer overflowed, a few things happened:

  • Players became inflicted with every possible ailment
  • Players had every possible boost
  • Dungeon elevators were permanently broken, trapping logged-off players in unescapable dungeons
  • In-game farms could never produce
  • In-game resources simply stopped respawning

Server operators reverted to a month-old backup as a stop-gap effort to hold down the fort until the engine developer issued a patch. But in doing so, it shattered the game’s community. Now, less than 8% of their playerbase remains.

One wonders what interesting ways the upcoming Fallout 76 will break. Regardless of engine, regardless of platform, these easily avoided bugs continue to pop up. Because gaming, gaming never changes.

7 Likes

The Y2K bug struck 18 years late, causing the apocalypse that ended the post-apocalypse?

That could make an interesting cyberpunk-meets-post-apocalypse apocalypse story.

4 Likes

Give it 20 years.

3 Likes

I’d say 20 years to have an apocalypse, recover from it, and have another is a short timespan, but given the last 20 years or so…

More seriously, this is why I make a strong argument that every date/datetime in systems that I work on must be using ISO-8601 if at all possible and totally avoid timezones and DST if at all possible. There’s a strong tradition of using Unix timestamps because they’re so simple and convenient, but there are so many ways that they can fail (birthdates before 1970, due dates after 2038, odd cases where timezones and daylight savings time offsets get applied wrong). It’s one of the few coding-related things that I have really strong opinions about. (due to having lost so much time to debugging datetime-related problems)

3 Likes