a func_wall with only skip textures on it will be totally invisible (and not do nasty things to pvs+csg+etc), and yet still support monsters walking over it just fine.

however, your shots will also hit it instead of passing straight through, which is how come monsters will be willing to walk over it.
so pick your poison. 

The walkway is made of four bars. At first they are not extended. Later they move to the position here (lower right).

http://quaketastic.com/files/screen_shots/Wish13_e.jpg

Sorry for the poor angle, but the screenshot is one I uploaded a while back.

Monsters do not move on to the walkway because of the gaps. I've used monsters that have ranged attacks, but it would be better if they would use the walkway once it extends. A func_wall or skip textured brush won't work because of the need to move. 

Would making a second overlapping func_door that's just a skip-textured box work? 

Skip textures work on doors? That was what I was asking. I didn't know, never use them.

Special compiler needed? I use txqbsp_xt

I was thinking to try the tyrutils as long as marksurfaces don't go up, but I would have to relight a lot of the map because there are parts that look a lot different from MH/BJ light. I think it's the lack of "soft distance". 

There is already a clip brush inside the bars to smooth out the "bumpiness" to the player, changing that to a separate door would be no problem. 

I'm pretty sure skip on doors will work fine with txqbsp-xt or tyrutils (I tested my version, probably the original works too). As spike said it'll block gunshots but otherwise it should be ideal. 

Does it really need to be func_wall only, when using skip textures? Just wondering because func_train is used in many places, and if ever decide make a floor about irons bars then there will be problems if monsters can't move over it. 

In general, for anything non moving I would use a func_wall. For something that moves along one axis only, func_door. If a complex path is needed, multiple directions, continuous loop, etc., that is what func_train is for. I don't actually use func_plat any more, too limited. 

By the way.. because I'm still discovering new keys and things... does func_door has key "angles" like in buttons? 

Yes, but like buttons, only in the horizontal plane, and from what I've seen it can get confusing if you use non-orthogonal directions.

Doors make great lifts and extending walk ways, you just have to learn how to control them by setting the "lip" value. 

So it is better than func_plat in many cases?

I tried using now skip, I think I asked about whether it makes same effect when using invisible textures.. and it makes the same weird effect, it kind of don't want to draw some faces:
https://drive.google.com/file/d/0BwxYkKdSD855eDdtQU1JdEpPSE0/view?usp=sharing 

From Quake Wiki...

"Skip is a nonstandard special texture, used by modern QBSP compilers, but does not have any function in the stock Quake compilers as released by ID Software. Skip is a texture much like clip in that it is invisible, but skip's use is to remove an entire face from ever rendering, and a brush does not have to be fully textured in skip. The removed face remains solid, and will block player and monster movement, as well as block weapon fire. In general, this is of little use on solid geometery, as Quake performs backside culling, but can be used on brush entities or "hacks" like windows to hide unwanted faces. A "*waterskip" texture exists as well, for use with liquid brushes."

So you use it only on those faces of a brush that you want to remove, not on a whole brush. 

I don't want to remove anything, I only want to let monsters move surfaces. 

Thanks for who mentioned about func_wall + alpha.. it worked! 

Looking at your screenshot I think you have a grid, and that you want monsters to be able to cross the grid?

If so, then you cannot cover the whole grid with one skip brush. You need to fill each of the spaces in the grid with a brush of exactly the same size as the gap, and with the same texture as the grid, then retexture just the top and bottom faces of that new brush with the skip texture.

After compiling, the faces with the skip texture will be solid but invisible, meaning that you can see what is below the grid, and all the other faces of that brush will remain, thereby making the grid look complete. Monsters will then be able to cross the grid.

I used that technique in FMB-BDG2 where I had a grid with some holes big enough for the player to fall through if he was not careful, and skip textures everywhere else so that the monster could chase the player across the grid and maybe panic the player into falling through one of the bigger holes (those bigger holes did not have skip textures in them). 

The problem in the screenshot is that the skip brush is world geometry. This is what I explained above. The skip brush needs to be a brush entity, ideally func_wall (NOT func_illusionary). Alpha brush is a bad choice, because when playing the level with a port that doesn't support alpha, that brush will be fully visible. 

When world brushes touch, regardless of texture, the touching faces are removed. If top and bottom face are skip-invisible, then you can see through the sides where the brushes touch. So in order for this to work, there must be no touching (similar to the "DP" issue), for example if the skip brush is shaped like an upside down pyramid or at least has slanted sides to make sure only the floor surface matches up with the adjacent floor. However, this is problematic as well, since it may lead to the parts below or behind the skip brush to be visblocked and therefore create a visual anomaly, too. 

"Alpha brush is a bad choice, because when playing the level with a port that doesn't support alpha, that brush will be fully visible."

Didn't some just said Skip is not supported as well in some ports.. or am I blind. It seems there is couple ways to solve this problem. That I don't know what is the right way to do it anymore.

You can recommend using specific engines for your maps.. if it comes to that mentality "it should be working on every possible quake engine" you're just making your life unnecessary hard?

I just tried func_wall + alpha and it gave the best result when using Quakespasm. So if that is the wrong way to do it, then shall be it - if it works on this specific engine.. 

Do AD's fence textures not work in darkplaces? Or have I borked something somewhere? That screenshot is 100% less pink in QS.

Actually, should I care about DP at all? I only installed it tonight to see how my map would look (basically the same save for the broken plants) and experience the horror that is excessive particles and blood decals. Does anyone care if my map's broken in it? 

Sorry about that; my memory is shot!

Negke is right. Ignore my comment about exact size and retexturing, that was the actual problem I had, not the solution. The solution was a standard brush 1 unit away from grid brushes (still needing one skip brush for each gap in the grid)

I think this shows what I am meaning:-

http://imgur.com/a/PzDvZ

You can see the skip brushes in place, and the larger holes that the player could fall through, but monsters would not.

This screenshot is from the original map that was compiled and worked as intended. 

Actually, should I care about DP at all?

No. 

Like this? : https://drive.google.com/file/d/0BwxYkKdSD855amlBS1FCSWVlaHc/view?usp=sharing

Is the offsetting by 1 pixel only way to make it not hide faces from those iron bars? 

Let me get this straight. Skip is a compiler thing, so if the faces are removed does the engine port used to play the map make any difference?

Alpha does require engine support, if not supported by the engine port used to play the map the model will appear as normal and not transparent? 

Yes, that looks right. And yes, the 1 unit gap stops the grid's faces from being removed whilst allowing monsters to cross the grid.

In my map, Ogres, Death Knights and Shamblers could chase the player across the grid. 

should I care about DP at all?

It depends whether you intend to allow players to play your map without forcing them to put their engine of choice away or restrict it to some kind of elitist club. Your call but IMHO mappers shouldn't make their work dependent of one engine.