Forum posts

Well, guys, thanks for the input.

The solution I've tried is the one recommended by Elon: adding an ORIGIN brush to my elevator. Of course, since it was only ever an intermittent fault, I may never know for sure whether it has been fixed - but if I playtest this level for the next week and don't run into the problem again, I think I can be reasonable confident... :)

If I still do have problems, I'll be sure to let you know...

If Elon's information is correct, would it be worth revising the TWHL entity guide description for a func_train? Perhaps add something like:

While a func_train often appears to work properly without an ORIGIN brush, adding one can improve its stability under certain conditions.

shrug

@ Highlander: I don't think it is a lag problem -- although parts of this level do have rather high r_speeds values so I guess it's possible, especially when several people are in the offending area. I've retained the speed-change path_corner, though, so thanks for that...

@ Saco: My "necropolis" is Egyptian-themed; I'm using a set of textures I got from Wadfather -- in fact, in many ways the texture set has guided the level design.

@ Unbreakable:

@ Kasperg:

my opinion is that any off-theme bounce pad, trigger_push, func_ladders or ramps will be better than a buggy elevator in case you can?t fix it

I guess that's still the ultimate fall-back position, if all else fails!

Still, I tried replacing the elevator with a ladder, and it just didn't seem right somehow. (My original thought was to have a huge fan blowing air (and players) up the shaft; I may yet go back to that if Elon's solution doesn't fix the problem... It would sorta fit the theme...)

@ Daubster: When I first started trying to build an elevator in one of my earlier levels I tried a func_plat but switched to func_train because in most cases it was easier to control, and more flexible. For this level I automatically used a func_train without even thinking that there were other options. I think a func_train is still preferable, but if Elon's fix doesn't work I'll switch back to a func_plat. (I do have a func_plat in an earlier level, come to think of it...)

@ Elon Yariv:

Many people think that func_trains don't need origins- but they do!

Thanks for that. All the entity guides seem to suggest that an ORIGIN brush is NOT required (unless being used as a beam target) and all my other func_trains have worked fine without one - but I'll give it a try. Certainly, when I have more time, I shall do some testing of some of the strange behaviours being mentioned here... :)

@ killer1102:

and mine never seem to use the CENTER of the origen brush
more like 1-6 units up or down...

Having revised my lifts to add an ORIGIN brush, I haven't noticed this to be a problem. However, I would suggest that perhaps the func_train still uses the center of its brushes as the centerpoint, regardless of whether it has an ORIGIN brush or not (and therefore, regardless of the placement of the origin brush.) Again, this is something I might test when I have a little free time.

@ rowleybob: Nope, only 644 units of travel. I do have another which travels further - still less than 3000, I think - but so far I don't think I've had any problems with that one...

@ Muzzleflash: Thanks for confirming what Elon and rowley are saying.

FWIW, I have a couple of the ATI Radeons (a 9600 and an X800, both with 256Mb RAM) and they perform beautifully. A friend of mine has a 9550 (with 128Mb, I think) which also performs quite well.

That probably didn't help much, and I really can't say anything about the Nvidia cards...

shrug

I have a problem with an elevator (a func_train) in my latest HLDM level (Necropolis: Mausoleum, coming soon! ;-)). Basically, you sometimes get stuck on it before reaching the top. (I've seen a couple of levels (and other requests for help) where you get stuck at the top, but it is generally possible to at least wriggle yourself free -- or jump just before you reach the top, if it is a persistent problem!) Of course, since the func_train is set to inflict damage if blocked, you then start taking damage, and die, at which point the elevator starts moving again.

Needless to say, it doesn't happen every time, only occasionally.

I'm almost certain that it happens at the point at which the elevator slows down -- I have a path_corner with a speed reduction at around the point where it happens -- so I guess the simplest solution is to eliminate the speed change. I shall try that in the very near future.

However, I just wondered if anybody had any other ideas? Any alternative approach to this problem?



FWIW, I did a search of the forums and found a couple of posts on related subjects:

In this forum post, Kasperg said:

I dont like saying so, but the best solution to problems with elevators in maps is simply not using them

Which is, unfortunately, just not possible in this particular case. I've only got a small space in which to travel quite a large vertical distance. I originally had ramps, but that was just painful, and some sort of bounce-pad or teleporter wouldn't fit the genre (well, I've already got a stargate or two, but I don't wanna overdo it! :-)) Also, I've never had problems with my other elevators...

