Jump to content

Discovery transcript: GE-BUG-012

From Galactic Empire wiki

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

Retrieved from "https://manicpop.org/gewiki/index.php?title=Discovery_transcript:_GE-BUG-012&oldid=1478"