Opening Doom 3 maps with DarkRadiant?

[GuyMcBrofist]

I'm looking for some clarification on how well DarkRadiant supports mapping for Doom 3. I'm trying to open alphalabs1.map from pak000.pk4 and it doesn't seem to be reading it properly, there are some brushes sitting outside the map which don't appear when I open the map with D3Edit (see the attached picture). Unsurprisingly, if I then save the map and try to compile it with dmap in the console it gives me a leaked error.

 

I have the game type set to Doom 3. I guess my question is: Is my DarkRadiant probably configured improperly, or should I not expect everything to go smoothly for these sorts of pathological cases (complicated map, made in a different editor, etc.)?

 

 

 

[greebo]

It's been over a decade since I last tried to open a vanilla map, but it used to work. I don't even have the original game PK4s at hand anymore on this laptop, I'm afraid I can't even test this here.

Is there anything written in the console about missing resources or similar? Are the project settings defined correctly?

[GuyMcBrofist]

1 hour ago, greebo said:

Is there anything written in the console about missing resources or similar?

The only thing that's really suspicious to me is the "MapResource operation failed" message on line 4 here:

Spoiler

Loading map from D:/Games/DOOM 3/base/pak000.pk4 [maps/game/alphalabs1.map]
Opened text file in PAK: maps/game/alphalabs1.map
Using Doom 3 format to load the data.
MapResource operation failed: Could not open file in archive: D:/Games/DOOM 3/base/pak000.pk4
Could not open file in archive: D:/Games/DOOM 3/base/pak000.pk4
map load timer:  1.78 second(s) elapsed
[shaders] Unable to load texture: textures/editor/visportal.tga
[shaders] Unable to load texture: textures/base_wall/steribpanel3.tga
[shaders] Unable to load texture: textures/base_wall/gotgimwall.tga
[shaders] Unable to load texture: textures/base_wall/a_rib_panel_01_fin.tga
[shaders] Unable to load texture: textures/base_trim/steeltrim.tga
[shaders] Unable to load texture: guisurfs/guisurfaceremap.tga
[shaders] Unable to load texture: guisurfs/guisurfaceremap.tga
[shaders] Unable to load texture: guisurfs/guisurfaceremap.tga
[shaders] Unable to load texture: guisurfs/guisurfaceremap.tga
[shaders] Unable to load texture: guisurfs/guisurfaceremap.tga
Material keyword not recognised: 2
Material keyword not recognised: models/mapobjects/healthgui/healthgui_local.tga
Material keyword not recognised: models/mapobjects/healthgui/work/healthgui_hp.lwo
Auto-saving registry to user settings path.
XMLRegistry: Failed to save path /darkradiant/user/ui/colourschemes
--- LoadMapFile ---
maps/game/alphalabs1.map
6938 brushes
5155 patches
2116 entities

 

1 hour ago, greebo said:

Are the project settings defined correctly?

Well, that's part of my question. Under "File->Game/Project Setup..." I have "Game Type" set to "Doom 3" and "Engine Path" set to "D:/Games/DOOM 3/". That's all I've done to configure DarkRadiant, so I'm wondering if there's anything else I should do.

[GuyMcBrofist]

I guess it's worth mentioning that this is happening with v2.14.0.

I just found v3.0.0pre3 and gave that a try. It looks better, those green brushes in the middle of nowhere in my original attached screenshot don't appear. But saving the map and trying to compile it in doom 3 still returns a leak error.

I opened the point file and had a look, and it appears that some brushes in the level are missing. I guess maybe there was some property on these brushes that caused an error, and they were just dropped? See the attached image.

[GuyMcBrofist]

I investigated some more. I opened the map in D3Edit and looked at the trouble spot. I narrowed it down to at least one brush which appears in D3Edit but not in DarkRadiant. I tried updating my post above with a new image but I think I screwed it up, so here's an imgur link:

https://imgur.com/a/Ms4Irv3