In this forum post, JujitsuMan said:

make sure there's plenty of room on for them to stand, it's a half life glitch, not totally your fault. What happens is they didn't put into the engine an ability to make you go smoothly with the elevator, so when your being constantly lifted with the elevator, it puts you inside of it. There's a glitch like that in the actual half life game, the elevator that goes to the surface about 1/4th of the way up

to fix it, just make sure there are railings or an invisible func_wall for the railings, and make sure it's big enough for 2 people to stand on easily

Which makes sense, and makes me think that I really do need to remove that extra path_corner. I'm not sure I understand the suggested solution, unless it's intended to keep people away from the moving edges -- in my case, I often seem to be closer to the middle of the platform when I get stuck, so that doesn't really help...

shrug

Any thoughts?

Although this usually just ends up making the entity realy bright

Yes ... until you realise that it is expecting a value from 0.0 to 1.0! Back when I was trying to have my switch lit just bright enough to be visible in a dark room, I tried 10, 5, even as low as 2. Finally I did some research and discovered that anything above 1.0 is fullbright, 100% brightness. To achieve the kind of effect I was after I needed to set this to 0.05, or 5% of maximum brightness.



Edit:

As for light_origin, the following comes from the ZHLT documentation:

"light_origin can be used to place a brush based entity to a new location for the purposes of lighting. Typical use requires placing an info_target at the relevant location, and then setting the light_origin to point the info_target's name. If the entity is opaque, it will also cast shadows from that location in addition to being lit as if it were there."

So it places the brush-based entity centred around the info_target while calculating lighting. Note that it will cast a shadow if set to "opaque"...

Re the dynamic lighting: I'm assuming from what you're saying that the light in question is actually affecting a large area of the map? If so, that is an awful lot of information which the engine has to keep changing continuously. (The slow strobe ramps the light level up and down, doesn't it?)

I had a similar issue in one of my levels. lab17_storage has a freight elevator. When activated, the lights throbbed on and off, and affected much of my warehouse area. It looked great, and worked well in tests, but when more than one player was in the map, it just brought everything to a halt. I had to switch back to a much simpler flashing sequence - and reduce the strength of the lights, and hence the number of surfaces lit by them - to make it playable.

I wouldn't bet on a particular rotational speed for a fan. Mine vary from a few hundred to a few thousand.

Yeah... I only recently built a machine with a variable speed CPU fan, and while my CPU knew about it, for some reason my M/board didn't. First I knew about it was when I booted up for the first time and got a BIOS warning that my fan speed was too slow... :

It was a loose fan that was mounted on the side of the case inside

Moral of the story: don't call support until after you've checked out all the simple options...

but it doesnt sound all too correct to blame it on a virus only.

The very fact that AlienWare would play the virus card with what sounds very much like a hardware problem has pretty much pushed them off my list of possible future suppliers. Unless I know I've been visiting some dodgy sites, or otherwise playing "unsafe" with my PC, I am usually very hesitant to blame a virus when something misbehaves.

First thing I'd do is boot into the BIOS and see if you can get any sort of readout on the CPU fan speed. I think "normal" is around 3000-3600 RPM, although on newer CPUs you can often get a smart fan which runs only as fast as necessary to keep the temperature down below - well, on my machines it seems to target around 50 deg C. Leave it sitting there a while, so you can see if it increases as the machine warms up. And if it's running too fast or too loud while in the BIOS screens, I think that mostly eliminates the possibility of a virus (you might want to consider a RESET to factory defaults, to be sure - although that's not something I'd rush into either...)

If it behaves fine in the BIOS screen for half an hour or so, and then starts misbehaving when you jump into Windows, it does sound like there's a program running that's causing it -- and the first thing I'd check would be any diagnostic software for controlling the fan which might have been supplied with the machine.

If it misbehaves while in the BIOS ... I dunno. Apart from checking the connection to the MB - both the fan's power, and the physical clamping (in case it's come loose and is rattling) - about all you can try is putting a replacement fan on yourself, to see if that fixes it...

