How do I make illusionary brushes in a way, light doesn't go through them? Is there any other way to make brushes you can see, but doesn't collision check. Especially when doing tiny detail in some brick work, it is good to make some of those tiny deals, so player can move smoothly enough, because gameplay is more important. 

I think that's it? maybe also _shadowself 1 and _dirt 1, i'm not sure how necessary/functional they all are. (_dirt is obviousy only if you're using dirtmapping) 

Especially when doing tiny detail in some brick work, it is good to make some of those tiny deals, so player can move smoothly enough, because gameplay is more important.

Probably you know this already, but you can of course do the opposite: instead of using func_illusionaries for the tiny details that stick out, make those parts out of normal brushes -- or better yet, func_detail* -- but then cover the whole structure in a large clip brush (i.e. a brush covered in the "clip" texture"). The same technique works if you have small recesses in a wall that you don't want the player to get caught in.

*I can't explain the exact technical reasons for this myself, but it's been said several times on this forum by experienced mappers that it's best to use func_detail for tiny detail brushes. 

To be honest, I heared them talking about func_detail but couldn't understand what they tried to say actually, because of language barrier.

So func_details don't have mesh/box collider (no collision check) ? 

No, func_detail brushes will function pretty much like regular brushes (so the player can still bump into them and won't tell the difference between func_detail and regular world brushes), except that they optimise the compile process ... or something.

The bit that's relevant to your question is using a clip brush to cover all of your detail work -- so it's doing the opposite of what you suggested:

Instead of removing collision check from e.g. the bricks that stick out, you cover the entire wall (including the bricks that stick out) with an invisible brush that the player cannot move through.

The end effect in both cases is that the player moves along the wall without getting caught; the difference is that if you use tiny func_illusionaries, the player will move "through" the tiny bricks, whereas if you use a clip brush, the player will move past the entire wall, including the tiny bricks.

I just added the part about using func_detail, because it's probably good practice, and if you are using a large clip brush instead of small func_illusionaries, then you can use func_detail for all your small detail brushes. 

Clip > illusionary for detail. Obviously not ALWAYS true, but if there's any risk of a player's camera getting inside a func_illusionary it's not worth taking. It just looks bad, frankly.

As far as I know func_detail is mostly a way of optimising the vis part of building your map. It basically excludes those brushes from a lot of those calculations, which is great since vis tests visibility really thoroughly and things like little bricks sticking out will be included in that test normally, which is both useless and time-consuming.
Vis is often the longest part of compiling a map, so optimising it is a good idea. 

Like this. 

I'm sorry, I'm still confused that did I get the answer for my question.. so what I asked was how to make brushes that player can see, but also can go through. I really don't care whether it is possible to see inside brush, because you can't do anything to remove that side effect.

Maybe it is better if I show what I'm doing on my map, and I'm sure millions of people will say to me "Don't do that, that is the wrong way", and that might be 100% true. But there is no time for my to learn new tricks at the moment, if it seems to slow down my progress.

These couple small parts of wall are at the moment just func_illusionary, because I don't want player to struggle with that doorway.. sure it looks a bit more detailed but basically is just the part of basic hallway after breaking the middle:
https://drive.google.com/file/d/0BwxYkKdSD855X2F2NkFyUkliTmM/view?usp=sharing 

In general, how do you make func_illusionaries solid, so they block light and cast shadows and so on ? 

how to make brushes that player can see, but also can go through.
make them a func_illusionary entity

how do you make func_illusionaries solid, so they block light and cast shadows and so on
add "_shadow" "1" to the func_illusionary

(fyi Pritchard, only one of "_selfshadow" or "_shadow" is meant to be used at a time. I'm not sure what happens if both are set, probably _selfshadow is ignored) 

Ericw, that's interesting to learn! Would you mind elaborating on what the functional differences are between the two flags? Also, since I'm still not sure, does _dirt need to be set if it's enabled in worldspawn? Thanks!

Newhouse, yeah, func illusionary is fine for that. Or, since you're using AD, func_breakable_wall works too. It's specifically designed to appear as part of the rubble when a func_breakable is destroyed. Set its targetname to the same value as target on the breakable, and then you can set properties such as whether it has collision or not. It also has things that support fading out etc. but for your use it's basically the same as having a func_illusionary that spawns when you break something. 

Here's an example of a func_wall (the floating cube with a hole through it thing) with "_selfshadow" "1": http://i.imgur.com/lDQ7vNh.png

If it was just a plain func_wall with no extra keys, the left wall would not cast a shadow on the bottom wall. If "_shadow" "1" were set, you'd also get a shadow cast on the world. 

re: dirt, I think if "_dirt" "1" is set in worldspawn, you don't need to set it on every func.

However, dirt interacts with the use of _shadow/_shadowself on funcs in the same way shadows cast by lights do.
i.e. "_shadow" "1" -> the func will "cast" dirt on to the surrounding world
"_shadowself" "1" -> the func will "cast" dirt on itself, but not on the world.

Btw screwed up in my last post.. the key is called "_shadowself", not "_selfshadow" 

Does _shadow have support for multiple light sources? 

Shadow+Shadowself...did some tests:

_shadow 1 - self shadowing done and func_ casts shadows on the world.

_shadowself 1 - self shadowing and no shadows on the world.

both - same as _shadow 1.

Conclusion: _shadow 1 causes brushes in func_ to be treated as any old normal world brush. _shadowself 1 is only useful for cases where you don't want an object to cast shadows but still want it to shadow the brushes within the func_. 

Would someone explain me 'why func_illusionary.. if I put _shadow 1.. Light still goes through it and lights for example one room that should be dark? Because I can't make this working like you do, I have to make actually normal brushes there.. kill them when func_breakable wall is broken and then set active func_illusionary which where first "start off".

If someone knows why simple just using _shadow 1 doesn't make it solid + block light coming through it? 

Which light tool are you using? Only the newest versions of some light tools support _shadow. I'd grab a copy of http://celephais.net/board/view_thread.php?id=61211&start=99999 if you aren't sure. 

I thought I already crabbed that one.. let me see.. yep. I'm using tyrutils-ericw-v0.15.7-win64. 

I mean I grabbed* 

How bad is hitting the vert limit on bsp? I added the bsp2 flag to my compiler like the error said, but should I be concerned about it at all? Also, I'm assuming that all modern engines support bsp2, I mean i'm only about 3/4 done with this map so I can't exactly just trim it down yet. 

I want that player goes to "wait elevator zone" and whether it is up.. it goes down where player is.. but if it is down already - don't do anything ... just let the player go inside elevator.. wait about 1 second, after it goes up. And same other way around.

Pictures would help a lot more to visualize this. 

I want this to happen:

https://drive.google.com/file/d/0BwxYkKdSD855THBfcFRUWmlXd0U/view?usp=sharing 

you could probably use logic gates to make that happen neohouse 

I take it this is for the AD jam?

You could use entity states for multiple triggers. I don't know if this is over thinking it but what comes to mind is something like:

If elevator is up, and the player is down then a trigger by the elevator entrance will trigger a func_door set with toggle. This also turns off the trigger so it will not go back up without the player going inside the elevator.

A trigger located where the elevator space in the down position would then activate the door toggle. A similar trigger would be in the elevator space when in the up position.

Finally, duplicate the first section but on the upper floor.

With this, you can set separate wait values for triggers to get the elevator to act how you want.

I just pulled this out of my bum and your mileage will probably vary. :O