Thanks ORL! I took Bloughsburgh's advice (thanks!), but that is good to know in case I ever get crazy enough to make a really huge map. (Btw, Cataractnacon/Zeangala is one of my top Quake releases ever! So thanks for that too!) 

Thank you, it makes me happy to hear you enjoyed those maps. Don't be afraid to make some really huge background scenery for your own maps, now that you have the freedom to do so. :) 

Hey guys.

I need a brush entity that will be in the map file, but completely ignored by qbsp. Is there any already?

What about using the skip texture? If I cover a brush with "skip" completely, none of its planes will make it to BSP. But what are the side effects? Any unused remains of data in BSP structure?

Or better put: if I cover a brush with skip texture completely, BSP will be exactly the same as if that brush was never there? 

Skip texture merely skips adding those faces to the visible world model. The brush will syill affect collision, leafs, portals, and brush splitting.

For instance, put a skip wall across a hallway and there will be a line with the hall of mirrors HOM where the brush touches the other walls. Also it will block the player, bullets, line of sight, etc.

Maybe you need func_detail. That makes it such that it ignores that brush for vis leaf generation in qbsp then lumps it in with the world as a normal brush.

Else maybe you need an info_null brush. It would help if you specified your goal. 

I need a brush entity that will be in the map file, but completely ignored by qbsp. Is there any already?

Do you need a brush entity? If you have an entity with no brushes, isn't that a point entity? Why does it need to be a brush entity? 

My goal is to use VMFII / ItEndWithTens' func_instance entity to make most of my level.

I created a modular greybox of the level. Each part will be replaced by a real asset: a corridor section, a junction, a 45 degree curve, etc.

The func_instance entity is a point entity. That would force me to have 80% of my level made of tiny pink boxes in the middle of nowhere.

So, I tried to turn each of my greybox blocks into a func_entity, to be replaced by the "production" corresponding prefabs. I changed func_entity's class from @PointClass to @SolidClass, but the code then positions the prefab at (0, 0, 0). I believe it's due to the absence of "origin" property in brush entities. I then tried to add an "origin" property by hand, but JackHammer keeps renaming it to origin#1, origin#2, ... seems that there is a hidden "origin" property on brush entities that I'm not allowed to manipulate.

So, I was considering a workaround: what if my greybox assets were some "func_skip" to stay in the source .MAP as a visual reference, but to be skipped by qbsp? I would use this func_skip along with func_instance.

This is, obviously, not the cleaner solution. If someone has any other idea...

Looks like func_instance was meant to be used for specific assets in a level, not most of its geometry. But that would be very handy. 

For example if I have a lot same kind of things like.. specific statues/pillars etc. , it would be so easy to just modify one and all others updates themselves at the same time. But I assume that is editor specific feature then.. There is already layers.. even groups in TB, but haven't figured out how much things you can do with them.. Are you using J.A.C.K? 

The Quake engine just isn't designed around this kind of map development. You would have a lot of trouble lighting, vising and in general would struggle with actually making a map in such a way.
Modern game engines can do a lot more "dynamic" computation at runtime, which is why they can use such techniques to build their levels from sets of prefab'd assets, and on top of that their compilers will work with that in mind as well and operate as if the objects were actually in place.

Besides, I can't see a good level coming out of this technique. Unless you build a unique prefab for every part of your level (which is the same as just building it the normal way) you will end up with a bland creation that looks copy-pasted and repetitive...
What NewHouse is talking about with easily duplicating detailed brushwork for small parts of an area is fine, but due to the technical issues I raised above is best done using something like TrenchBroom's group functionality or by turning all relevant brushes into some kind of func_ that can be selected all at once. 

No guys, I'm using func_instance, developed for Half Life and modified by our buddy ItEndsWithTens here. It's a .map preprocessing, before compiling. It has the needed features, works great, it's tried and true.

Pritchard, it's all a matter of balance. I can compose a unique room out of prefab chunks, use a corridor section multiple times with different lighting, etc, the way it's done with modern engines. 

Hmm... I see. I still don't think it's a good idea, but it's really up to you and if done well it can come close to rivalling entirely hand-made maps.

