hm, indeed.

Oh well. The cubic clip hides most of the currently irrelevant stuff anyway. 

Just press I to invert the selection, then use H to hide it. Same result. Should have thought about this before posting. 

If selecting all entities of a certain classname in the entity list doesn't work for you, what about Shift+A? 

shift+a doesn't do anything in qe3 :)

that java text editor worked really well though. 

linux loves shammy,
pengui. 

too many beers after reading last post.

Quark. Yes. Still trying to credit Armino Rigo.
I was so glad with my no-warnings map in Quark.
Loading it in BSP made it 1864 warnings.
I wonder what Radiant will do. 

Yeah, forgot about the invert selection step necessary in some radiant versions...

Doh. 

> I was so glad with my no-warnings map in Quark.
Loading it in BSP made it 1864 warnings.
I wonder what Radiant will do.

Haha :) 

May sound strange, but reloading it in BSP the map had no hom's, as in Quark6.3.
Sad the side has stopped updating, as I use Quark from the first version'97.

What is this floating point error issue?
I know it has to do with not right placed brushes, not integers that are replaced, so mislignment is caused.
DMM seem to suffer from it, Quark has it.

It feels as if BSP is more accurate, although changing an editor is really hands crossed helpfiles. 

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.