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. 

Worldcraft I mean. It's not a difficult editor to set up. I deleted the prgram All_wads_To_HLWads.exe in favour of using TexMex to convert wads to Half-Life format. It's worth downloading the Hammer 3.5 executable, and dropping that in place of the Worldcraft .exe.

But as much as the QuakeAdapter makes it easy, fast and convenient to get you started, there is nothing stopping you from running Worldcraft from any DIR. You can easily configure it, and although I'm sure at the time Quakeadapter was put together it's compilers were the best current compilers - well, they aren't anymore. I have long since replaced them with better compilers (with the exception of TXQBSP which is *THE* best compiler. evar.)

I compile my maps from the command prompt anyway. Worldcraft gives the full location of the wad files in the .map file header too, so you can export your .map file to anywhere on your HDD and compile it from there, and as long as you leave your wads where they were when you were building your map, the compiler will find them.

If I were you, I would try running Worldcraft again.....

And there's always .BSP editor........ 

would copy pasting the same brush twice at the same spot, skewing and then deleting the spare work? 

Still didn't make it much easier to work with though unfortunately, as when I'm dragging vertices in one view the editor always seems to compensate for it, like here where I tried to align the vertices along the curve in the top view and the lower edge got dragged downwards. That was just an example image that I threw together to show what happens and not a serious attempt at creating a curve, but this is what happens no matter what I try, and skew didn't seem to work around this either. Oh well, time to try out WC again then I guess, where this is unproblematic... 

I think Quark is also a great editor, but has some purposely corrupt coding is in the export to .map - This problem is easy to solve with copy and paste. The arches in func_city_04-13-11 are set at 2 unit resolution, something trinca said he avoided. On export, Quark goes through "extra software mutilation code" to get to it's .map file.

So forget the float precision, Quark doesn't even let you get 2 unit precision on angled brushes. 

I work with Quark since it was an early Qmap version in the late 98, so I'm very contributed to it. Skewing with one brush only goes by setting angle of a brushside.
But then you miss gridclipping of course.

My simple outcome is when I make a map In Quark with complicated brushes the leak error grows.
When I import the same map into WC1.6 and it compiles well with the same compilers it reduces Quark in compare to the WC1.6.

I'm doing with QRadiant and it is a RTFM job to get familiar with.
My interest grow to BSP which has an update to 96, since I learned to know it in QBSP94b. 

sorry i didn't reply earlier, but it appears necros did a pretty good job of explaining everything you asked. 

Yeah necros got me on the right path (thanks again), just fiddling around with different techniques at the moment.

Also got Hammer 3.5 to work with Quake, had no idea it was even compatible, so thanks for the tip Ricky! Although I did encounter something strange... made a test map, saved as .map and it compiled fine, closed the editor and later when I opened the map again it was completely empty. I guess it's not much of a problem as I can save as .rmf just fine, just found it a bit odd.

And bear with me here, but how do you make the extra parameters for the compile tools work in Hammer? In the advanced compile menu I wrote "-soft -extra 4 -gate1" without the quotes as a parameter for $light_exe, but it doesn't seem to do anything. Light 1.43 by Bengt Jardrup.