Sadly i'm not sure how you could avoid the pink boxes issue, you might just have to live with it. I think that there would need to be significant changes to how entities and brushes work in Quake to make it possible to replace brushes like that, especially if the current pre-processor isn't meant to do that. 

I worry that you might be trying to solve the problem in the wrong place. If you've having trouble in the editor seeing what a func_instance represents, perhaps that's something that the editor should provide support for.

Having said that, the .map file is a pretty straight-forward text format. So I'd imagine it would be possible to create a script in e.g. Python which removes the brushes from func_instance entities, and run it prior to qbsp. This might be a better solution for the specific problem at hand than a modification to qbsp itself. 

Yes, it is.

And yes, that's what I'll end up trying to do, considering I don't know and don't care to know about C#. Python seems the right choice.

I just e-mailed Rob (aka ItEndWithTens) about his func_instance entity. More info and more brains on it doesn't hurt. 

The only place I've extensively used instances for major portions of a map is in Half-Life 2, where Hammer supports the display of instance contents in the editor (even though you need an external utility to compile the maps, since the singleplayer HL2 compilers don't support the entity). Building an entire map out of them when all you can see is little pink boxes is beyond my level of patience. :)

Support for instances would need to be added to editors for the idea to really work well. I know Xaerox has mentioned a passing interest in adding support to Jack for instances, "adding .map as another model format" or something to that effect, but I don't imagine it's a priority for him, or anyone else. Also, as Pritchard has said, you don't want to end up with that "snapped together from prefab 128-unit cubes" look so many games have; instances are useful for all sorts of things, but I wouldn't personally recommend making the whole map out of modular sections.

Nonetheless, I'm not looking to force a mapping philosophy on users by way of the tool, so I suppose I could add support for something like what you're describing. For example, and I'm just brainstorming here, maybe users could specify an entity type on the command line they'd like removed from their top-level map. Tie your placeholder geometry to a custom entity in your editor, say "func_greybox" for argument's sake, then run Quinstance with your usual parameters plus --remove_entity func_greybox and simply have it kept out of the final, collapsed .map file.

I need to get a couple of bug fixes released anyway, I could take a look at adding this at the same time. I'll give it a shot myself, but does this sound like an approach you'd find useful? 

Whether you'll find it useful or not is a moot point, as I've just finished adding an entity removal option. :D I'll update the actual Quinstance thread later on, but for now the release is available for everyone to play with: Quinstance 0.3.0

Please do let me know how many things are horribly broken! 

Yes, very useful. I was getting ready to implement a new tool, but that's awesome, gonna try it right away.

Thanks, man. 

My func_greybox instances were removed, but there is a problem. This is how the prefab is supposed to look, but when I place func_instance like this it appears like this

Looks like intersection between the func_instance and another func_ is f..king the whole thing. 

- of course there is one. I positioned func_instance 32 units under the func_greybox and lifted the prefab 32 units in its .map

Intersection avoided, everything works. Bug reported. :) 

Damn it, that's disappointing. Would you be willing to send me the files so I could take a look? 

Just sent you. 

Turns out I was screwing up. It works fine. Thanks, Tens. 

You're welcome, any time! As I mentioned in my email to Adib, the test map he sent along revealed by way of no harm another bug, unrelated to the issue at hand, so I'm throwing together version 0.3.1 for release sometime today. When it's done I'll go update my own thread, if anyone's interested. 

Out of pure curiosity, what was the screw-up? 

I used the -r switch on a test map but wasn't using on the real map. Greybox asset and production asset were clipping each other. 

Something weird. If I travel in one direction inside my map, at some point everything disappear and I'm on the other end of the map's working area in JACK. I mean, outside the level, looking at the level from a distance, as if I'm teleported to zero or something.

Like I'm blowing a limit and being teleported around to the other side.

I already tried to use Arcane Dimensions settings (if it works for Swampy, gonna work for my level):

-heapsize 256000 -zone 4096

and even tried to increase zone to 8192. No luck.

Does anybody know what's happening?