Good luck...

Edit: On second thought, I think it's probably best to check whether the fan is clamped in properly FIRST! 'Cos if it isn't, it may damage the CPU - either physically, or by not cooling it properly. Only once you've eliminated that possibility should you start trying other options... ;)

One further thing worth mentioning about the Ignore button - 'cos I get caught by it all the time. ;)

Don't forget it is turned on!

This can specifically be a problem if you start trying to create or modify other brush-based entities; you can get yourself into quite a mess...

As other people are saying, do something else...

I generally find that the biggest problem I have is getting a new map started. Once I have that first room which I like, building up from there is almost easy. However, when I do find myself stalled at a particular point in the development, I find it very useful to show the work in progress to one of my mates - just give him a quick tour - and see if he has any thoughts on where to go from there. Even if another person's thoughts aren't quite what you want to follow, they are often enough to kick-start your own ideas again: I don't want to do that because I want to do this instead.

OTOH, several of my maps have sections which I can readily point out as having been somebody else's idea; I just had to build it (and make it work, and look good... ;-))

Everyone is saying "compiling shouldn't take hours".

If my compile doesn't take 24 hours, I know I've left something out!

(Well, okay, I've only had a couple of maps take that long, and that was a combination of lots of angled surfaces, and lots of large-area light-emitting textures...)

So really, it depends how detailed the map is. My latest, which is excessively complicated and pushing at the compile limits in numerous places - but doesn't have many pools of glowing slime - takes about four hours. That seems to be about 2.5 hours VIS, and 1.5 hours RAD (the CSG and BSP between them take perhaps 5 minutes, if that...)

are you sure you need all that?

Absolutely!

Actually, while I still want to retain the full thing, I'm rather leaning towards throwing away all the below-ground stuff -- which will give me the leeway to fine-tune the remaining details. I've already got it set so players can't get into the below-ground sections until there are enough people in the level, so throwing that all away won't be too hard...

I think I'll probably release two versions (at least then I'd be consistent.)

Edit: The big problem with the level as it stands is that the lower section really is too big, and slows down gameplay too much...

Hmm. Perhaps I should resurrect it as an SP map or two...?

Edit 2: I know now how to solve this issue -- assuming, of course, that it is related to the size of my level. Full (well, "more") details in my newest Journal entry.

Thanks all, for your input.

Cheers,
Pete.

ETA? Soonish. Probably another couple of weeks, at least. I need to have a playtest or two with my testers, and I need to put a little thought into resolving the issue I'm discussing here. And I've currently got it set up so half the level is locked off until at least five people enter the level -- but I think I need to add some sort of back door switch for people wanting to explore the full thing. And then I need to get the documentation up to scratch...

... and not much of that will be happening THIS weekend.



So, "soonish"!

Edit:

Thankyou all for your input into my question. I have a pretty good idea now of how I'm going to handle the issue -- by having my cake and eating it too. (A phrase which never made much sense to me, but hey, you use whatever's available... ;-))

For those of you wondering when this level will be released, I've probably just added a week or two to my estimate of "soonish" -- but my new journal entry explains it all.

Cheers,
Pete.

