Well, Quake is an ancient game engine. The fact that we can make maps for it at all is something of a miracle. :) And yes, errors can be disheartening - especially considering how little Quake does to help you fix them.

"new portal clipped away"

Oh thanks! Yeah, I'll get right on fixing that. Sheesh... 

Yeah, it's pretty amazing that the engines and tools still run and are fairly solid (and we have some nice new versions to play with as well).

The mystery errors and (at times) seemingly unfixable problems can really break your spirit though, at least when you're starting out with the Quake stuff. You learn real fast that you need to get it compiling ASAP, and do regular builds to make sure QBSP and the other tools are still happy. At least that way, when the compiler does choke, you'll have a pretty good idea what killed it (likely something you recently added).

The best error I ever had with QBSP was some crap like CHECKFACE: BUGUS or something similarly cryptic. I wish I could remember exactly what it was (not sure if that's it). Anyway, after hours of searching on the web, all I could find was one post or webpage about the error... some guy reckons he asked Carmack about it, and he supposedly walked away muttering and shaking his head...

Not sure if that's true or not, but it makes for a good story. :) 

Yeah, that reminds me of when I started out. I would build 2 or 3 rooms before compiling. This was before editors would load the pointfile or any of that helpful stuff. What a nightmare.

You really do quickly learn to get the new area into a sealed, compilable state before adding all the trim and detail work. It's just not worth it to fly blind. 

real bad with maths, but if I compile two maps without errors, the both still can give a lot of them.

that's what made it so diverse. I used to make maps from one room to another, just watching where the error count goes.
Now I compare parts and put them partly together, arised with that error count.

I'm not using prefabs, probably the reason. 

...just watch yourself when your making something. Rectangles and cubes are no problem to keep on the grid, but when you start messing around with triangles or wedges, just make sure its on grid. Also, we all know you can overlap brushes in .maps, but the point where the lines cross - that has to be on grid! I think this is a big causer of errors - lines overlapping off-grid. Cause you KNOW Qbsp is gonna put it on the grid, and it might no necessarily go where you wanted! All of a sudden you have a bad bsp. 

"Also, we all know you can overlap brushes in .maps, but the point where the lines cross - that has to be on grid! "

I really doubt that's the case. QBSP doesn't snap the intersection points to the grid, just the brush vertices.

I might be wrong on that count as I haven't studied the code in-depth but a BSP compiler that snapped every resulting vert to the grid would be extremely limited. 

Well, ha ha! It occurs to me that I dont know what a vertice is!

http://www.mediafire.com/imageview.php?quickkey=01ftmszvgzm&thumb=4

But heres an image, possibly better explaining what I mean (you may have to make sure you are viewing the image full size)

I know that the Doom3 engine allowed things to be ultimately snapped onto a 0.125x0.125 grid...

I assume, I suppose, that things have to be on grid. I dont really know.

It would just certainly explain a lot of the problems and issues I have run into while mapping. But I do strive to understand it better, so please, explain... 

you might have to download that image to view it! click the link and then select "download image", on the website... 

Your image link isn't working but my basic understanding is that the brush vertices really should be on the grid for best results. What happens after they get chopped up by BSP isn't necessary to be on the grid since there's no danger of floating point creep there. It's compiled once and saved.

There -may- be some sort of snapping that occurs during processing but whatever it is, it will be way smaller than a 1 grid unit.

But there's no harm in lining up your brushes like you are if you want to, so really it's a personal choice. 

Pretend my post was written in comprehensible English and it reads much better. Sheesh. Is it Friday yet? 

What's floating point creep? 

It's technical but if you save a float value over and over again in a text format file, for example .MAP, the values will change slightly each time due to floats only having a set number of decimal points. You lose a little precision each save and eventually the vertices drift apart ever so slightly and you get leaks and errors in your maps.

That's why the early Quake editors had so much trouble and eventually everyone switched to storing vertices as integers for the most part. 

it's the evil twin of the counterpoint - you can't counter it since it floats. 

I tried some more with the mountain.mdl as some terrain mapping. It appears as the triangle methode is worth its effort.
Texturing and lighting are undone, just to see it would vis well.

http://members.home.nl/gimli/gimli11.htm 

I have this map with a monster in the wall. When player enters it triggers the monster with a trigger_once. Because the monster is in the wall it takes 5 sec to leave its place. So this place needs to be sealed. It takes a func train with 5sec delay to seal the wall again.

Is it possible to give the monster a target to the func_train so it opens the wall again when it dies?

For now I can only make the func_train wait for another 30 sec untill the monster is killed. What of course is only an approximately moment. Better would be to connekt it to the monsters death. But I can't see how. 

If the monster is angry at the player automatically when triggered (not targetting a path) then you should be able to target it to a trigger_relay, which it will fire when it dies, AFAIK this can be pointed at the train. But I'm not sure.

There's alot of bugs in these kind of setups (you can't killtarget and target from the same relay, for example) and the methodology isn't very clear.

I assume you've got your own code base - compare monsters and triggers with other mods that have a much cleaner trigger system - Quoth1 and 2, for example. 

AFAIK this can be pointed at the train

but a trigger_relay won't fire a func_train to a destiny point.
Already tried. I guess I got to keep it to a timelimit. 

I get the idea.

You could always use two trains and killtarget one whilst the other moves into place.

A hack, basically - but it'd probably work. 

http://www.speeds.quaddicted.com/snk1.jpg 

interesting combination of textures
nice lighting 

Good! 

look nice! 

the skull tex doesn�t fit somehow 

Cool architecture, but flat lights (I guess it is not yet lighted ?) More shots please !! 

its not flat its realistic
besides this map is not for looking at