This is pretty much how I created most of the textures for my MOD, In The Shadows. Once I had a brushwork template I liked the look of, I did a print screen of the brushwork and then painted over it in PS. Added the new texture to my WAD and then tested the texture on the brushwork. After that it was a simple case of brushwork cut and paste.

I also re-used sections of the texture for variety detail and odd angles, so each new texture could be used multiple times and still be consistent.

This approach can create a consistency with architectural shapes and textures. It will also make a map feel like a designed location rather than a haphazard combination of brushwork and texture. 

" After that it was a simple case of brushwork cut and paste. "

Ah, the joys of proper texture lock that works.
Not really sure why I still use wc1.6a. 

In 3.3 you lose cross-editor compatibility and have to convert the textures to wad3?

...I still use it though :) 

Sock uses an old version of Radiant, I don't know how it works there, but the texture lock in new(er) versions produces decimals in the offset values which are not supported by standard QBSP. This can lead to textures getting misaligned by 1 unit in-game while looking perfectly right in the editor. Got to keep this in mind. 

When I say 'cut and paste brushwork' I do not mean texture lock/rotation. If you look at the architecture of my maps they are consistent, each arch, door or pillar is the same size because I cut and paste the brush shapes and then apply the texture afterwards.

I created the textures based on the brush shape so I only need to nudge the texture surface until it fits. This approach really makes a room/area feel like it is designed to fit together. When the texture and architecture are in harmony, the scene looks and feels better. 

Coming back to this after 9-10 months.

Anyone know how long the netradiant site has been down? http://dev.alientrap.org/wiki/7

My version is dated march 1 2012, but there is a bug with the 3-point clipper that crept into that version. Just wanted to know if there had been a newer build since then. 

Move to the latest version, it has better support and there is a coder actively working on it. They are always looking for people to offer feedback and get stuff fixed.

http://www.quake3world.com/forum/viewtopic.php?f=10&t=48330&sid=590f6d83bfd40da9dfdae6ea9aedaa98 

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.