I am clearly not understanding how this all works.

qbsp: takes a map file and turns it into a bsp file?
light: takes a bsp file and applies the lighting as defined in the entity list saved within the bsp file?
vis: takes an existing bsp file outputs a visually optimised version of the bsp file? 

yes, but each of those compilers puts their data into different parts of the bsp, so when you do -onlyents on qbsp, you're telling it to only update the entity list and not touch the lighting or vis.
and when you do -onlyents on light, you're telling light to only redo the lighting on switchable lights and update their connections with the entity list. 

The vis data is a separate part of the file, like the light data.

You can replace the vis data, just the same as you can replace the light data.

The vis data does not modify the BSP tree.

Or am I wrong? 

Does that mean when I run qbsp with -onlyents, it isn't outputing a NEW bsp file, it is only updating an existing bsp file with the revised entity data?

Is there anything wrong with the way I did it, which was to directly edit the bsp file? Admitedly, the 'angle' field is still there but is now contains a zero value, which seems to have solved the "wiggle" problem straight away. 

Does that mean when I run qbsp with -onlyents, it isn't outputing a NEW bsp file, it is only updating an existing bsp file with the revised entity data?
Correct.
Is there anything wrong with the way I did it, which was to directly edit the bsp file? Admitedly, the 'angle' field is still there but is now contains a zero value, which seems to have solved the "wiggle" problem straight away.
There's nothing wrong with that, it's just more work. 

also, btw, when you put an angle onto a trigger, it makes it so the player has to be facing 90 degrees to that trigger, so the wiggle is really just you accidentally pointing slightly downwards so that it was less than 90 degrees from the straight down angle and the trigger would fire. 

Thanks necros, now I've got it and your last comment is the last piece of what was puzzling me: I didn't even realise that triggers could angles. 

Are there any good guides around for optimising a map? My Deck remake is fairly detailed, maybe too detailed(!)... I'd rather optimise it than to start chopping detail down.
UT had occlusion brushes and such, will using skip textures on the void-facing brushes make a difference (is this what you're supposed to do??)... 

Anyone got a copy? The link up-thread is dead. 

func_detail entities should help. As for optimizing the map itself ... is it actually slow? It's hard to make a machine run slow with Quake these days. 

It's hard to make a machine run slow with Quake these days.

It really isn't. 

Is there a way to add up 2 .lit files?

I've been playing around with Q1Rad a little and I like the area lights and indirect shadowing it gives.

I've got a light_environment for the sky and light emitting slime as ambient lightsources but I wonder if these can combined with lightmaps from Bengt's light tool for the pointlights?
I like the idea of having bounced area lights to supplement the crisper lighting from pointlights. 

maybe it's my machine? I find I have to tweak settings a bit on some of the newer custom maps. I've started using RMQ as my main engine a lot of the time because it usually always gives me a solid framerate (plus I love them coloured coronas) 

Not that I aware of. Lit files only hold colour data, btw.

think it might he cool to bring back radiosity lighting for quake, but in a more controlled and sutble way... 

It really isn't.
Maybe you need a better machine. :) I have yet to see a Quake level that gets my machine above "bored". 

Maybe you need a better machine. :)

You try playtesting somebody's 100+ monsters map without a fullvis and come back. But eat a bowl of dicks with deqer first. 

That may as well be just luck. Some Quake engines are not as optimized as others, and then performance depends completely on the driver. For example, I got severe slowdowns on my 2012 iMac before I patched QuakeSpasm to use a different texture and lightmap format. 

Wasn't trying to offend, otp, just fooling around. My machine IS a beast though. 

The Quake engine scales differently than modern game engines. So a large map can indeed make even a fast computer choke. Like Sleepy says, some ports handle it better than others (RMQ and DirectQ come to mind). For example, the unvised version of Tronyn's latest map ran quite poorly on my machine, at least initially, and it's by no means a slow computer.

And this is only about polys. If you take additional features into account, replacement graphics and real-time lighting, it's actually fairly easy to make the game run slow. 

I'm not aware of any distinct guides. There's always room for optimization. Func_detail won't help here, it only makes the vis complete faster. It's sometimes possible to bring down the wpoly count by turning certain things into func_walls and illusionaries or move touching brushes apart. This requires experimenting, however, as it can well turn out to be counterproductive. Check the map with r_showtris and r_drawflat to search for and investigate locations where unnecessary brush face splitting can be avoided. 

part of the problem is due to Deck being simply a big atrium, plus the detail I've put into it also.

I can't seem to get r_drawflat to work, I think it's due to there still being a giant hole where I haven't made the ceiling work.

Am I supposed to use skip textures on the void-facing polys? (haven't done that yet either if you are) 

Void facing "Polys" (I assume that you mean the faces of brushes that are touching the void here) are ignored however putting a skip texture on them would probably confuse the bejesus out of any bsp compiler.

You might be able to make a big "Curtain" of additional skip brushes that occlude the faces facing inwards. I don't know if that's going to help or hurt you though. 

Once you fill that hole, the compiler will automatically remove all void-facing ploys. This will cut your r_speeds in half, probably. So basically you can't accurately gauge performance until the hole is filled. 

skip on 'void facing' polys will not cause problems, but it unnecessary from a technical standpoint. (some people do that because it's clearer to look at).
The reason is that the compiler completely removes all faces on the outside of the map before the skip removal process runs. 

That makes sense. I wasn't aware of the order of the steps that qbsp does things. I do know that with other "Special" textures that mixing some of them with others on the same brush can be a bad idea. I was just extrapolating from that.