here's what i do:

you have two identically ratio'd curves:
http://necros.slipgateconstruct.com/temp/ed1.jpg

in radiant, and probably most editors out there, edge selection will show the center of a brush's edge:
http://necros.slipgateconstruct.com/temp/ed2.jpg

choose the width of the cross piece you want to add (here, it'll be roughly 32 units)
http://necros.slipgateconstruct.com/temp/ed3.jpg

remember to keep in mind that making a diagonal this way makes the brush slightly thinner. however, that's less important than making sure you choose points that line up on the grid:
http://necros.slipgateconstruct.com/temp/ed4.jpg

skew your cross piece brush so the side that buts up against your curve is parallel.
use the edge handles to align the centers so that your crosspiece sits in the middle of the brush:
http://necros.slipgateconstruct.com/temp/ed5.jpg

now, simply stretch that brush outwards to meet the outer curve, again, using the edge handles to align the crosspiece to the center of the outer curve brush.
http://necros.slipgateconstruct.com/temp/ed6.jpg

boom. done.
http://necros.slipgateconstruct.com/temp/ed7.jpg 

i left the brush offset by 1 unit so you can see the relative positions, obviously in ed7.jpg, i slid the edge back the 1 unit to connect it properly. 

That's quite ingenious. Maybe one of the reasons I haven't been able to do this is because there is no skew function in QuArK as far as I know. Maybe I should just switch to radiant or something... 

if you're working with 12 sided curves, it makes things much easier too, because you know that every 1/4 ratio'd vertex will be on the grid, so you have a lot of selection when it comes to deciding where you want to place the crosspiece corners and then the middle bit of the curve that's on 45 degrees is of course simple, because the whole edge is on the grid. 

Yeah I figured, been using mostly 12 sided curves throughout my map. As I mentioned I've had to cut slopes into two triangles if I want to place them alongside a curve, otherwise this happens when using vertex manipulation in QuArK: from this to this. I imagine being able to use the skew tool would circumvent this as I've seen sloped curves that are a single brush and not cut in two, again using the dam as an example.

Could you confirm if this works in radiant? If so I'll just switch over immediately as it would make working with such architecture a hell of a lot easier, and QuArK has a few annoying quirks and bugs anyway. Also, how good is WC for mapping with Quake and advanced brushwork vs radiant? 

don't do that. :x the outer edges of the brush won't match the curve. then you'll have to manually resize it.

what i do is first make the sloped brush whatever size, but being on large grid makes it simpler.
then i skew the edge so that the inner part matches the curve:
http://necros.slipgateconstruct.com/temp/ed8.jpg

then, i extrude the face outwards so it goes far past where it should end:
http://necros.slipgateconstruct.com/temp/ed9.jpg

with the clipper, i just lop the extra parts off, by following the same line as the curve itself:
http://necros.slipgateconstruct.com/temp/ed10.jpg

to complete the curve, i take the bit i just made, copy it, rotate and mirror it so it fits on the bottom part.
then, i copy the same part, and skew it so that the inner edges match (just like before) but now the leading vertices will be fucked up, so i just grab those and put them where the previously placed vertices (from the first 2 sloped brushes) are.
http://necros.slipgateconstruct.com/temp/ed11.jpg

this took me about 10 seconds? 20 maybe. 

Yeah I've used that exact method before when mapping with Hammer, but when I attempt the final step of aligning the vertices with QuArK I always get the fucked up brushes like in the image I posted for some reason, so I always end up having to split the brush in two. That's why I wanted to know if it works properly in radiant. 

curves are generally easier to deal with using Radiant over WC/ other editors? 

maybe there's something i missed, but i don't think WC can extrude a face out/inwards along the axis of it's edges. it can only stretch brushes which is, afaik, completely useless. i don't know why you'd ever want to stretch a brush in that way. what i mean is:
http://necros.slipgateconstruct.com/temp/ed12.jpg
top brush is the original. when you try to resize the brush, note the angled edge's profile is destroyed.
i don't know any way to prevent this behaviour.
i seem to recall czg's curve tut relied on this odd deformation, but since it's completely possible to replicate the curves with extrusion, there's really no need for such a strange method of brush manip.

so yeah, for that alone, i find it much easier to make curves in radiant.
once you've got a curve of one radius, you have a curve of ALL radii, since you can just extrude faces out/in.

in those little clips i posted, the brush for the outer curve was the same as the brush for the inner curve. i just pulled the top edge upwards and then pushed the bottom edge up to match the width-- the length of the brush was preserved relative to the size of the curve. i don't think that's possible in WC.

otoh, if it IS, someone PLEASE tell me how. it'll make my hl2 mapping a lot quicker. i always change my mind about working on hl2 stuff because i dread using wc brush manip. :x 

is that it works with multiple brushes selected; i'm not sure radiant can scale multiple brushes like that at once? so taking an entire corridor and curving it round becomes possible (via czg's stretch & skew method)

for individual brushes i just use VM.. just a case of selecting all verts at one end and either dragging or nudging using the arrow keys, like so

of course once you skew the brush it becomes a tad less simple, but seeing as i only ever use this kind of 12-sided curve (ie. flat at the top/bottom/sides) the only diagonals ever needed are either 2:1 or 1:2, which is easy to keep track of when pulling or nudging vertexes around. likewise when you are lining them up round the edges of a curve, the diagonal between the point and the centre of the curve will either be 1:4, 3:3* or 4:1, so nudging vertexes becomes simple. see 1, 2, 3

