ag>What do you mean by crash in vis at 70%, does it actually crash (with a dialog from the OS), or just seems to be stuck on the same position for a long time?

OS crash on my decompiled map elmdm5 which I fixed up since then with colored lits and map fixes. It worked just fine many previous versions of vis. It took about 1 hr to compile on my p200: treeqbsp, vis(that website), and tyrlite.

as 

Just read the relevant bits, aguirRe, and it got me wondering: just how big can I make a func_wall? You mentioned that all the brushes of a single func_wall must be in the same area, but would I also run into problems if I made a REALLY big func_wall? 

OK, please send me the zipped map+wad and I'll try to find out what's happening. 

I've no idea how the compiler (or probably more important, the engine) will handle very big func_walls. What I know is that entity brushes seem to be less efficiently rendered by the engine so you can't go overboard with them.

Also, the reason why you should keep all parts of one func_wall in the same area is that otherwise the engine will have problems knowing whether to render them or not according to the vis PVS (potentially visible set).

In any case, I wouldn't suggest relying too heavily on assumptions of qbsp/engine, you'll have to trial and error step by step. 

parts of your func_wall will not be drawn if it crosses too many bsp nodes, becuase each node it crosses creates an efrag. So as you walk around, you will notice those pieces appearing and dissapearing. 

When I was a less knowledgable mapper, I was working on a terrain map for Q2 using almost all overlapping brushes for the rocks -- I'm talking 26 sided cylinders clipped and skewed every which way. When I compiled with the standard tools, it took 4 or 5 days to get half way through it, at which point my computer would just shut down. It is unrealistic to build large areas of rocks/terrain in this manner.

In conclusion, the best way to the kind of map you are talking about is to build it mostly from triangle meshes. A pain in the ass, yes, but you will have very few problems. 

Hello,

It seems that major problem than mine occured these night, and then nobody answer my basic question... grrr..
Anyway, I'll retry now: I never used lift (and train as well) into map, and I would like to use them for the next one. So, How can I build a lift with for example 3 stairs, with 3 call buttons on each stair, and the possibilty to choose the stair destination when into the lift ?? It's like our real world lift..... hum...
Is there somebody who knows how to do that ??

Thanks 

I think I'll stick with the triangle method for the time being, until I'm ready to move on to a newer game engine.

===

JPL: the closest behaviour to what you require can be achieved with a func_train, but only if you use the Hipnotic QC source, or equivalent QC which allows trains to pause at each path_corner, waiting for retrigger.

Note that you won't be able to have call buttons inside the lift though, because you can't set up buttons that move as if connected to the lift.

If I were you, I shouldn't worry about trying to do complex mover behaviour like this until you've mastered the basics. Once you can make great "vanilla" Quake maps, then you might want to start thinking about custom QC etc.

Hope this helps :) 

Thanks for this quick reply.

If I understand correctly, it will be very hard to perform a complex and complete lift feature with more tha 2 stages... grr..
And as well, I need to "trigg" the path_corner before it let move the "func_train platform"... but what about the waiting field ?? Do I need to set a wait -1 to stop it ?? But if I set wait -1, does a trigger will be enough to restart the lift ?? Sorry but I'm not sure about the right methos I have to use...

Thanks 

You will need to use a "func_train2" in the Hipnotic QC code to make a train (lift) that is capable of stopping and starting.

In the path_corners, set "wait -1". This will stop the lift when it reaches each destination. The train will then need to be retriggered to start moving again.

Note that this is fine for movement between two floors, but as far as I am aware, if you want to give the train a choice of paths (i.e up or down), in a 3 stage lift or more, you will need to write custom QC. 

Concerning QC custom code, I'm not a very well software designer (C code is not my "cup of tea"...)... so, forget this option ;-))
I'm currently building a base-based map using 3 stairs (perhaps 4, it's not yet clearly defined) and an unique lift to reach each stairs should be great... I will see later how to build it, perhaps with an automatic one...
Anyway, thank you very much for these quick replys, and for the informations..
Regards. 

You could also check out the Custents pak; I think it also has some func_train enhancements. Get Custents at Fat Controller's site http://www.planetquake.com/fatty . Look in the downloads section. 

I'll take a look later to this link..
Thanks 

...for the moment, use the Oubliette method. Have the lift (train) access all levels in a continuous loop, but restrict access to all areas until certain buttons are pushed. 

This method was the first idea I had... and it seems that I need to come back to it !! Anyway, I've just started the map, and there is still long way before designing the lift... I still have a lot of time before taking a decision about what kind of lift (or several ones.. ) I will use..
Thank you for this advice ... 

