always map on the grid! besides it looking much better ingame, you avoid lots of little strange problems like that. 

Well... the grouping of door ents might be a superstition, and they could be working for me just as CZG said, because they are touching.

/me sprinkles more giblets in the pentagram around his mapping chair to appease the Quake gods. 

I will try grouping the entire door to see whether that helps. As of now the left part is grouped together (consists of several brushes) as is the right part. 

Hello,

I'm back with my basic questions... I never used lift and walking monsters, and would like to use it in the map I'm currently working... I've read somewhere that func_train can be used, but I would like further informations and advices to use it correctly..
Is there a noble man that can help me please ??

Thanks 

Target a path_corner with a monster and it'll walk towards it. (untill awakened). Then target that path_corner to another path_corner and target the second path_corner back to the first path_corner and the monster will pace between those two points.

Thats how you make walking monsters (i think) 

Thank you, I'll try it as soon as possible...
And now, what about lift ?? I would like to create a lift with "call buttons" and "stair choice buttons" ??? I mean a lift called by button that allow the player choose his stair destination... Is it possible to build that in Q1 ??
Thanks 

http://user.tninet.se/~xir870k/

There's no email in file. I need to get in contact with them. It crashes on 70% in the vis program.

as 

Whilst researching for my next Quake map, I godded my way through Alice, to check out the inspiring level design. Now, one thing that really impressed me was a particular style of rock formation that's used extensively throughout a couple of the maps. It appears to consist of loads of overlapping boulder-shaped brushes built up to make huge rocky structures.

Here's a screenshot from Alice illustrating this:

http://photopile.com/photos/sloochyslooch/quakemisc/124282.jpg

Now, I always thought that overlapping brushes like this in Quake was a bad idea, but this is the Quake 3 engine, so I flipped on gl_showtris to see what was going on:

http://photopile.com/photos/sloochyslooch/quakemisc/124283.jpg

As you can see, the triangles that make up each boulder aren't actually getting cut up by the overlapping boulders. Am I correct in assuming that these rocks are all detail brushes?

If I was to build rock formations like this in Quake 1, would it be a very bad idea? Bear in mind that I'm not really bothered about r_speeds, I just want to get an idea of it's feasibility from a technical standpoint, i.e. could bsp theoretically cope with all the overlapping brushes, or would it just choke?

aguirRe, any thoughts? 

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?

The former is an error, but the latter is not unusual in some maps, they just take a very long time to finish vis due to unfortunate design. The high-score I've heard so far is 550 hours (on a pretty fast machine) held by Scragbait.

Please email me your zipped map+wad with a description of your problems and I'll see what I can do. 

Brushes that overlap a lot increase processing time (the CSGFaces part in each hull), but thanks to algorithm enhancements by Tyrann the penalty is much less than it used to be.

However, if the overlapping is minor, you can get any kind of problems; leaks, clipping errors and HOMs. It's always a bad thing for qbsp to have multiple planes that are near identical. Then the floating point inaccuracies can produce pretty nasty results. 

that you might also want to check the Vis Issues section of my ToolTips for detail brushes in Q1. Please bear in mind that it's not any Magic Bullet, but might be useful in some cases with a bit of planning. 

The reason I'm very interested in this method is because I'm planning a large scale map that will be almost entirely rocky terrain.

I'm also currently working on another map that has a fair bit of terrain in it, but it has all been constructed with the "triangle method", which is a nice safe method that gives good results, but is very time-consuming, and isn't very useful for really freeform stuff like in the Alice screenshots.

The "overlapping boulders" method seems like a really quick way of building terrain, but the map I am planning would consist of hundreds upon hundreds of brushes overlapping in this manner - I just wondered if it would be a realistic option. 

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