Netradiant seems much more actively developed: https://github.com/divVerent/NetRadiant

Also check out https://github.com/jdolan/radiantjs -> http://radiantjs.herokuapp.com/index.html 

Ah, looks like they finally added a workaround for the foreground/background issue. Though I'm pretty sure there's still no fix for the NextView button/shortcut not working on the floating window layout. It's been there for years. Will have to stick with Gtkradiant 1.5 for another while...

Kinn, the old download directory is still accessible here, but there's no newer version. There appear's to be some slightly newer build by Ingar dated July 2012, not sure how many fixes it actually contains (if any). 

Ok, thanks chaps - negke, good to know the old download page can still be accessed. I couldn't find it through google or anything. The Ingar build contained 7 trojans according to Kaspersky - probably false positives but...eh.

I'll stick with my current version I think. The clipper problem is minor-ish. (Basically, the "1, 2, 3" number labels on the clip points don't display anymore, which makes 3 point-clipping a game of chance more than anything). 

Kinn, I always Shift-Enter the clipper unless I know for sure which side will be removed. 

yes, that's ok once you have the correct clip plane - problem with netradiant's bug (and it's only an issue with 3-point clipping), is that if you lay down the 3 points in XY, then change to XZ (say) to shift the points in Z, because the points are not labelled 1-2-3, then often you lose track of which point needs to move where in order to get the desired clip plane in the first place. It just slows the process down and makes it more annoying. 

I get what you mean now. that sounds like a real pain. 

I have just noticed that a dead Imp 'floats' a couple of units above the ground. Comparing models in QME, I can see that e.g. the Hknight and the Imp final death frames are both on the grid, and also the eye position is -24 for both.

What determines the final resting place of a monster? 

don't really know what the eye position is, or if it does anything.

the 'bottom' of the monster is determined by the bounding box set in the QC.

This is -24z for all monsters (unless you are playing around with non-standard bounding boxes)

As long as the bounding box is set normally like it is for small and large monsters, then any vertex on the model that is 24 units below the origin of the model will be on the ground. 

Yes, that was it - looks like a typo in QC as the z was -34. Thanks. 

Has anyone come across a texture set that even remotely evokes the Australian bush or outback? 

I think I saw it converted somewhere. 

Is there any guides on how to setup GTKradiant for quakeworld? which version should I use? 1.4, 1.5 or 1.6? 

http://kneedeepinthedoomed.wordpress.com/tutorials/ 

Why are brushes stored as planes and not verts + tris? Was it only to on save filesize? 

with a list of planes 

On top of that, enumerating vertices and adjacency information is considerably more complex than simply giving a list of planes. And of course there's much more that can go wrong. 

Oh,so this is a case of it being the best way to represent the data then? I guess it's only easier for puny human minds to think of it I'm terms of verts and faces. :) 

From today's point of view, it certainly isn't the best way. We all know the problems associated with this data representation. But in 1996, it was a different case because in QuakeEd, brushes were mostly manipulated by manipulating their faces. I'm not even sure it had vertex manipulation at all. 

Given a list of triangles, you've got no idea whether it's even a valid brush (convex polyhedron) without doing loads of maths.

With a list of planes - by definition, the brush is simply the intersection of all the inside half-spaces. Easy peasy. 

But with modern computers, those maths should be trivial? 

...let's just say this is a question of "how should the brush be defined for the purposes of editor manipulation?", which I think is the important issue here...

Regardless of how it is stored internally, in terms of user interface, you could try to treat it like a bunch of polygons - and I think WC/Hammer did that, allowing you to pull verts around willy-nilly.

However, this is pointless IMO, because all that means is you are exposing an interface that allows the user to produce an invalid brush. Now you either have to detect and prevent those manipulations - which simply means you might as well just go with Radiant-stype manipulation in the first place, or - in the case of WC/Hammer - go "sod it, let the designer spot the invalid brushes later and fix them himself".

This was basically the reason I ditched Hammer and moved to radiant. 

That's very annoying.

But I don't think its an issue that can ever be properly eliminated just because of the amount of tools and potential upsets in Quake.

We've all seen brushes that have no reason to provoke a leak, or deform weirdly when compiled. And then rebuilding the exact same brush typically solves the issue.

I still use WC for two reasons - the texture locking and general laziness to learn another editor. 

I think it was a good choice by Carmack for reducing user error. As was stated above, a brush formed via clipping planes is, by definition, convex. It has to be - or it's empty, in which case you can discard it.

The errors we see in maps are, I believe, a result of rounding errors and precision problems but the basic idea of how he stored the brushes was actually very smart.

Where it was a poor choice was in texture alignment control. If he stored actual verts, he could have stored actual UV coordinates along with them, and then we'd have some truly beautiful looking Quake maps because you could have real UV tools and make everything perfect. And texture lock would be the default action in level editors, not a specialized feature. 

But by today's standards, it makes operations like vertex editing and rotation very complex to do correctly. It's quite a hassle because the tool chain is not prepared for the brushes that modern editors can produce, even if they are correct.

As a programmer, I have to take care that what the user sees in the editor is actually what QBSP will produce after being converted to the halfspace representation in map files.

Also, the map format has nothing to do with "user error". The user should not have to look at map files. The editing software must take care that the user can only produce correct map files, and the compilers must correctly translate the map file into the representation the engine understands. Ideally, the user should not have to worry about this. And that would be much easier to achieve if you could store vertices in the map files.

The way it is now, the complexity is shifted out of the map files into the editor and the compiler. That's not a good thing. Ideally, the map file format would make it possible for an editor to precisely store in it what the user is seeing in the editor. But since this is not possible with the map file format, the editing software must not let the user create geometry that either cannot be represented in a map file or that cannot be reproduced by the compilers. A very complicated task, I will tell you. 

Hmm, I think by user error what I meant was tool errors. If the map editor can only spit out a set of planes, then it's impossible to feed a concave brush to the QBSP compiler. That sort of idea.

The guy using the software shouldn't have to think about it, I agree.