It is similar to clip, but there are some distinctions. One is that you can use skip on any face, if you had a brush with some faces clip and some not it doesn't work. Another difference is that skip brushes/faces are in fact solid to projectiles, whereas clip are not. This could be helpful for broken ground, as filling the gaps with skip faces will improve monster navigation over the ground. Of course, it also means you can't fire grenades through the holes in the ground, so it's not an ideal fix.

There are some drawbacks compared to clip as well. One is that a clip face blocks visibility for the vis program, even after it is 'removed'. So if you make a window with skip, even though you can see through it, the contents on the other side won't always be rendered once you run vis on the map. Another is that the whole skip brush is compiled just like a normal brush during the bsp stage, unlike clip which is treated specially. So the edges of a skip brush can clip away other faces, which is often undesirable as you can see through the skip. And the skip brushes will split surfaces, count towards clip nodes, and stuff like that.

A good way round some of the limitations of skip is to not use it on the world, but instead on other brush entities. The previous problems with a skip "window" can be avoided if you use a func_wall for the window, and just make all the surfaces skip. Another illustration of where skip might be useful is a complex shaped platform, or moving decoration or something, that is up against a wall. You can make all the backfaces that are never seen against the wall skip, and cut down the amount of rendering required. Plus some of the tricks in the progs thread use it. 

OK, thanks for these precisions... I understand better now the subtility.. :P 

Thanks Preach :) 

A mapper could gain: lower r_speeds by removing non-visible faces, moving ladders, statues (a la rpgsmse4) a one-unit thick trigger on the floor could be inaccessible until a given event by covering it with a a very thing func_wall skip brush. There's more. 

movable ladders can be done with clip brushes, as long as you make sure the func_whatever has visible brushes (hidden in the floor, probably) that extend to the edge of the model's bounding box in all six directions. RPG, you might notice that i fixed the ladder in SM69 this way. P.S. when's SM69 coming out? P.P.S. maybe we should rename it to SM666 or something, if you think we can get it done before the actualy sessions get up to the 600s. Or not. 

You can make solid, moving invisible walls to slap metlslime with.

SM69 filename remains the same; although I'm thinking about changing the map title. 

could someone list all the sm chainmaps? I don't know exactly how many there are. Did sm40 ever get finished? 

See SM40 Contest Results thread: http://www.celephais.net/board/view_thread.php?id=28383

Change the DL link to http://rpg.leveldesign.org/files/mirrors/sm40contest.zip

Too bad my map died and scampie laughed at me. :(

Also, SM82 and SM32 are linked on my site, SM28 is on TEAMShambler, and SM36 is on Underworldfan's review site. 

some one send me some porn 

some one send me some porn 

Is there any info_notnull trickery to make a light_flame killable?

Just wondering :) 

There is, but it's a painful hack invovling modelindexes. Make an entity with the following collection of fields:
model progs/player.mdl
mdl progs/player.mdl
modelindex *theindexofflame2.mdl*
think SUB_regen
nexthink 0.3

It doesn't actually matter what model goes in mdl or model, as long as it's precached already, so player.mdl works well. The important thing is getting *theindexofflame2.mdl* correct. This should be the number of flame2 in the list of models(so you will need a regular flame somewhere to precache it). Every time you add a new bmodel to the map, it will bump the index of flame2 by 1, so best to do it right at the final stage, or you'll be correcting it all the time. Also, be warned that the correct index in regular quake may be wrong in other mods - even things like weapon patches.

You may find the command modellist in darkplaces handy for finding the modelindex, it prints the entire precache list in order to the console. 

someone mentioned a while ago that func_illusionary has special magical properties, and can't be killed like a regular func entity. I was wondering if func_illusionary is treated by the compilers as world or as an entity, and whether or not I can place them freely or have to worry about the precache model index getting full.

I am guessing it is an entity... I think they vanish when you noclip into the world anyway.

Would it be possible to treat func_illusionary ents as world in the compiler and have their polys compile into the world, cast shadows etc, but not split world polys or add to the clip hull? Would this be problematic? 

A func_illusionary is a static entity. This means it does use a model slot up, and it is added as an entity. However, it then gets turned into a static entity, which means it takes one of the static entity slots, rather than the regular entity slots. There aren't as many static entities available, 128 I believe. But there's also less competition for them, as you can't modify a static entity once it's made static - meaning you can't kill them. The model precache however works as normal, it still takes up one slot per model from the same pool as regular entities.

As for the modification for a compiler, I'm not really sure if it's doable. Which isn't to write it off - the compiler aguirRe made that makes the clipping hulls visible instead of the regular surface means you can have drawn faces that differ from the map walls. On the other hand, I'd guess that just making them non solid wouldn't be enough to stop them splitting the bsp up, since vis relies on the portals and whatnot. So if you want something illusionary for the sake of it and need to save a model precache this might work, but if you are trying to save faces by making things illusionary so they don't split things, I suspect it wouldn't. 

Trinca just asked me about the monster_fish "well known" issue: i.e fishes are not counted as dead monsters at the end of a level, even if you killed them all... I know this issue, but don't remember how to solve it... so ... is there a noble man to refresh my memory (and then give advice to trinca) about how to solve this issue ? Thanks in advance ! 

It's a bug in the original 1.06 QC; fishes are counted twice at spawn time, but only once when killed. Comment out one of the total_monsters increments near the end of monsters.qc.

This and similar killcount issues are mentioned in my latest ToolTips. 

ouch... It means QC, and progs.dat rebuild... hhmmmm, I'm not yet used with QC, and I guess Trinca is not as well... Would it be possible you send me an updated progs.dat thta solve the fish issue, or is there a link where I could download the stuff ? Thanks a lot for Trinca and myself ;) 

I've uploaded my latest std progs here http://user.tninet.se/~xir870k/std_progs.7z . It's packed into a pak2.pak file that you can put in the id1 directory.

If you already have pak files with higher numbers than the original pak0/1, just rename this one to a higher number. You can of course also repack this progs into the original pak0.pak if you wish.

There are several other gameplay issues fixed and some debug help for e.g. missing teleport destinations. 

Downloaded ! Thanks a lot !! 

does anyone know where I can get all of Kell's skyboxes? His DL links are down :(

Thanks. 

http://kell.leveldesign.org/skies-kothic.zip 

Thank you, Kell! 

Same question for your texture sets ! I downloaded some days ago knave and apocryphia texture sets, but fury and KDM links are broken.. could you restore them please ? 

you ungrateful bastards ;) 

he he he .... I'm not a bastard.. at least that's what my parents told me ;P

Happy New Year to all of you !!