and most monsters use hull 1 for collision detection, while e.g. shamblers use hull 2 which is even more expanded (looks really weird).

Making the clipping hulls visible doesn't fix anything but it might help understand why these symptoms occur. There is an option -altexpand to alter the behaviour of the brush expansion logic, but it's a bit controversial and usually doesn't really fix the problem. 

Just a general question... if only large monsters use hull 2 (and the player does not use it at all), would it be possible to remove that hull from a deathmatch-only map and save some space?

Of course the reduction in file size would probably not be significant at all, so I doubt it would be worth it. I don't necessarily want to do it, I just want to know if you <can> (potentially). 

Can covering the offending area in clip brushes sometimes help this problem? 

and now my Quake1 cries with SIGSEV failures... 

This isn't what you wanted to know, but if you did that then you couldn't play the map in DMSP. 

It's pretty hypothetical but yes, in theory it should be possible (if the engine also was changed in a similar way).

Other games (e.g. Hexen2, HL, Q2) has an extra crouching hull so I can't see any obvious reason why it should be impossible to remove the shambler sized hull if there are no shamblers around that can complain.

You wouldn't save much space, though. Especially since DM maps are generally smaller and with less detail to keep r_speeds low. 

Yes, if the clip brushes would completely cover the invisible protruding objects in the hull in question.

The clip brushes get expanded the same way as other solid brushes so if you can't confirm by "feeling" that the the clip brush works, you could use another texture momentarily and build with -hull 1 to visually confirm it.

The main problem with the expansion is that it gets unexpected on complex brush shapes. It's always simple to imagine how a cube is expanded, but pointy triangular shapes that look great in the editor, can grow like cancer in the other hulls. 

I've spent some time looking at the expansion code, trying to solve the strange clipping bugs you guys are talking about. It SEEMS like the code was designed the way it should be, and i wonder if there just isn't some implementation bug. Or, a precision problem?

I never checked out your visible hull stuff, and it would probably help me understand exactly what wrong results the current expansion code is generating.

Anyway, this is one of those things i really wish could be fixed in qbsp, if anyone ever finds the bug or realizes why it doesn't work. 

AFAIK the brush expansion isn't really a "bug" since there's no obvious way to do it without getting protruding parts in some junctions.

Changing this logic is controversial because most experienced Q1 players (not to mention speedrunners) know how a map should "feel" when they see it.

Me and Tyrann have spent a long time spanning several years trying to find the cure for the brush expansion related problems, especially the theoretically impossible leaks in hulls 1/2 (when hull 0 is sealed). Same for the annoying clipping errors; there are a whole list of variants just for them.

I've also contacted XP-Cagey who works with the HL tools and he confirms the problems and it appears that in HL, the situation is even worse. Apparently, he's found some kind of solution (or at least improvement) for HL and I've tried to translate it to Q1 but I've only managed a partial implementation so far (available with the -altexpand option).

Any help or suggestion regarding these problems are welcome, but I've a feeling that the solution might be complex. The whole build process seems to be something of a hazy floating point stochastic (or even chaotic) process, where small changes can have large impact elsewhere. I hope I'm wrong ...

But check out the hull visualization, I think it's a real eye-opener for most mappers (and players too). 

mention that the brush expansion logic is also the reason why I think that e.g. creating a block of natural rock from one multifaced brush is better than several triangular ones that together form that block. Even though there's no difference when looking at it in the editor, the expansion might be different.

The multifaced brush will just expand pretty logically outwards and will not generate any weird protruding objects. The expansion is always done for each brush separately so it won't notice that after expansion, the brushes might not join nicely anymore.

There are probably other aspects of this issue too. 

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...