But yeah, Mugwump if you want to chat more about something here is my one email mikkou9 ( at ) gmail ( dot ) com 

I thought I had max edicts, this is new for me.
What�s going on, to much Efrags= 

caused by having entities (typically torches) too close to oreven partly inside solid walls. 

Noted. I wouldn't give my e-mail openly over the internet like that but I'll send you a mail. 

Alright, so here's a weird one.

Basically, there's a point (really, a whole vertical plane) in my map that sends you into the void--whether you're "in" the map or not.

It's kind of hard to describe so I uploaded a video:

https://drive.google.com/open?id=0B5ubevjSCiEYZFZlX2VUQzZnN1E

As you can see, if you move away from the blue bridge structure towards the blackness, you pass into the grey void without actually reaching the end of the box--and as I demonstrate later, this happens outside of the map bounds as well. Actually, you're technically taken to the *other* side of the map--as if you'd gone so far in one direction that you looped around to the other (like what happens when you fall through a hole in an unsealed map).

I *don't* think it's because I exceeded normal map size limits (that's what those colored lines are supposed to represent in TrenchBroom, right?). I've already ruled out holes, at least those that BSP can detect, having tracked them all down with pointfiles and removed them. Any ideas? 

That really does look like hitting up against the hard limits of map size, actually. I'm not aware of any coloured lines in TrenchBroom that represent the bounds of the map, either, just the set that extends out from the origin along the various axes. My advice would be to spawn an entity out there and check its "origin" key values, or use the viewpos command to check the player's own coordinates.

If you're not actually outside the map bounds, i'm totally stumped. 

I had this issue when I exceeded the 4000 from origin limit 

That might be it, although those flames are just past 4000 units from origin (e.g. one of them is at -224 4048 460 according to TB).

The colored lines are visible here:
https://drive.google.com/open?id=0B5ubevjSCiEYT1JfRF9SODBjZG8
I thought I read somewhere they extend as far as some (extended) limit but I guess they're just the axes. To be honest, I thought the map size was a bit bigger.

There are bigger maps though, like ORL's Zeangala... how does that work? 

cause it's a super secret area that I doubt many of the ten whole people who will play the map will get to, and they'd fall to their deaths if they jumped from there anyway. :P 

You could Select ALL and drift the entire map's contents a bit away from the boundary limit. 

4096 is the actual limit, not 4000. 

I have been reading ad docs, especially trying to figure out how to make door open in a way.. I can specify origin where door rotates 90 degrees, and probably will just stay open after triggering, because if it spins back after some time "wait", it should notice if it touches players or enemies so it goes back to open..

Noir thmemed map, wooden doors might look stupid if they just moves inside walls. 

Sorry typos.. anyway there is multiple options..
'func_rotate_door' + 'info_rotate' might be things I should use? 

You can use sv_protocol 999 console command in the latest Quakespasm, 0.92.0. That expands the quake boundary limit from +-4096 to +-32678. There's no special compiling tools or commands to use either, just set sv_protocol to 999, restart the map, and you should be golden. 

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.