Explain?? 

http://www.snarkpit.com/editing.php?page=tutorials&id=16

http://www.snarkpit.com/editing.php?page=tutorials&id=18

http://www.snarkpit.com/editing.php?page=tutorials&id=17 

Using triangle method for terrain is great to avoid huge plane terrain, or cliff in a map.. As described in VoreLord related links, you build a surface using triangles.. It is very easy to build if your map editor includes a "brush splitting" tool like described... But in some editor it doesn't exist (like QuArK).. you'll so have to build your triangle-based terrain manually using pyramid or tetrahedron polygons... and it can take you a long time (you can see an example with my "ugly" bunker map.. the dune terrain was built like this..)
You will have a cool look, but there is a bad news.. it increases painfully the VIS process time..
You will so have to find a trade off between compilation timing and polygons number...
Hoping my poor experience gives you some further infos :)

Regards.. 

quark does have a brush splitting tool? at least it did when i still used it 

Thx im gonna Make some kickass terrain now!

Kinda off topic but who wants to recomend a good QWbot? (a bot u kill not a bot that kills for you) 

FrogBot 

I don't know about a "QWBot", but for normal quake, you can't really go past the Omicron

http://www.fileplanet.com/dl.aspx?skorpion/files/obots102.zip

especially with an .ent file(route) installed for the map. 

The easiest method by which to create a terrain mesh is, of course, GenSurf. It's fun. Lots.
Combining it with Terragen I can create my heightmaps from pseudo-fractals and a bit of elbow grease in PSP. This gives lots of control over the look and feel of the terrain overall and also allows specific modifications to be made in respect of conventional brushwork, Vis, LOS etc. Even to the level of adjusting one/several terrain vertices by as little as 8 units z-axis by simply changing the color of a pixel.

Optimising the terrain is another matter.
Grouping the whole lot into a func_wall requires that vis blockers be constructed inside the terrain, as per the Q3 terrain method, and with the hope of casting appropriate shadows where the func_wall sadly will not.
Using a single func_wall for a large terrain is also going to shatter the thing into a multitude of efrags, which could look bad as whole rock formations blink in and out of existence due to the vagaries of your PVS. Strategically grouping pieces of the terrain into individual funcs is better and some terrain brushes could even be left solid where useful.

I'm hitting all this stuff because I have been working on a large Q1SP terrain map for the last few weeks and have hit various problems, not least of which being the estimated vis time for a solid terrain version being something in the order of a month.
The strategic func_wall method is probably what I'm going to have to resort to, unless I miraculously gain access to a state of the art processor.
If you use GenSurf, I recommend a mesh resolution of 128 units/triquad. 64 is only really possible for small, isolated bits of rocky stuff in an otherwise 'architectural' map. 256 drops the brushcount+compile time+render issues considerably, but looks extremely naff and is a pain in the arse to traverse.
A large terrain map is a beautiful thing to make, but think very carefuly about exactly what you want to do with it and if you really want to be so ambitious. I wish I'd given more thought to my landscape.
In the absence of Q1 detail brushes, even the generous limits now pushed back by current compilers and engines struggle to swallow massive terrain. Despite its name, even Quake can have a hard time moving mountains :P 

Tyrann's prog "Skippy", as I understand it is a bit like Quake3's caulk, where any surface with the skip texture on, will be removed from the .bsp, therefore causing the engine to have to draw less (something like that, if I have it right)which you would think is a good thing, so....

does anyone use it?
are there problems with it's use?
are there any benefits to be gained by it's use?

I noticed that the only version I could find is the initial version from 2000, so I thought that maybe work on it was ceased due to problems or whatever. I don't want to get to far using only to find out it was a bad thing.

Any help appreciated 

I have no idea why Tyrann dropped development of it. Perhaps because there are no known issues. Anyway, it works fine for me, but I don't use it for the things you asked about; I usually use it for obscure things, such as the "statues" in rpgsmse4.bsp. (Download Quake Condensed from my site if you want to know what I'm talking about http://rpg.spawnpoint.org/ .)

Maybe I'm just deluded, but it seems like it would be a pretty rare circumstance where Skippy would actually be useful for removing rendered but non-visible polygons.

The only issue I ever had with the program was when I tried to encase a func_door elevator with a set of "skip" brush stairs to create the illusion of a moving ladder. The brushes that were inside the "skip" brush were removed along with "skip" faces, resulting in a mostly invisible ladder.