Hopefully this gives some inspirations for future Quake maps:
https://www.youtube.com/watch?v=GZ99gAb4T0o 

I'm liking a lot of the stuff people are posting. Great work.

I'll be getting back to it in about an hour.

https://www.twitch.tv/ionous 

Is it possible to make sentinels move between path_corners? By default it just seems to just stay there. 

They're stationary enemies. 

would probably be annoying as hell though. 

The wonders of lighting.

http://www.quaketastic.com/files/Jam7/jam7_ionousG.jpg 

For people with properly calibrated monitors:
https://dl.dropboxusercontent.com/u/9212165/ff.png
Looks pretty impressive! 

You can go absolutely nuts with this obscure Quoth feature: http://www.celephais.net/board/view_thread.php?id=4&start=10180&end=10181 

Hmm, thought I'd do a full vis for fun...started 2 days ago, still only at 55%. The full release will therefore miss the deadline or else have only fast vis (meh maybe not so bad but...) 

 

Absolutely I will use teleports, I will make everyone hate the map ; P 

I listened when you guys talked about it earlier, but I haven't used it personally ever, what is the purpose of func_detal brushes and how to use them? 

Thanks dude* 

They are used to decreased compile time. Brushes set to be detailed are usually just that - details in your level like rafters, shelving, overhangs...stuff that isn't the basic geometry of your maps. 

Thanks Bloughsburgh. But because I want to understand it practically/precise, let me do couple questions:
Situation 1:
I have a wall that made of 3-4 slices of different brushes with different textures, do I move func_detail brush over all that?

If I have a square brush which is on floor and has sliced in two parts, do I move func_detail brush over that as well.

I already use clips in some cases, but clips are used to add that collision only right? Func_detail doesn't add collision?

Sorry my bad English* 

By "isn't the basic geometry" do you mean detail that has no collision? 

by collision I mean "collision mesh/box" 

Detail brushes are included when the collision hull is created. They are just ignored by Vis.

Vis basically just calculates which parts of the map are visible from other parts. Any parts that don't significantly affect line of sight could be made detail.

However, any brush that contributes to sealing the map or contacts the unsealed area should not be made into detail. 

I should probably add that the main reason for visibility calculation is so that the Engine only has to render what is visible from the player's position. That was pretty important back when Quake was new. Most mappers would carefully monitor "r_speeds 1" for their maps. 

By visibility calculation do you mean back side of the brushes or sides that are never shown to player? But why not use skip texture then? 

Or is there something to do with this "less time more results" mentality. Maybe I didn't just get it, because I'm stupid. But it sounds like you can place func_detail brushes between walls so everything before that "cut point" are calculated, am I on right direction now? 

Just figured I'd ask before going further:

Trying to use a waterfall that is "3" models high. Preach's Tome of infinite wisdom states to have each one be 4 units back from the last.

Here is a picture of my attempt, granted it looks okay in the picture but there is an obvious seam where each fall starts in game.

http://www.quaketastic.com/files/Jam7/mjb_waterfall.jpg

Is that the intended look? Or maybe someone could steer me in the right direction. 

The basic, low-poly skeleton of your map should be made with worldspawn brushes - this will define the spaces that vis uses to create the potential visibility information for the map.

In addition to this basic hull there will be various brushes that add detail and other embellishments to the geometry.

Any brush which doesn't significantly block the player's view should probably be detail. Specific examples include:

Pillars, plinths, supports.
Beams, trusses, buttresses.
walls that don't extend all the way to the ceiling of the room.
Suspended walkways, platforms, overhangs.
Arches (e.g. build arches in such a way that when you hide the arch, a boxy hull is underneath).
Steps (create a smooth wedge-shaped world brush underneath).
Furniture and other clutter.
Rocks, terrain etc.
etc. etc. etc.

MOST IMPORTANT - do not use detail to seal gaps in your basic "map skeleton" - i.e. imagine hiding all your func_detail brushes - when these are hidden, the structure of your map should still look watertight. 

Is that the intended look? Or maybe someone could steer me in the right direction.

Yeah, that's more or less what you get. The built-in waterfall model can't be tiled into a single seamless flow. This is because the water falls with acceleration - each wave moves faster the further down the model it gets. Once you get to the bottom, you have fast water meeting slow water below. So the idea is long waterfalls get made out of several smaller steps, with the water landing on a lip and then flowing over the next.

It can look a bit off, but one thing that can help is staggering the animations of the waterfalls. Setting the frame key to a number between 0 and 25 staggers the animation, but you need to work around a bug first! The workaround is simple, set targetname to a placeholder value you don't ever trigger elsewhere in the map, like "!!!invalid-target". That way the waves aren't all landing at the same time on each one.

Another option is to make the steps more distinct by offsetting each one more than 4 units, with a little pool of water between them. This might communicate the steps better. Here's a screenshot of how that might look:

https://tomeofpreach.files.wordpress.com/2016/08/waterfall.jpg 

What's r_speeds?