And what Palette?

Finding it difficult to assign different ones to the various groupings. 

Not sure what exactly you're asking, but maybe these links will help:
Quake palette: http://www.gamers.org/dEngine/quake/wad_conv/palette.html

The color codes for Quake palette: http://www.gamers.org/dEngine/quake/wad_conv/quakepal.txt 

Got it.

Fgd uses rgb 0-255 while Def uses 0-1.

So all the worldcraft values are invalid - any number at all clamps to 100%.

Fixing. 

https://www.dropbox.com/s/dqnm02pth5313sd/Quake.fgd

This uses the 0-1 colour scale.

However, in order to read future fgd's out of the box, without having to convert by hand, you might want to consider reading their native 0-255 rgb format.

In regard to how I grouped things, I tried to make it forwards compatible with any new entities a modder might require:

Logic - white
Dangerous Stuff - Orange
Atmosphere, lighting - Yellow
Misc - Turquoise
Pathing - Purple
Collectables - Blue
Ammo - Dark Purple
Players / Camera - Green

The sub groupings of stuff have slight variations within those broad colours.

I'll do the Quoth one if you decide to keep the 0-1 colour format, along with some cleanup to make them easier to read. 

Thanks, I've been looking for a colour key for ages since a link I had to an image was lost when a site closed.

That .txt colour readout is going to be very useful. 

I would actually prefer the. In the native values. I can fix that very quickly. 

I thought so. It took me longer to figure out why it was displaying weirdly, and even then not long either so no problem. 

The website is now more or less ready and I included a link on it to TrenchBroom's own homepage. 

ok, so last night I changed a value in LinuxCapabilities to force 24bit z-buffer on my laptop and the z-buffer started to work normally.

I was knackered from a long cycle trip, so that's all I did, but next time I get a chance, I'll have a better look at that file and see if I can figure out if I can fix it so that it works without forced value setting. If not, at least I have a build that I can probably use now :) 

Yup, that's what I suspected. Thanks! 

- Fixed a crash when undoing edge and face move operations.
- Improved map loading speed.
- Improved accuracy of vertex computation.
- Added antialiasing for grid lines (rebb).
- Thin out grid lines after a certain distance (rebb).
- Draw thinner grid lines for small grid sizes.
- Added face shading depending on view direction (rebb).
- Fixed a performance problem when editing face attributes.
- Place initial brush in new maps and make the camera look at it.
- Position pasted objects so that they line up with objects under the mouse cursor.
- Added option to use Alt+MMB to move the camera forward and backward.
- Fixed parsing of color values in FGD files.
- Improved Quake.fgd and Quoth2.fgd.
- Updated and fixed some errors in the documentation. 

Cool, you updated your website too with the latest version. You compiled the binaries for me! Yay! 

on my machine. I have microsoft sidewinder mouse.

Also was there something wrong with the brush creation / vertex manip on version 1 that the editor now picks up a couple of brushes in my map and deletes them because they're invalid?

Vertex manip seems better, like the shading, no longer have the map loading speed problems I had before, better grid etc.

It's definitely all-round better. 

You must activate Alt+MMB drag in the preferences. It is mainly targeted at Wacom Tablet users though.

Regarding the brushes, send me the map file please so that I can test it. The whole vertices vs. face planes issue is still not quite resolved in TrenchBroom, but I'm working towards it so that these things can happen. That said, maybe I fucked something up, so make sure to open a bug and paste the file there. 

even though I checked the box in preferences, I even updated my mouse drivers.

I'll send you a private link to the map file, it's not quite finished yet (still a ways to go!). 

emailed you the map file. I'll make a new bug on bithub. 

What would be killer would be if ALT+MMB would fly towards whatever the mouse is pointing at instead of just the camera facing direction. That would be really useful. 

Alt + C? 

What? No.

Have it work just like ALT+MMB does now except instead of moving towards the camera direction it moves towards where my mouse pointer is pointing. 

The Alt+MMB option is targeted at Wacom users. As I understand it, they don't have a mouse wheel. Maybe what you are suggesting would be useful for the flythrough mode. I'll add it to the issue tracker, maybe there's some way to incorporate it. 

It's just something that most of my 3D apps have. It lets you navigate your model very quickly. You just point at what you want to get closer to and zoom. It's a lot faster than trying to aim the camera first.

Just a suggestion! 

But I'd rather have it work independently of the Alt+MMB thing, as that is merely a replacement for using the mouse wheel to zoom.

Maybe something like Shift+Mousewheel / Shift+Alt+MMB. 

What exactly does it do? Does it just move the camera position or does it also point the camera to where the mouse points, effectively rotating it? 

Here's a quick video of me doing it in Modo:

https://dl.dropbox.com/u/161473/Misc/ScreenCapture_3-18-2013%207.36.49%20AM.wmv

The way it works in Modo is:

MouseWheel - Zoom along camera angle
Zoom - Zooms towards the mouse cursor