Discovery transcript: GE-BUG-012
Discovery of GE-BUG-012
Related bug: Classic bug: Planet record-limit failure
Source: Discord #dev discussion, October 7–21, 2025. Times are as displayed in the supplied screenshots; their time zone is not established.
Participants in the excerpts: Oliver, Madam Airlock, manicpoporg, Hacker, Mlacko, and archwiki.
Editorial note: These are selected, chronological excerpts from 16 overlapping screenshots, not a complete export of the channel. Game output and images are described in square brackets rather than transcribed in full. Original spelling and wording of quoted chat messages are retained. The bug article gives the verified technical explanation; the discussion below records how that explanation developed.
October 7: Phantom planets reported
[Oliver shared scans in which several numbered planets returned nearly identical bearings and distances.]
- 8
- 57 PM — Oliver
- Weird!
- 8
- 57 PM — manicpoporg
- wait what
- 8
- 57 PM — Oliver
- Is that because the database is full?
- 8
- 58 PM — Madam Airlock
- maybe? they are spread through the sector, but they weirdly all have the same bearing
- 8
- 58 PM — manicpoporg
- that's happening now?
[Madam Airlock shared a sector scan plotting four planets at different positions, followed by individual scans that reported the same bearing and distance for all four. One planet scan later showed a distance of 2,516,980 units.]
- 8
- 59 PM — Madam Airlock
- yep
- 8
- 59 PM — Madam Airlock
- happening now i'll slow down and see if i can orbit one and claim it lol... nope
- 9
- 12 PM — manicpoporg
- ok very interesting. i'll have to see what causes that behavior and how to stop it, i have some ideas but yes i assume the db is full and it has some trouble with that
- 9
- 43 PM — manicpoporg
- numrecs/cntrbtv is the amount of records total (sectors, planets, wormholes) and max_plrec is 65,534 by default so when the db is full it just never writes sectors. but obviously not everything knows how to deal with that
- 9
- 52 PM — Oliver
- which is why those planets disappeared?
- 9
- 52 PM — manicpoporg
- i don't think they were planets i think it was garbage data
- 9
- 53 PM — manicpoporg
- something with the scan routine probably expects something to be there that isn't i doubt any significant testing was done for what happens when you have a full db i can turn down maxplrec to near nothing on my test build and see if i can figure out what's happening
October 8–14: Checking the database limit
- October 8, 8
- 48 AM — manicpoporg
- can you tell me what the size of the mbmgeplt.dat is?
- October 8, 11
- 16 AM — Oliver
- Is the DB size limitation a configuration setting or is there a technical limitation ?
- October 8, 11
- 18 AM — manicpoporg
- it's the value of maxplrec in mbmgemsg there may be a technical limitation too, i don't know
- October 9, 9
- 49 AM — Hacker
- MBMGEPLT.DAT 35716096 10/09/25 11:44a
- October 9, 9
- 49 AM — manicpoporg
- 34mb. it's only supposed to grow to 32mb of records but there is probably some additional stuff in there so i need to figure out exactly what the behavior is when it gets full
[On October 13, archwiki shared photographs showing the same implausibly distant planet-scan results. Oliver reported that no new planets were being saved and that a scouting script had filled the database. On October 14, manicpoporg shared logs showing repeated Max Sect Reached notices alongside unexpected missing-planet and update failures.]
- October 14, 10
- 02 AM — manicpoporg
- the max sect reached errors are what you should expect, but these other two errors shouldn't happen
- October 14, 10
- 19 AM — manicpoporg
- i imagine something is pulling garbage data in lieu of the non-existent sector to those routines i say: embrace the nothingness
October 16: Cause identified and first fix
- 10
- 29 AM — manicpoporg
- so when the db is full, the sector creation still runs, it still decides if the sector has planets and how many, etc so when the db is full and you go to a new sector and nothing's there, it's because the routine ran and decided this would be any empty sector but if it decides this sector should have planets, that's when you start seeing the "phantom planets" there's no way to actually save the planets, so you get planets that were previously in memory they are real planets from the db from other actual saved sectors
- 1
- 11 PM — Oliver
- That would explain the crazy distance we see?
- 3
- 31 PM — manicpoporg
- yeah, i actually got it to show zygor once
[The first ge-next fix was committed as 442482f: avoid generating a new ordinary sector when the database is already at MAXPLREC.]
- 4
- 10 PM — manicpoporg
- ok, i think that's all we need if the number of records in the planet db is MAXPLREC or higher, it "creates" an empty sector in memory but doesn't save it
- 4
- 47 PM — manicpoporg
- that was why, when you scanned a planet with sca pl, you'd always get the same planet (env/res, bearing, distance) BUT if you did scan se, you'd see planets in different places — those are where the planets would have been if the sector had been able to be saved
October 17–21: Partial sectors and final fix
- October 17, 11
- 49 AM — manicpoporg
- this needs a bit more work yesterday's commit will keep the game from trying to create new sectors if the db is full, but it occurred to me last night, what if the db is nearly full and a sector with planets/wormholes is created and the sector fits inside the db, but then planets/wormholes don't? this happens
[Test output showed a four-object sector whose fourth planet record was absent, and wormholes whose destination sectors could not be created.]
- October 17, 11
- 57 AM — manicpoporg
- planet 3 exists, but planet 4 does not, so the log shows garbage data and the scanned planet just shows as the last planet in memory, planet 3
- October 17, 12
- 02 PM — manicpoporg
- oh, the planet 4 is not garbage data, it's an error in the logging command... fixed
[The next screenshot shows one scan returning “There is no such planet in this sector,” followed later by a scan of the same missing slot displaying Zygor after the planet update routine had loaded it into shared memory.]
- October 21, 8
- 22 PM — manicpoporg
- ok, that's the most elegant fix. instead of a hard cap of records on the db, allow the sector (or wormhole dest sector) in the process of being created to finish, even if we slightly exceed db "limit"
[The corresponding follow-up commit was 6fd9c79. Later defensive lookup checks are described in the bug article.]
See also
Home · Play · Reference · Versions & history · Sysop · Development · Classic bugs