It's only - what's the limit? 4Mb? - of textures (slightly less; I'm at about 92% at the moment, although I have run into the MAX_MIP_TEX compile error a time or two.)

I started playing with a set of Egyptian textures (by "Sock") that I got from WadFather. In many ways the texture set helped influence the design. I've potentially only used a quarter of the textures (I hopefully haven't fallen into crappy texturing habits) but I still approached the limit...

Of course, if 4Mb is textures, that means it's still 7Mb of architexture...

Screenshots? Sure.

http://www.petesplace.id.au/image/sshot.gif
http://www.petesplace.id.au/image/sshot2.gif

The first one shows all four windows, but doesn't show the two teleport-effect tubes which are at the bottom corners of the map, running "North-South". The second is the main 3D window from a slightly different angle. I couldn't pull back any more without Hammer starting to clip the stuff at the far side of the map...

Soon I'll post a couple more in-game screenshots to my userpage...

Either way, try cropping out something or just compiling a little bit of the map and see if it then works.

Yeah, thanks, I think that's the approach I'll have to take -- and I suspect that is probably the answer (although it seemed a little strange that a tripmine would not respawn, but a shotgun would. OTOH, it is all weapon-slot #5 stuff, isn't it? Perhaps the engine is simply prioritising...)

I'll do some testing (which might take a few days now) and let you know how it goes -- although if I do have to crop the map, I really don't know where to start. It <i>is</i> too big, but given the design premise I started from, it couldn't really be much smaller. sigh I suspect I'll be writing this level off as a learning experience...

Custom footsteps are just not available for multiplayer maps.

... and that's what killing me (for extremely low values of "kill", obviously ;-)). Because they are available if you set up a minimod.

Anyway, thanks for your input. I think my best bet is to release the map standalone (with .RES file, obviously, to ensure the correct environment map is used ;-)) and set up a minimod customised for all my maps for my own use...

Cheers,
Pete.

Apparently.

I just spent a few minutes testing this, and it does appear to be affecting every weapon_tripmine, and every weapon_snark.

At an earlier point in the development of the level, I noticed a few which were not reappearing, and I'm sure, at the time, others were. But now it seems to be all of them. Also, they are not just "falling through" as I first thought, because it's also affecting some on a ledge which has another floor beneath it to catch them, and they're not reappearing there...

I guess I should add that, while the map runs okay in Multiplayer mode, if I attempt to run it in Singleplayer (ie, by using the "+deathmatch 1 +map mapname" from the command line, which appears to simulate DM rules in the singleplayer engine) it fails with an Alloc ("Too many edicts") error...

So perhaps it really just does have too many entities, and DM is running it but choosing not to respawn some of them?

Edit: It is also affecting weapon_satchels, it seems...

Edit 2: Looking closer, I don't think the tripmines are starting out too low; must have been a trick of the light which led me to think they were... Sorry.

I'm guessing that's a "no" to the minimod then? :

FWIW, I do "know how" (whatever that actually refers to.) I know how to set up a minimod (more or less; I've been nutting that one out over the last couple of weeks.) I think I know how to set up a .RES file, based on the few that I have on my machine already - although, admittedly, I've only recently learned what they were for because in the past my maps've never needed one. I know how to wadinclude; it's the reason my BSP file is 11Mb (and only zips down to 5Mb). ;)

Thanks anyway...

What I don't know is how to make my* custom sand texture sound different, when walked upon, from my custom wood texture, or my custom stone texture - without setting up a minimod or asking people to screw with their valvesoundmaterials.txt file. Obviously polluting the valve directory with my* environment map is not a big issue - but making changes to files which most people will still have locked inside their PAK file? That's not a good thing. Is there some way I can get a .RES file to do this instead?

I guess, though, the answer is that the cons outweigh the pros when releasing a DM map for general use -- but there's nothing to stop me from setting up my own for in-house use.

• And when I say "my", I didn't create the textures I'm using. Maps I can build; textures I can't...

raise the weapons off the floor a bit

