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? 

seems to be pretty shitty as a level editor. Who uses it? Madfox, trinca -- who else? 

JPL, too... Bring on the inquisition!

It seems it's a matter of proper configuring. The established Quark users here seem to have no problem with floats. So it's probably some bad default setting.

Most editors have a snap-to-grid function. This should take care of these things in one quick swipe - selecting the whole map and snap. Though there's still a small change some vertices might snap wrong and invalidate the whole brush. 

Quark is the most user friendly and feature rich editor out there. Period.

It fails sometimes on non-cubic brushes though. It is also rather slow and Windows only. 

I actually think it's a pretty good editor with a pleasant and user-friendly interface, and the tree-view is very handy, but because of some annoying quirks I'm contemplating on switching. Tried out WC with the Quake adapter but because of an extremely finicky setup (like needing Quake installed on the c: drive and I already have it installed on d:), I'm gonna try out radiant. Shame though, as the skew/vertex manipulation features are quite easy to handle in WC.

...although I still couldn't bloody figure out how to create those support beam things along a many-sided curve with correct width and perspective, the brushes always end up slightly disproportional and with an odd angle, even when using skew. It's fine and dandy when only working with 12-sided cylinders, but from 16+ it starts getting problematic. 

All right, I finally figured out how to skew with QuArK, but how the hell do you skew a single brush? The bounding box with the middle selection handles that allows you to skew (like in this screenshot MadFox posted only appears when selecting multiple brushes.