annoying leak during BSP for ase conversion

(rgoer) #1

I’ve got a .map file… it’s just some detail–that is, non-structural (is this the problem? It didn’t work when the brushwork was structural either)–brushwork enclosed in a structural caulk-box. There are no entities, whatsoever. When I BSP this .map with -meta and -patchmeta, I get a leak–but there aren’t any entities… what else can cause a leak? The blocksize is 1024 (default?), and the brushwork/caulk-box is nowhere near that size… could that be a problem?

edit: I tried _blocksize values of 128 and 2048 to see if it had anything to do with the leak (I’m really clueless, yeah?), but the thing still leaks so I’m back to square one.

(ydnar) #2

Put a player start entity somewhere in the box.

(rgoer) #3

Thanks. I’ve done that now, and the .map compiles just dandily.

But, alas, this just wouldn’t be Thursday if things starting working fine all of the sudden. Now, when I compile the .bsp file with -convert, I get a non-working .ase file. It seems to be writing “house.ase” just fine (it ends up at etmain/maps/house.ase and it appears ok upon inspection in Vi). However, when I try and add this model to a .map file in Radiant (version 1.3.11 with ET support), I get this error:

vfsExtractRelativePath: C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/house.ase
cleaned path: c:/program files/wolfenstein - enemy territory/etmain/maps/house.ase
Matching against c:/program files/wolfenstein - enemy territory//etmain
vfsExtractRelativePath: failed
trying with a short version
vfsExtractRelativePath: C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/house.ase
cleaned path: c:/progra~1/wolfen~1/etmain/maps/house.ase
Matching against c:/program files/wolfenstein - enemy territory//etmain
vfsExtractRelativePath: failed
WARNING: could not extract the relative path, using full path instead
ERROR: PicoLoadModel: Failed loading model C

Thanks for all the help, y, and sorry I’m such a pain in the ass… oops, “all around great guy,” I meant to say.

By the way, this shows up in the .ase code:

*MATERIAL	2	{
		*MATERIAL_NAME	"noshader"
		*MATERIAL_CLASS	"Standard"
		*MATERIAL_DIFFUSE	1.000000	1.000000	1.000000
		*MATERIAL_SHADING Phong
		*MAP_DIFFUSE	{
			*MAP_NAME	"noshader"
			*MAP_CLASS	"Bitmap"
			*MAP_SUBNO	1
			*MAP_AMOUNT	1.0
			*MAP_TYPE	Screen
			*BITMAP	"..
oshader.tga"
			*BITMAP_FILTER	Pyramidal
		}
	}

Should it? There is at least some kind of texture applied to every face in that .bsp (there’s a lot of caulk, but common/caulk shows up in the .ase file already–it’s the first one defined in the materials section)… there isn’t any “notex” to be found :^\

(ydnar) #4

The first shader in a BSP file is “noshader.” The shaders get mapped 1:1 to ASE materials.

y

(rgoer) #5

Sorry for all the fuss–it was a stupid PEBKAC issue. Forgot to check the path as entered in the “model” key of the misc_model entity. Lo and behold, it was borked.