Er, yeah. I have tried that, of course. Should have mentioned it in my original post, though. I've got them placed, in Hammer, about 4-8 units above the floor. (But in other maps - and indeed, in this map with other weapons which aren't misbehaving - I've simply placed them by clicking on the floor in the 3D window.)

My newest HLDM map has the problem that several weapons (it primarily seems to be Snarks and Tripmines) are not respawning. They actually appear to be spawning lower than they should, as though they are partially embedded in the floor -- and I suspect that when they respawn they are falling through to the next surface below them (which, in most cases, takes them right out of the map.)

The surfaces in question are mostly flat, not sloped.

The map itself is rather large:

Object names  Objects/Maxobjs  Memory / Maxmem  Fullness
------------  ---------------  ---------------  --------
models            393/400        25152/25600    (98.3)VERY FULL!
planes          11185/32767     223700/655340   (34.1)
vertexes        25644/65535     307728/786420   (39.1)
nodes           13711/32767     329064/786408   (41.8)
texinfos         4413/32767     176520/1310680  (13.5)
faces           18959/131071    379180/2621420  (14.5)
clipnodes       31113/32767     248904/262136   (95.0)VERY FULL!
leaves           8112/8192      227136/229376   (99.0)VERY FULL!
marksurfaces    24947/65535      49894/131070   (38.1)
surfedges       84126/512000    336504/2048000  (16.4)
edges           46110/256000    184440/1024000  (18.0)
texdata          [variable]    3787328/4194304  (90.3)VERY FULL!
lightdata        [variable]    4177326/4194304  (99.6)VERY FULL!
visdata          [variable]     405638/2097152  (19.3)
entdata          [variable]     129799/524288   (24.8)
=== Total BSP file data space used: 10988313 bytes ===

Possibly that is causing this?

Any ideas what the problem might be?

I am almost ready to release my latest HLDM map, and I'm wondering what the consensus is: is it better to release it as a standalone BSP file + the graphics for the environment map, or as a Custom game minimod?

Both approaches have their advantages and disadvantages.

If I take the minimod approach, I can separate the graphics out into its own WAD file (this level uses a LOT of custom graphics) and I can set it up so my sand sounds like sand. And I can keep the extra files required all neatly bundled together. It would be a further saving if I ever do another map in this "series", since I can then make use of the same WAD file...

But on the downside, if somebody has their own set of player models (and possibly other customisations), they lose them when playing a custom game -- unless they copy them across to the custom game directory.

What do you guys think?

Perhaps a little elaboration on the flooding dealie?

The flooding (with slime, not water) is irrelevant to the OP's question. In my level I had to disable some spawn points after the room in question got flooded with slime -- since respawning in there, only to die instantly, would be not a lot of fun.

The point being made by Daubster is that the info_player_deathmatch entity has a "master" value which can be used to "lock" (disable) it via a multisource. So you could effectively have two sets of spawn points for each team, and enable or disable one set of each depending on which side you want which team to restart...

Hey, whaddaya know? It really DOES have a multitude of uses...

My post vanished the first time round, so I'll try again...

My first (completed, playable) HL map was LavaLab. I have a couple of RMF files which predate LavaLab, but they were never finished - in fact they were my attempts to learn what I could or couldn't do with Hammer while aiming for the concept of glass walkways and a canyon which eventually metamorphosed into the volcanic setting instead. (My first volcanic crater was big enough to lose an aircraft carrier in; the current basis for Lavalab was born out of frustration with the constant leak errors I was getting, and began as a hollowed cube - you can still see it is basically square...)

Pre HLDM I built a couple of DOOM levels, way back, and I'm almost tempted to dig them up from somewhere and rebuild them for HLDM, as an exercise...

... but bear in mind, of course, that while a minimal machine (with a video card capable of supporting OpenGL) should be okay for mapping, the compile time is directly related to how fast a machine it is.

No problem.

