the clip brush should be part of the world, not the illusionary.
if the clip brushes are part of the illusionary then it'll be non-solid, just like the rest of the func_illusionary geometry.
(they could also be part of a separate func_wall if you want to killtarget it to make it passable later, but you will may need to fiddle about with it in order to get the qbsp to accept it, depending on the qbsp) 

Clip textures on func_illusionary tends to crash my compilers 

It was simple actually, have the func_illusionary brush be surrounded from both sides by 1 unit-thick clip brushes.

For that whole rotating brushes thing, can I get to know more about it? 

czg's rotation tutorial:
https://tomeofpreach.wordpress.com/quoth/tutorial/rotation-overview/ 

ad_test3s first rotating door (the "vault" door) is a bit trickier to explain, it is actually a func_rotate_train.

But first the normal door we all see everyday, with a vertical and fixed hinge. Build one of those out of as many brushes you want, these all go into an entity called "rotate_object".

Note there is no func_ prefix on this entity, idk who was so crazy to name it w/o this.. :) But the quoth fgd/def has it.

Give it a targetname, lets say rotate_door1 , and a target, lets say rotate_hinge1.

"targetname" "rotate_door1"
"target" "rotate_hinge1"

You must also set the light parameters like "_dirt" and "_minlight" on this one (if you want to).

Now create a "info_rotate", this is a point entity, important is you place it right on the vertical axis i.e when viewed from above or below in the middle of the hingebrush for best looking results.
This one is targeted by the rotate_object.

"targetname" "rotate_hinge1"

Now create a "func_rotate_door", again a point entity placed on the axis.
This one targets the rotate_object

"target" "rotate_door1"

This entity has all the keys for controlling the rotation of your door.

"speed" - the amount of time to open/close the door

"angles x y z" - the total angle the door rotates i.e.0 360 0 is one full turn vertical.

sounds/noise keys depending on the used progs.

"targetname" - last but not least this one must be targeted itself by a button/event of your choice.

Important note, these "doors" have no collision. You'd have to fake this with skip-textured func_doors/func_movewalls.

Try this guide first, vault-doors later (those are easier to fake collision for :))
Hey.. 

 

Build one of those out of as many brushes you want, these all go into an entity called "rotate_object".

Note there is no func_ prefix on this entity, idk who was so crazy to name it w/o this.. :) But the quoth fgd/def has it.

Blame hipnotic! In Quoth we tried to name things with consistency in terms of func_ being solid brush entities, trigger_ being invisible brush entities, info_ being invisible point entities, etc. Most of the exceptions to the rule are things that would be too confusing to rename now, like trigger_counter. Unfortunately rotate_object is a name hard-coded into the compile process and there's no way to change it. 

I don't get the part with the func_move_walls. I know they're part on making a collision mask, but for two side-to-side rotating doors how does it work?
Do I just make tiny cube brushes that form a quarter-circle from the closed position of the door to the theorized opened one? Or do I just make a single brush that I cut in an arc that's suposed to draw out the shape of the movement? 

Correction: CZG's tutorial

The movewalls should be shaped to approximate the size and shape of the visible entity while stationary. The ideas is that because you can't actually rotate solids in Quake, you have these small chunks which slide along a circular path.

It might be better to describe a couple of basic things you might create, and how to movewall them.


A door: cuboids which stretch from the top to the bottom of the door, are square on top, and exactly match the width of the door. In ascii, from above

========= (door)

[ ][ ][ ][ ][ ] (movewalls)


A propeller: cubes along the length of each blade, flattened to the thickness of each propeller. 

After some bits of trial and error regarding rotation angles I came through
http://image.noelshack.com/fichiers/2016/06/1454888677-schlossherr20160208004219-00.jpg

(And here you can see fullbright pixels will be a huge problem) 

TexMex can remove fullbrights. 

Load the wad into TexMex. Double-click a texture. It will open in a "Detailed View" window. Right click on the texture and select "Adjust Brightness", then click "Remove Brites" in the "Brightness Adjust" window. 

 

I hope it works. I'm not sure I ever actually tried it.

I edit textures in an old version of PSP and have a custom quake.pal file where all the fullbrights are replaced with black. I just apply that (using match nearest color) to any texture where I want to get rid of stray fullbrights. 

Some of the reworked pixels where fullbrights, so I had to edit them with Photoshop.
Nevertheless, they're gone now. 

Is there a hack to make explosions made of info_notnull deal zero damage? I need just a visual effect of explosion. 

http://www.celephais.net/board/view_thread.php?id=37116&start=7 

Ogre grenade suits perfectly for this, thanks 

Is it possible to place an animated texture without animation frames playing (last frame I need) without making it a separate non-animated texture in wad? Like the button that have already been pressed? 

ignore the previous post 

 

Just use its switched-off frames as texture for your button, wall etc. 

so the +a*.* frame? 

But I read it as if PuLSaR is saying use one of the animation frames, not the 'off' (+a) frame.

I know that func_wall has some little known hackery inside that works with this, but can't remember what it is.

And now, reading it again, it seems that it is just setting the +a frame yeah. 

I just needed the +a frame, silly me