goes in a folder named 'move2id1' beneath the keygip16 folder. My version of it works fine even though I haven't loaded it since last summer.

A few other factors. Check the preferences. Make sure there is a WinQuake path listed and a dem path listed. It does need a .dem file to load correctly. The three Quake .dems will work fine for that purpose.

So if it continues to freeze, open up the kgdemo.cfg ('cfg' is for configure) in note pad and supply the necessary file paths and be sure to match them to your Quake directory and where you keep your .dem files. 

There used to be a submit link on UnderworldFan's site? 

Was trying to compile my q1sp, and got the error MAX_MAP_TEXINFO, which noone seems to be able to explain, while using TreeQBSP. Anyways, I was in #TF and RPG suggested I use your bspinfo.exe, which was included with the visbjp.zip -- which I did, but I got an even weirder error message: "c:\quake\id1\maps\q1debris5.map is version 1696608047, not 29"

I'm all out, here. 

Hmm, that seems unusual, my Tree/Tx compilers shouldn't normally abort on # texinfo. The BspInfo error just indicates that the bsp is corrupt, it should always contain he magic number 29 in a Q1 bsp.

Send me the zipped map+wad and I'll take a look at what's going on. 

Jago, since I didn't see anyone answer your question, I believe a door with multiple parts may be linked by simply grouping all the brushes together. ...At least that's what I do in Worldcraft and it works. That way you don't need a trigger and door names. 

Thanks for the tip. I'll work on it ASAP. Very informative i might add. (yr page) Provided information difficult to find nowadays.

Any suggestions on a leaky map that dosint appear to have a leak in it? Say the .pts file's line goes through what seems to be a solid brush. 

i've gotten that problem very often, esp when working with natural terrain. usually, the best way to fix it is simply to remake the brush in the editor (delete, and reshape a new one) although it's long, it's usually always works. if not, try splitting the brush up into two or more pieces. 

yeah it seems like qbsp dont like it much when brushes are misaligned. Even when said misalignment shouldint cause a leak.

Its all right there on buddy's webpage :) 

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.