creating a block of natural rock from one multifaced brush is better than several triangular ones that together form that block

Now that would be particularly relevant to Gensurf created terrain, because the t-mesh is neccessarily composed of individual triangular brushes.
The more I read in this thread, the less I want to finish my map :( 

When I was working on the terrain in RPGDM1 recently, I noticed that entire vertical patches of triangular brushes could be exactly reproduced by clipping pieces off of a 6-sided block. That was quite cool, and really helped the clipping problems.

/me HUGs 3-point clipping

________
Hmm. After writing this, it seems less relevant than I thought. 

discouraging, there are other opinions that promote triangular brushes instead (which may very well be right) so the case isn't clear.

I'm just trying to rationalize around the brush expansion issue to help mappers understand some of the underlying structure.

I also forgot before to add a link to XP-Cagey's interesting article in the subject: http://xp-cagey.com/?article=1000 . 

Thanks. 

So if Quake1 doesn't work under WinXp, I tried the WinQuake program. And then it does.
But when I run my convertion with my selfmade monsters, they don't appear in game.

The program starts at the start.bsp without messages, but when I run a saved game, it suddenly comes with all those errors asking for the monsters I put in the progs.dat?!

Why doesn't it do so when I start a game? 

Are you running the game from your own custom directory? e.g. c:/quake/winquake.exe -game madfox 

remember to delete opengl.dll in the quake folder so that you can use glquake with new graphics cards. 

it's the same directory from C:\ I used to play with under Win98, and there was no problem.

Now with WinQuake, it seems to block out my progs content in the pak file, giving all these edickts of finding no monster_orb etc. 

I�ve been running Quake1 on WinXP for years without issues. 

but how do you managed this without winquake?
it kills all my convertion options. 

Use FitzQuake for NetQuake and FuhQuake for QuakeWorld. 

The only engine that doesn't work in XP is DOSQuake, all others work fine including WinQuake.

Follow Kell's advice and check out the shortcut contents and make sure it's the same as you were using in Win98 with DOSQuake. Many engine options are identical in all engines. 

If I use Telejanos, everything comes through all right.When I use DOSQuake, with the same options as in Win98, suddenly all my own monsters are gone. And I do play it from C.

I don�t mind if happening so, but I like to play Quake straight, without comparing engines before it. I found Telejanos is working so dark, couldn�t change the gamma. Made me make the levels much lighter, but then the original engine makes it too bright.

It comes to me as a surprise WinXP is capturing all my own monsters from the progs.dat 

I'm sorry, but we can guarantee that it's not the engine, or your operating system, that is preventing your mod from being detected.

Also, I'm sure you're aware of this, but you do have your mod files in a seperate game folder? (e.g. C:\QUAKE\MadFox) - I know some people have tried putting their mod files inside ID1, and then they wonder why it doesn't work correctly. 

my Telejanos under C: won�t show them, although the same pak file under D: works good.

I made a pakfile with Quark,
made a file maps for the bsp�s,
made a file progs for the mdl�s,
and a file for the sounds.

Could be I have to use two pakfiles, but I find it strange the same pakfile runs good under D: and C: fails... 

Do any of your mod's files have capital letters in them? This is especially important for the files in the pak. DOSquake really doesn't like them, and so it might just not be recognising the files because of that. It's quite likely that telejano has this fixed...but of course I could be totally wrong here. Anyway, try making sure all the filenames and extentions are lowercase if they aren't already. 

No, I just get confused while I can't see why it works under D:\ and not under C:\ 

I have a few clipping problems in this map I'm working on, so I tried using -hull 1 -solid -noents on TreeQBSP. Well it seemed to work fine, everything was expanded, but I didn't notice anything that would have been causing the clipping errors. I'm just supposed to look for misaligned surfaces, spaces that are too short, and things of that sort, right? 

guarantee that clipping errors always will become visible when using that option but if you actually *do* see a HOM, it's a safe indication on a brush problem in that spot.

Typical causes are misaligned brushes or sometimes even a nearby pointy brush that somehow "pokes" a hole through the damaged brush.

If you send me the zipped map+wad and a description how to find the spot (or coordinates), I'll take a look and see what I can find out. 

I'll send the message shortly. Gotta put all the textures in one wad. 

forgot to put in the progs.dat and progs.src
now everything runs fine again. 

Great link aquirre, that explains the thing i was missing -- i thought that the qbsp bevelling would be sufficient, but i hadn't thought of the case where the blade of a wedge-shaped brush is running at an angle like that.

After further thought, i don't think xp-cagey's solution actually solves all cases -- he seems to have handled all problems caused by sharp edges, but imagine a sharp point at a weird angle, such as a pyramid with the pointy end in a nonaxial direction -- this still wouldn't be solved by his code becuase he's only looking at edges.

Still, it's an improvement to go from handling all faces and some edges correctly to all faces and all edges. I think a final bit of code to address points as well would finish off the problem for good. 

it's a precision problem rather than a logic problem. 

One of the reasons the map I'm working on has such a huge brush count is my liberal use of triangles, on architectural as well as terrain brushes. I haven't been that aware of the hull expansion issues until now. Bugger. 

As I think I mentioned before, HL seems to have had worse problems than Q1, so at least one of the cases XP-Cagey's describing in the article is already covered by the original Q1 expansion code.

He sent me some map examples that he claims fails in HL and they worked as expected in Q1.

I have a feeling that the problem is a combination of brush expansion, CSGFaces (brush merging), outside filling, SolidBSP (building the final tree) and numerical errors along the way.

Since I doubled the precision (to 64-bit) in my compilers, they work much better than before, so precision is involved but increasing it can only do so much. It's also interesting that doing the same to e.g. vis, doesn't make any difference at all.

Tyrann made a great stab at it in his TyrQBSP and some of the solutions he put in there, I've imported in my versions. Overall, it doesn't really seem to help, it only makes the compiler faster and a bit more consistent.

Kinn: If you don't have any obvious problems, maybe you shouldn't worry too much yet? After all, this isn't a new problem and it's definitely not worse than it was before.