You can see in the first image the left camera view is from DarkRadiant showing the missing brush, and the right camera view is D3Edit with the brush selected.

Ok, I'm done for now. This looks like a bug, but if anyone has ideas about what I should try then I'm all ears.

[greebo]

I'll try to check it out some time, I have to find the D3 files first. I'll create a bugtracker entry: https://bugs.thedarkmod.com/view.php?id=5942

[greebo]

Yes, I can confirm the problem in alphalabs1.map, the brush that is missing in this screenshot is primitive 9447. It is a brush with 9 faces, but 3 of these face planes are redundant. Obviously the brushDef3 is still valid for DoomEdit, but DR regards it as degenerate. I'll see what I can do.

Quote

// primitive 9447
{
 brushDef3
 {
  ( 0 0 1 -128 ) ( ( 0.015625 0 -14 ) ( 0 0.0078130001 0.7460148931 ) ) "textures/base_wall/gotcgate" 0 0 0
  ( 0 1 0 -4144 ) ( ( 0.015625 0 -1.5000076294 ) ( 0 0.0078119999 -0.9999359846 ) ) "textures/base_wall/gotcgate" 0 0 0
  ( -1 0 0 -136 ) ( ( 0.015625 0 14 ) ( 0 0.0078130001 -1.0000640154 ) ) "textures/base_wall/gotcgate" 0 0 0
  ( 0 -1 0 4104 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "textures/common/caulk" 0 0 0
  ( 1 0 0 128 ) ( ( 0.015625 0 0 ) ( 0 0.0078125 0 ) ) "textures/base_wall/gotcgate" 0 0 0
  ( 0 0 -1 -128 ) ( ( 0.015625 0 -14 ) ( 0 0.0078130001 -0.7460148931 ) ) "textures/base_wall/gotcgate" 0 0 0
  ( -1 0 0 -136 ) ( ( 0.0104219997 0 43.905040741 ) ( 0 0.0078130001 0.9999360442 ) ) "textures/base_wall/gotcgate2" 0 0 0
  ( 1 0 0 128 ) ( ( 0.015625 0 -14 ) ( 0 0.0078130001 -1.0000640154 ) ) "textures/base_wall/gotcgate" 0 0 0
  ( 0 1 0 -4144 ) ( ( 0.015625 0 -1.5000076294 ) ( 0 0.0078119999 -0.9999359846 ) ) "textures/base_wall/gotcgate" 0 0 0
 }
}

 

[greebo]

When loading that brush, DoomEdit just spits out this in the console and continues:

Quote

Unable to create face winding on brush

The game loader deals with brushes on several occasions, for instance the dmap code will send another warning, removing the second duplicate:

if ( sides[i].planenum == sides[j].planenum ) {
  common->Printf("Entity %i, Brush %i: duplicate plane\n", b->entitynum, b->brushnum);
  // remove the second duplicate
  for ( k = i + 1 ; k < b->numsides ; k++ ) {
    sides[k-1] = sides[k];
  }
  b->numsides--;
  i--;
  break;
}

DarkRadiant's brush BREP code will reject the brush, and the code doing that is very old, I'm pretty sure it has already been in place when we forked GtkRadiant.

I'll try to adjust DarkRadiant to not remove the brush and to treat it the same way as the game code.

[thebigh]

Will these changes have consequences for Dark Mod maps in progress, or old ones that we open up again?

Edited April 18, 2022 by thebigh

[greebo]

No, the changes should and will only affect brushes that have duplicated planes on them, which can happen only when loading legacy maps. DR never created or saved brushes like this.

I didn't even know that this was possible until I encountered this brush in alphalabs. It's also curious that DoomEdit doesn't correct the problematic faces when changing or saving the map (it continues to complain about it when manipulating the brush), so it just preserves the duplicated planes. It's relying on the engine code to weed them out during dmap.

[greebo]

Problem is solved in source, the next pre-release build will include that fix.

[GuyMcBrofist]

Awesome. Thanks a lot. Glad I could help!