I dont use last version to...

6.5.0.7 is the one I use... very nice... updated some times but always return do this version 

It's not a Quark floating point error, it's just the way Quark is making maps for Q1. Enliten's Quark map (just posted) has a brush coodinate of:
( 68 28 -0.00002 )
Quark purposely put a brush edge at -0.00002, and not snapped at 0.00000. It's not an error.
There might be a setting in Quark to avoid this. I donno. 

It's possible to change the coordinates back to integers in the viewwindow. Sometimes it works, not with wedges and noncubiks.

Quark tends to have a wicked leak error. Replacing cubes helps, but as I entered the 38767 clipnodes, I gave up trying to understand what went wrong with replacing the same volume of polyhedrons and getting weird outcomes.

BSP give a lot more warnings, but it are all healpoints. 

I posted on quark forums some time ago:

Quark etp means that it writes a lot of decimals in the .map file which means that you also need tools that can handle those decimals. Also you will run into troubles such as hom effects leaks very easyly when your map gets more complex and the compile time can increase insanely.

Classic Quake -> no decimals. Faster to prozess for the tools better framerate ingame, cleaner. But it also means that you should stay on grid. at least 8x8 or 16x16 is really recommended. 4x4 and 2x2 only for details. It's also recommended not to use things like rotation angles other than a multiple of 90� or quick object makers. You won't need more for quake1. I use this format.

Valve 220 is hammer/worldcraft format of the .map file. use this format when you open maps that were made with hammer/worldcraft.

Brush Primitive, I think it's radiants format

also check "Don't write floating-point coords"
and "Use Integral Vertices as Threepoints"

I should start mapping again during winterbreak, want to finish something.
Studying Architecture is really time consuming :-(
and playing with blender keeps me from mapping. 

http://www.file-upload.net/download-3002835/nofloats.zip.html 

I used Quark a lot with turning side angles and then forced to grid, which caused a lot of offgrid brushes. I once even took the time, to correkt them all with notepath.
Snapping corners to grid seems to be more usefull as the poly keeps its integers.

Link seems to have a Qsoll error. 

Grid and rotation and map format.

Valve 220 needs to die - imagine you work in a team, and someone wants to open your map file. Eep. Problem. That's just a no-no.

Grid: You can use 1 unit for stuff, that won't break, at least it hasn't broken anything for me yet. I use 4 unit grid regularly for example after rotating stuff etc. I used 2 unit a lot with Radiant's Polygon Builder plugin. The stuff it created needed to be snapped to the grid, and anything above 2 unit grid deformed the polygons too much, so I snapped the whole crap to a 2 unit grid and checked it afterwards by zooming in and controlling all vertices.

I build ladders and handrails on a 2 unit grid regularly. Nothing breaks.

1 unit is usually only required to get tricky stuff working or to build really thin stuff.

Rotating things... this can indeed create problems. Loading an external .mdl or .bsp and rotating that instead (via angle or mangle) might be a better option than to rotate world brushes by a crazy angle. Lighting those is tricky, though. 

the heck's valve 220? rmf files? 

1 unit doesn't break
but imagina a brush that has every vertex on 1 1 grid:
the brush is defined by planes not vertices, so it may result in floats easily.
And if you force the one unit grid, the vertices are NOT on grid 

Valve 220 is hammer/worldcraft format of the .map file 

not present in 1.6, which uses normal map format

didn't someone write a converter a while back? 

doh. :P thanks. 

Scrama wrote a converter that I couldn't get working, IIRC that was the only converter at the time where we had the problem. Baker or someone similarly capable might have written another converter since then, I can't remember.

On top of that I use Linux, so not everything that's written on Windows runs as it should. That's why I'm going to install XP, actually I'm in the process of moving. I'll keep a Ubuntu system as well though.

And now I'm ranting. (stops ranting) 

Scrama wrote a converter that I couldn't get working, IIRC that was the only converter at the time where we had the problem. Baker or someone similarly capable might have written another converter since then, I can't remember.

On top of that I use Linux, so not everything that's written on Windows runs as it should. That's why I'm going to install XP, actually I'm in the process of moving. I'll keep a Ubuntu system as well though.

And now I'm ranting. (stops ranting) 

hm, I only clicked Submit once, pretty sure. 

That's why I'm going to install XP

finally. welcome to the darkside 8) 

yeah, rub it in :-)

I'll see about getting l4d installed. 

http://www.leveldesign.nl/viewtopic.php?f=9&t=86
Games: Q3, UTs -> ergo: meh 

50 brushes was hard enough! With 20 brushes you could have two rooms, a corridor and a couple of crates, then you are done! Boooo-riiiing (yawn) 

4. Decals and custom sounds are also not allowed. 

It's about DM maps. This reduces the need for complexity somewhat. 

20 brushes DM map? That's actually an interesting challenge IMO.

Box to kill people in, and a bit of cover. 

... errr, it is quite small considering a mapper need at least 6 brushes to build a box... So basically you may have a box-room + 2 crates, and you're done.. sounds quite poor mapping :( 

You lack imagination...

http://www.chaosquake.de/files/contests/20bcvol2/#intro 

... errr, it is quite small considering a mapper need at least 6 brushes to build a box... So basically you may have a box-room + 2 crates, and you're done.. sounds quite poor mapping :(

sounds quite poor maths as well ;)

it's a neat concept. just requires a little bit of thinking outside the box, both figuratively and (almost) literally