map compiling

[y2keeth]

is it supposed to work in this? it starts up like it going to run but never finishes
the ones I did build was from stock q4 editors console but some wont build for some reason
qconsole.log

[themuffinator]

Thanks for the detailed log — this was an openQ4 compiler bug, not a problem with your map.

I reproduced the leak with the untouched official game/hangar1.map and compared openQ4's output with the retail Quake 4 compiler. openQ4 was leaving 442 editable func_group containers as entities instead of folding their brushes into the world. That dropped grouped geometry and caused the false leak at target_lock_1.

This is fixed in PR #140, now merged. The corrected compiler matches the retail totals exactly: 7,632 world brushes, 6,739 world trisurfs, 8,217 patches, and 1,415 entities, and it finishes without a leak.

Please update to a build containing the fix and rerun dmap game/hangar1.map; keep the original .map, as no map edit is needed. If it still fails, please attach the new log and .lin file and I'll take another look.

[y2keeth]

great

[y2keeth]

"Please update to a build containing the fix" how do i do that?

[themuffinator]

New build should be out soon pending some final tests and refinements.

[y2keeth]

oh ok I thought is there some nightly build thing i dont know about lol

[y2keeth]

must have failed the tests I guess bummer

[y2keeth]

tried openQ4 0.13.0 to build hanger 1 and 2 maps froze up
qconsole.log

here are the maps
hanger.zip

[y2keeth]

tried the official release waited longer this time and it ran but failed the proc
qconsole.log

[themuffinator]

Sorry � your last message here went unanswered, and it should not have. You posted an actual repro (the hanger maps plus a console log) and that deserves a proper look rather than sitting in a closed thread.

A compile that "starts up like it is going to run but never finishes" is worth tracking as a bug, so could you open it as an issue rather than a discussion? That way it gets a number, a label and does not get lost again. When you do, the things that would let me reproduce it are:

1. Which command � dmap hanger from the in-game console, the standalone tool, or the stock Quake 4 editor's console? These are not all the same code path for us.
2. Where it stops. The last few lines the console printed before it stalled matter more than the whole log � the stages are named, so the last one named tells me which phase is hanging.
3. How long you waited. Some phases on a complex map are genuinely slow rather than hung, and BSP/portalisation on a map with a lot of detail brushes can look frozen for minutes.
4. The .map file, which you already attached � please attach it to the issue too so it travels with the report.
5. Whether both hanger maps do it, or only one.

One thing worth trying first, because it is quick and it splits the problem in half: run the compile with +set developer 1 and see whether it stalls in dmap itself or after it, in the AAS build. Those are separate tools and separate bugs.

If you would rather not file it, say so here and I will open one from your attachments.

[y2keeth]

Sorry � your last message here went unanswered, and it should not have. You posted an actual repro (the hanger maps plus a console log) and that deserves a proper look rather than sitting in a closed thread.

A compile that "starts up like it is going to run but never finishes" is worth tracking as a bug, so could you open it as an issue rather than a discussion? That way it gets a number, a label and does not get lost again. When you do, the things that would let me reproduce it are:

1. Which command � dmap hanger from the in-game console, the standalone tool, or the stock Quake 4 editor's console? These are not all the same code path for us.
2. Where it stops. The last few lines the console printed before it stalled matter more than the whole log � the stages are named, so the last one named tells me which phase is hanging.
3. How long you waited. Some phases on a complex map are genuinely slow rather than hung, and BSP/portalisation on a map with a lot of detail brushes can look frozen for minutes.
4. The .map file, which you already attached � please attach it to the issue too so it travels with the report.
5. Whether both hanger maps do it, or only one.

One thing worth trying first, because it is quick and it splits the problem in half: run the compile with +set developer 1 and see whether it stalls in dmap itself or after it, in the AAS build. Those are separate tools and separate bugs.

If you would rather not file it, say so here and I will open one from your attachments.

its ok I got it