The buttons? How about you set each button to have its own multisource lock, so that once you trigger it, it can't be pressed again until the whole trap has been reset. (You would need a secondary indicator that the button had already been pressed, and have the button itself reset almost immediately.)

Each button could target a game_counter which would trigger the flood event when all 4 (or whatever) had been pressed. And the flood event would trigger a nulti_manager which would reset all 4 button multisource locks after whatever delay you want.

Should work... (I'll test it out in my next level; has potential... ;-))

Where should I place the spawning points. It can't be in the rooms.

Y'know, you can use a multi-source to enable or disable spawn points... You should be able to disable all the spawn points in the flooded section WHILE IT IS FLOODED, and enable them the rest of the time...

I have two maps which make use of this. One (lab17_flood) has two or three spawn points in a small room which has the potential to be flooded with slime; after it gets flooded those three spawn points are disabled ("locked"). The other (mausoleum) has several levels, and the spawn points in the lower levels are successively activated as players make their way down from the top level by other means (so if everybody stays up top, nobody will find themselves spawning miles from all the action...)

I also use Hammer for my projects. It lets us see things right away. It's also much faster than any CAD or 3Dstudio thingy

... with the added advantage that you can export to DXF if you really need to take it further in CAD.

I agree with what everybody else is saying about adding a little detail to your maps.

One thing I always try to do, just to add a little touch of realism to my maps, is to think about how people might actually get in and out of the place when it's NOT being used as a deathmatch arena. Whether it be a main entrance door which doesn't open, or a lift which isn't working, or a corridor that has collapsed ... something to make it feel like it is part of a larger world, which you can't quite reach now.

(Of course, that then prompts me to go build the rest of the complex as another level -- but maybe that's just me. :D)

I ran it at 800x600 and no issues...

Not on THESE graphics cards you didn't!

At home I run it at 1024x768, so I know the OpenGL can handle it -- but I think with the cards we've got at work (which are NOT gaming cards) it's either a compatibility issue, or a memory issue.

I've got an alternative for you, although it may be just as painful to do it this way...

If you save your level out as a .map file, the entire thing is just text, much of which looks like:

( -48 -88 288 ) ( -88 -48 288 ) ( -88 48 288 ) E-BLOCK08C [ 1 0 0 128 ] [ 0 -1 0 128 ] 0 1 1

Where the "E-BLOCK08C" is the texture of that particular face.

If you know what changes you actually made to the textures, you should be able to do a series of find/replace functions in your favourite text editor and reset all your textures that way. If you know anything about something like PERL (being my weapon of choice) or some similar programming/scripting language, and if you can summarise the changes you made in a list of old_texture,new_texture, you should be able to fix the whole thing in one swift hit.

Of course, you would work on a copy of your .map file -- and doing it that way would lose any layering / grouping information you might have set up, so YMMV...

I think you can probably use -verbose or something to show detailed compile resource usage stuff. Have a look at zhlt.info.

Thanks; I'll give that a try. (I'm still working on the level in question, and it's currently run into one of these limits again, so now would be a perfect time to test that...)

Results: For my current error, MAX_MAP_FACES, it doesn't give me conclusive results. There is a lot of output which looks like this:

-- MergeAll --
226 mergefaces
--- SolidBSP ---
-- MergeAll --
246 mergefaces
--- SolidBSP ---
-- MergeAll --
236 mergefaces
--- SolidBSP ---
-- MergeAll --
92 mergefaces
--- SolidBSP ---
-- tjunc --
131 world edges 291 edge points
14 edges added by tjunctions
0 faces added by tjunctions

So perhaps if I went through and added all the "mergefaces" totals it might tell me something interesting -- but I suspect that the code itself simply stops processing as soon as it hits (or exceeds) the limit, and hence it doesn't actually know what the total number of faces (or whatever) actually is. Maybe some day when I've got time I'll actually look through the code to confirm that... shrug

The only thing I can suggest is that each info_teleport_destination be covered by a trigger_multiple which uses a multisource to deactivate that particular destination -- but I really don't know if it would work fast enough to prevent the engine from sending another player to the same point if the teleports are all triggered at the same time.

(I'm assuming that a single trigger_teleport with multiple info_teleport_destinations selects one at random? Is that how it works? I didn't think that was the case anyway...)

The other way would be to use a change_target -- but again, it may not work fast enough for the simultaneous teleport.

The only other option I can think of - since you say it's "an HL1 mod" - is to add (or ask the mod developers to add) an additional trigger_teleport_multiple and info_teleport_sequential entities which are actually hard-coded to do what you want; distribute incoming teleported people evenly amongst the specified targets...

Edit:

As an alternative possibility, could you have two sets of spawn points (INFO_PLAYER_DEATHMATCH) controlled by a couple of multisources, such that one set is active while the other is inactive, and vice versa. Your main set could be in your main playing area, with a secondary set in your arena, and then instead of triggering a TELEPORT event, you trigger some sort of MASS DEATH event (nuke or whatever) and kill everybody in the main arena (which then makes it desirable to be the person who triggers all this and gets into the arena first, and therefore survives.)

If you run it on a server with forced respawns, you can ensure that everybody will respawn in the arena, and leave it up to the engine to handle the respawns without any telefrags (does the HL engine avoid spawn telefrags? I don't think I've ever seen one... Provided there are sufficient spawn points for the max number of players, it should work fine.)

You could even, perhaps, sound a brief alarm and open a couple of portals into the arena so people will be fighting to get in before the nuke. Or not.

Just something to think about, anyway...

We recently got new graphics cards on the machines at work, and if you try running HL at greater than 640x480 (OpenGL), the map seems to go randomly "full-bright". Probably not the same issue, but it might be worth running at a lower res to see if that makes a difference...?

Ctrl-Shift-G should bring up a go-to coords box too.

That brings up a Goto Entity# / Brush# box; not quite the same thing.

I know basically what you are trying to do. (My guess is you're trying to pinpoint a "Leaf saw into leaf"-type error (or a "too many light styles" error) which only gives coordinates, not entity numbers?) Basically (unless there IS a goto coords box? I'm talking about Hammer, BTW) you need to move your mouse around in the X-Y window to the approximate X,Y coordinates you're trying to find, figure out roughly where that actually is in your level, and then switch to the X-Z or Y-Z box to determine the (x,)Z (or (y,)Z) coordinate...

Basically the problem is that for every little angled face, you have a CLIPPING surface generated.

My first plan of attack when trying to eliminate MAX_MAP_CLIPNODES is to place a CLIPPING brush (a simple cubic brush with the CLIP texture on all faces) in any little spaces where the player cannot actually get to. For instance, if you have a couple of pipes running along a wall, or a fancy stairway with a space behind it which you can see but not reach, fill it with a CLIP brush.

Secondly, if you have any fancy-shaped walls, go through and fill them in with a single CLIPPING brush. For example, compare these two screenshots from Hammer, from my latest level in progress:

Unclipped:Clipped:Of course, CLIPPING blocks are not visible in the final compiled level.

I was going to give you a link to an article by xp-cagey about clipping hulls, and how they are generated, and what they do -- but the site is down. This article seems to briefly cover the basics of clipping hulls, and might be worth a read. You need to have a clear picture of exactly how/why clipping hulls are being used, so that you can decide whether or not to place a hull in a particular spot.

As you can see from the screenshots, each of the CLIPPING blocks I've placed only saves 2 CLIP faces (there were three, there's now only one.) I had quite a few such walls, however, so it seemed a reasonable place to apply the method - and as it happened, it got my level compilation going again. The biggest problem with using this method is that - with the version of compile tools I'm using, anyway -- it doesn't tell you how many clip nodes you've actually got, it only tells you you've got too many. So proceeding like this is very much a blind effort; you have never got any idea how close you are to solving the problem...

Hope that helps...