You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The crash is identified and a fix is ready in PR #182.
The .proc writer reserves 2,344,661,760 bytes for unshared vertices, exceeding the legacy allocator's limit, then writes through the rejected allocation. The fix shares vertices first; the same surface needs only 21,559 vertices (1,379,776 bytes). It also removes repeated triangle-list scans without changing triangle or matching order.
The attached map now completes the geometry pass in 503 seconds, writes collision and all five navigation files, and exits normally. Native regression checks pass on Windows and with Linux address/undefined-behavior sanitizers; stock-map gameplay also passes.
Keeping this issue open: loading the rebuilt hub2 exposes another limit. Its largest surface has 36,635,340 indexes, exceeding the renderer's 16,777,216-index cap, so it reports R_ParseModel: bad surface counts. There are also MAX_SIL_EDGES warnings. The compiler crash is fixed in the PR, but this map is not yet qualified for gameplay.
Separately, the supplied log rejects hidef2kbc72 because its required openQ4 version is 1; that manifest field needs a valid major.minor.patch value. The compile above used installed stock assets to isolate the compiler problem. Existing source-map geometry warnings are recorded in the PR documentation.
"Separately, the supplied log rejects hidef2kbc72 because its required openQ4 version is 1; that manifest field needs a valid major.minor.patch value. The compile above used installed stock assets to isolate the compiler problem. Existing source-map geometry warnings are recorded in the PR documentation."
@y2keeth Sorry, that part was written for developers. Here it is in plain terms.
Your hidef2kbc72 mod isn't being loaded
Every openQ4 mod folder has a small label file called mod.json. Among other things, it says which version of openQ4 the mod needs. In your mod that label says 1, but openQ4 expects the version written as three numbers with dots, like 0.14.0. Because it can't make sense of 1, it plays it safe and skips the whole mod. So far the game has been running as if the mod wasn't installed.
To fix it:
Open the hidef2kbc72 folder and open mod.json in Notepad.
Find the line "requiredopenQ4Version": "1".
Change the 1 to 0.14.0 (the version shown at the top of your log) and save.
Please don't use 1.0.0. That tells openQ4 the mod needs a version that doesn't exist yet, so it would still be skipped.
"The compile used installed stock assets"
When I rebuilt your map to track down the crash, I used only the original Quake 4 game files, with no mods. That way I could be sure the crash came from openQ4's map builder and not from the mod. The mod had nothing to do with the crash.
"Geometry warnings"
While building your map, the tool also prints some warnings about the map's shapes: a few pieces with doubled-up sides, some paper-thin spots, and some faces pointing the wrong way. These come from the map itself, they were there before, and they didn't cause the crash. I wrote them down in the fix's notes so they aren't forgotten. You don't need to do anything about them right now.
Where things stand
The crash fix has now been added to openQ4, so once you update, your map will build all the way through instead of crashing. It still won't load in-game yet, though: one part of the map is too detailed for the game to handle in a single piece. That's why this issue is staying open.
I've updated the title to describe the remaining failure. The compiler allocation crash was fixed by #182; the rebuilt map's oversized runtime surface and silhouette warnings remain open under CORE-05 in the roadmap.
The next acceptance step is safe geometry partitioning/representation followed by loading, rendering, collision and AI checks on this map. Simply raising the renderer's safety limit is not the planned fix. No new map qualification was performed in this triage.
Activity
themuffinator commentedon Oct 14, 2026
The crash is identified and a fix is ready in PR #182.
The
.procwriter reserves 2,344,661,760 bytes for unshared vertices, exceeding the legacy allocator's limit, then writes through the rejected allocation. The fix shares vertices first; the same surface needs only 21,559 vertices (1,379,776 bytes). It also removes repeated triangle-list scans without changing triangle or matching order.The attached map now completes the geometry pass in 503 seconds, writes collision and all five navigation files, and exits normally. Native regression checks pass on Windows and with Linux address/undefined-behavior sanitizers; stock-map gameplay also passes.
Keeping this issue open: loading the rebuilt
hub2exposes another limit. Its largest surface has 36,635,340 indexes, exceeding the renderer's 16,777,216-index cap, so it reportsR_ParseModel: bad surface counts. There are alsoMAX_SIL_EDGESwarnings. The compiler crash is fixed in the PR, but this map is not yet qualified for gameplay.Separately, the supplied log rejects
hidef2kbc72because its required openQ4 version is1; that manifest field needs a validmajor.minor.patchvalue. The compile above used installed stock assets to isolate the compiler problem. Existing source-map geometry warnings are recorded in the PR documentation.y2keeth commentedon Oct 14, 2026
"Separately, the supplied log rejects hidef2kbc72 because its required openQ4 version is 1; that manifest field needs a valid major.minor.patch value. The compile above used installed stock assets to isolate the compiler problem. Existing source-map geometry warnings are recorded in the PR documentation."
what does this mean?
themuffinator commentedon Oct 15, 2026
@y2keeth Sorry, that part was written for developers. Here it is in plain terms.
Your
hidef2kbc72mod isn't being loadedEvery openQ4 mod folder has a small label file called
mod.json. Among other things, it says which version of openQ4 the mod needs. In your mod that label says1, but openQ4 expects the version written as three numbers with dots, like0.14.0. Because it can't make sense of1, it plays it safe and skips the whole mod. So far the game has been running as if the mod wasn't installed.To fix it:
hidef2kbc72folder and openmod.jsonin Notepad."requiredopenQ4Version": "1".1to0.14.0(the version shown at the top of your log) and save.Please don't use
1.0.0. That tells openQ4 the mod needs a version that doesn't exist yet, so it would still be skipped."The compile used installed stock assets"
When I rebuilt your map to track down the crash, I used only the original Quake 4 game files, with no mods. That way I could be sure the crash came from openQ4's map builder and not from the mod. The mod had nothing to do with the crash.
"Geometry warnings"
While building your map, the tool also prints some warnings about the map's shapes: a few pieces with doubled-up sides, some paper-thin spots, and some faces pointing the wrong way. These come from the map itself, they were there before, and they didn't cause the crash. I wrote them down in the fix's notes so they aren't forgotten. You don't need to do anything about them right now.
Where things stand
The crash fix has now been added to openQ4, so once you update, your map will build all the way through instead of crashing. It still won't load in-game yet, though: one part of the map is too detailed for the game to handle in a single piece. That's why this issue is staying open.
y2keeth commentedon Oct 15, 2026
crazy how many polys round pipes add
thought the mod.json was for mods. I got it now
Fix dmap vertex allocation on heavily split maps
[-]crash when trying to build hub2 map[/-][+]Rebuilt hub2 exceeds runtime surface limits after compiler crash fix[/+]themuffinator commentedon Oct 18, 2026
I've updated the title to describe the remaining failure. The compiler allocation crash was fixed by #182; the rebuilt map's oversized runtime surface and silhouette warnings remain open under CORE-05 in the roadmap.
The next acceptance step is safe geometry partitioning/representation followed by loading, rendering, collision and AI checks on this map. Simply raising the renderer's safety limit is not the planned fix. No new map qualification was performed in this triage.