Also, you can't put only clip textured brushes into a bmodel entity. You need at least one brush that is not clip. Also, the clip brushes will only be solid in the mins/maxs of the visible brushes, so you'd actually need to have two brushes at the opposite extremes of all your clip brushes. 

clip brushes actually reduce clipnodes (in many cases), and have no effect on vis or r_speeds, so you're only making things worse by putting them into a func_wall. 

Thanks for advice.

I thought if normal brushes in func_wall overide vistime, then why clipbrushes not.

My last level4 vis is 23h15. I was looking for ways to minimize this, but as it is such a
cramped map I don't think it will work. 

Trigger is made ​​from info_notnull has turned a unique. He responds to any entity. Such as boxes of ammunition and fireball :) 

For some reason all my teleported entities get a wrong angle in their target path in game.
I thought the path_corner would get its angle for showing direction of the entity in game.

I tried the teleporter angle which should be off.
I tried the entity in the teleporter.

They all come teleported in on a wrong angle. 

is this with a mod? 

No, it just happened after some last addons in my map.
Square hide out for monster teleporting in game.
I placed about 10, deleted the angle in func_teleport, made a path_corner to teleport to and gave this the angle I wanted the entity to look at.
They all go right.

Then I added another ten, and to my surprise they all have the angle 0, no matter what angle I give the path_corner.

Then I thought, no also delete the arg "angel" in the func_trigger complete but no matter.
The last 10 decided to go off angle.

I'm chequing if I forgot one path_corner giving an angle, but it looks fairly strange. 

if you are using path_corners as the target of teleport triggers, you have to do some extra work because the info_teleport_destination entity does this stuff automatically.

Instead of setting angle, you have to set mangle to a vector with y being the angle you want to be facing.

So if you wanted angle to be 90, you must set mangle to '0 90 '. 

er... well, should be '0 90 0'. 

Oh me, info_teleport_destination.
Of course, I was so involved in getting waypoints done, that I just forgot and try to use path_corners for teleporting.
In this case it worked, but I'm such a typo. 

Is there a command in any quake engine that will output like a manifest of all precached sounds and models?

I'm thinking something that can be parsed and then used to copy files out of a dev folder into a release folder. 

I'm not sure if i am reading you right, but if you are looking to make sure that you have removed all unnecessary sounds and models from the pak before release, then I use TexPad to search-all-files for "precache" targeting the folder with all the qc modules in. The output is the form of 'boss.qc(271): precache_model ("progs/boss.mdl");' which I then copy/paste into Excel and use a parsing formula to extract the 'progs/boss.mdl' bit i.e. the bits between the quotes, remove duplicates (built-in command), alpha-sort that column, and then go through each folder in turn to remove all unnecessary entries. It sounds long-winded but only takes a few seconds really.

I have no doubt that you could do that all from within TexPad as it has a macro recorder included, and also allows you to run other programs: I use it for all qc work - editing the modules and then running the compilers from within TexPad using the Run command. Aguire put me on to it many years ago. 

Thanks, but what I meant was actually the opposite. An engine command that, after loading the map, displays every precached sound and model in use to the console so I can condump it and parse it so I can cherry pick only sounds and models needed for a specific map for packaging in a pak file. 

Darkplaces has the modellist command which does that. Not sure about other engines. 

fitz has mcache, soundlist and imagelist which I believe do what you want between them 

that's exactly what I was looking for! :) 

hope that kind fit's here.

The problem is, Radiant refuses to load external textures if in q1-mapping mode.

I wrote a own gamepack for a project i joined.
The engine they use utilizes q1 map format and can load both external textures and .wad's.
For mapping i would prefer to use external ones, so i just have to drop them into the folder, and not have to compile a wad everytime i want to try out a new texture fast.

But as soon as you tell the Radiant to do maps in q1 format, he only shows wad's, and refuses to load anything else.

Messed around with the gamepacks .game file trying to figure out how i could workaround this, with no success yet.

Does anybody know a way how to do this?

thx

PS: i'm using Radiant 1.5 

used the q3.game file as template, now i have some sort of hybrid mode.

But the next problem arises -.-'
The engine currently loads textures directly from /textures folder (like it would be a wad),
but ignores subfolder's.
But the Radiant now only loads files from subfolders.

Does anyone see a way to workaround this? 

did we ever figure out what these are? And if so, how can I reduce them? 

Reducing surfaces will also reduce marksurfaces.

Surfaces are every single world polygon you see when you turn on r_drawflat in winquake or fitzquake-based engines.

I think the crash is only when the world model has too many marksurfaces, because the brush entities don't use marksurfaces for rendering (as a result, they won't try to access an index out of bounds.)

So, you could use func_walls to reduce marksurfaces in the world. This won't change the bsp marksurface count, but it should prevent an engine crash. 

Reducing surfaces will also reduce marksurfaces.

So reducing cuts on faces then? Surface/Face that's the same thing right? Or are surfaces collections of coplanar faces or something?

So, you could use func_walls to reduce marksurfaces in the world.

So I would be seeing marksurfaces over 65535? Cause I have many func_walls already and as soon as marksurfaces go over 65k the engine crashes. I figured it was a hard limit, unlike the old 32k limit where you could go over a little without any problems. 

Yeah if you are going over the 65k limit then func walls won't help.

BUT, you could use external bsp files (since they have their own marksurfaces array.)

And yes, faces are the same as surfaces in this case. 

yep, been converting most of the ceilings into external bsps. I would convert some outdoor stuff too, but unfortunately I'm using a lightning flash effect so that's out of the question. :(

Oh well, at least the map is fully playable. It'll just have to be light on details. 

I'm sure you could get set up. Infact RMQ demo3 has SDK, tools etc. 

Someone set him up.