(in this example however you'd have to clip it at a 4:7 ratio, which is a lot less user friendly (and neat :) ))

for 24 sided curves i use this; again just a case of remembering the diagonal ratios.. 4:1, 2:1, 1:1, 1:2, 1:4, joined from the corners to the middle at 1:8, 2:5, 10:13, 13:10, 5:2, 8:1. bit harder to remember that one admittedly ;p - nudging vertexes can be a bit of a headache. but that's the price you pay for sexy curves, alas

(* - technically 1:1 but putting 3:3 keeps it in scale with the other two) 

otherwise this happens when using vertex manipulation in QuArK: from [this] to [this].

that's weird.. i don't know about radiant but in WC, VM would work fine so long as the inner and outer edges end up parallel. even if a user mistake means they don't end up parallel, WC can still render it illegally - it just won't export to .map properly. so you can always correct it later (the vertexes will still be where you left them in the .rmf)

i don't really know how radiant handles vertexes but i remember one radiant user being surprised at learning how lenient WC's VM is when it comes to illegal brushes; so i'd guess radiant's is more strict and less flexible? judging by how most radiant users seem to avoid VM for stuff like this, that would seem plausible :) 

24-sided curve - again flat at the top/bottom/sides 

A texture is scaled (shrunk) too small somewhere. For textures 128 x 128 and bigger, don't scale lower than 0.5 - and for 64 x 64 textures, a scale of 0.25 can be safely done. Test what works and look at Bengt Jardrup's Tool Tips text for more. 

Radiant does vertex manipulation fine, but at least GTKR 1.5 doesn't like illegal brushes, and sometimes doesn't quite join vertices the way you'd expect. Using translate sometimes helps, or clipping, or generating a new brush that's closer to what you want (cones and stuff like that).

For general purposes, Radiant's VM is fine, if probably different from Worldcraft etc.

I use it quite a bit, combined with edge manipulation. 

Well i try everything and i see everything and again same problem :( 

Man i delete the Arch and it works fine but how i can do arch's and curves when i try and maps just.....failed 

I tried the curves from czg in Quark but the possibiliy for skewing is rather detached.
From the first example everything is right
one
When I start skewing
two
happens and I'm broke. Quark starts warning for leaks whlile WC1.6 compiles well.
So I had to do the thing with substracting and this ends in bad lightning.
three 

good to know at least that i haven't been missing something obvious. :)

for individual brushes i just use VM.. just a case of selecting all verts at one end and either dragging or nudging using the arrow keys

yeah, this is what i do. but it's a lot slower than just grabbing the edge and dragging it. in radiant, it's one step: click anywhere outside of the brush near the edge, and drag.
in wc it's multiple steps
select all the vertices, then click + drag.
also, WC's obsession with control points is annoying. i prefer radiant's 'click anywhere in this area' method of moving. i mean, obviously, vertex manip uses control points too. but you can avoid having to use it by having the ability to simply drag out faces of a brush.

to be fair, i'm still not as familiar with WC as i am with radiant, so i'm sure a bit of 'slowness' or clunky feelings i have for WC is still due to that, but even factoring that in, i still find radiant faster.

otoh, i do like how WC doesn't complain about a brush until later. radiant runs it's 'brush legality' checks while you're manip'ing vertices. it's technically more accurate since it'll never let you screw up, but it also stops you from making a shape that would be legal but requires moving through an illegal form first.
WC will just let you do whatever so in general, it's easier to make super complex geometry out of single brushes.
doom3's radiant is even worse for some reason, because it won't complain, but you can actually rip brushes apart (like, the faces become unconnected somehow). very weird. 

It certainly comes from the "famous" floating point feature support that QuArK is suffering from...
Except if you have some time to waste, you can inspect all polygon corners' coordinates and try to realign it on grid.... but not sure whether it will solve the issue... though... experiment ;) 

Mans, you just need more practice. 

Mans, you just need more practice. 

One of the maps suffered leaks in Quark6.1, while starting it up with WC1.6 gave a good outcome. It only shows that with the same compilers the editor always is the weak link.

I just find it odd to see those examples and trying them out only ends up with peeling out the manual where I can find my purpose to the buttons. Sometimes they're there, others not. 

the more i think about it, the less likely i think that the floating point stuff is the issue.

a little while ago, i found that qe3 worked better with floating point enabled. aguirre's bsp was fully able to cope with decimals with even the most complex tri-souping.

i think it might be that quark is mangling the brushes in some other way that may not be immediately obvious. 

Is there a full guide somewhere to getting radiant set up and working for Quake? I'm curious to give it a try. I'm very comfortable with WC atm, but if fiddly manipulation is better in radiant it'd be nice. 

It's Quark's export to .map software code that is messin around wit your minds. It does not copy and paste the map coordinates from the .qrk file to .map

I opened func_city_04-13-11.zip in the Bsp editor with all brush coordinates exactly as would be seen in radiant/qe3. Then I opened the Quark revised func_city_04-15-11.zip. If you look at the alpha windows, which were not edited at all in Quark (only exported and saved), you'll see they are messed up. On top of that, Quark basically took quite a few on-the-grid brushes off the grid also. These files are in the Speedmapping Thread.

Wouldn't simple copy and paste code fix it?