I'm an idiot. 

I noticed something weird with floating ammo boxes while testing some related things. Below is a minimal map that has a single box room and two func_walls with ammo on top of each. Both func_walls disappear if you step into the other end of the room, and the ammo remains floating in the air.

When compiling the map with tyrutils and playing it on QuakeSpasm 0.85.9 I notice that I can pick up one of the ammo boxes without jumping, but not the other. However, they are both supposed to be at the same height.

Can you explain that? Does the proximity to the wall or the torch have something to do with this?

http://pastebin.com/fXUzXRMu

Compile it, play it, and just run around under the boxes without jumping. What happens?

Another question: What is the canonical way to create an item that falls from above after some event triggers? It's obviously not this, as they just float after killing the func_walls. 

On a func_door that moves sideways, and use another brush to scrap it off. Then it should fall.

Can't remember if it works for ammo though. 

They have always been wonky since their centrepoint is on one corner of the ammo item in the .bsp - so engines have applied various fixes to them down the years.

So you'll see different collisions depending on which engine you use. 

That works with ammo falling off a func_train, so I guess it works just the same with a func_door, where that is more appropriate. Thanks. 

removing entities with killtarget does not correctly register the entity is 'in the air' so the engine still believes it is on solid ground.

you can also try 'crushing' an ammo box. that may cause it to fall through the ground, but i'm not sure. 

Well, func_train is useful for dropping several items in a timed fashion. It just pushes each off its perch in turn :) 

"Internal error: didn't allocate enough planes? (NewPlane)"

What mean? 

Is that from Quake? 

 

Yeah, that popped out of QBSP. I was confused and scared. 

Not even aguirRe's readme has anything on that. 

\o/ What do I win? 

http://i.imgur.com/UoFePIp.jpg 

http://disenchant.net/git/?p=tyrutils&a=commitdiff&h=347020879dc46507681fac3d321a4502f0d72bff

if (map.numplanes == map.maxplanes)
- Error_("Internal error: didn't allocate enough planes? (%s)", __func__);
+ Error("Internal error: didn't allocate enough planes? (%s)", __func__); 

Yeah, I figured it was in the source code somewhere ... I just don't know what it means or how to fix it. :) It had something to do with a brush I had added. I guess it was a perfect storm of floating point planes or whatever and death by map.maxplanes cuts. 

I'm bouncing with a map progress on max_surfaces.
Txtqbsp says:

*** WARNING 31: Marksurfaces 33243 exceed normal engine max 32767

So while I'm liminating brushes I see in Quark6.4 the whole level counts 5167 polyhedrons and 30330 faces.

I wondered, are these the same as the 32767 markfaces limit or does it have no account for the Hull 1 and 2 amount and I am missing 2437 poly's? 

are ALL faces that are generated by the polys in your map, even the ones "outside".

These mostly get deleted by qbsp, its pure coincidence
your numbers are nearly equal. 

solved then, different parms. 

Thanks again to Pekka and ericw for the advice and recommendations above. Just wanted to say (just in case in might be useful to someone else) that I got TexMex to run in Wine.

For this I have to thank Luneran again, who initially recommended TexMEx to me over two months ago. Back then I saw "Windows only" and didn't investigate further -- don't know why I didn't think of trying it via Wine until now!

Admittedly I haven't tried doing anything too crazy/complicated, so I cannot vouch for medium/long-term stability, but at least for exporting and importing one texture from one wad into another, it worked like a charm and was very user-friendly/idiot-proof. 

Thanks again to Pekka and ericw for the advice and recommendations above. Just wanted to say (just in case in might be useful to someone else) that I got TexMex to run in Wine.

For this I have to thank Luneran again, who initially recommended TexMEx to me over two months ago. Back then I saw "Windows only" and didn't investigate further -- don't know why I didn't think of trying it via Wine until now!

Admittedly I haven't tried doing anything too crazy/complicated, so I cannot vouch for medium/long-term stability, but at least for exporting and importing one texture from one wad into another, it worked like a charm and was very user-friendly/idiot-proof. 

moer wine! 

some free open source procedural texture creating tool, looks nice (you could also just use blender though): http://neotextureedit.sourceforge.net/ 

i created my aas file and it seems everytime i make a big complex map the aas wont work whether i use radiants aas conversion or the command creation way. i have a map right now that wont pull up in \devmap through quake; only through the radiant program and the aas file wont work 

Okay. So you compile the map and you don't get an aas file at all? Does bspc give you an error? If the map also doesn't load in q3, do you get an error there?