If you use 1.5, you put the .wad file in Quake\id1, Earlier versions you must extract the textures from the .wad file as jpeg's to Quake\id1\textures\WHATEVER, you must extract them so as Radiant can use them, use TexMex (or whatever you want), to extract them from the .wad as jpeg's, plus you must also have a copy of the .wad file in the same directory as your .map file/compile tools for compiling.

As to what version, I use 1.4, others would have differing preferences from the 1.2.XX or 1.3.XX series. It takes a little bit of messing around to get it set up, nothing to painful though, and once set up correctly Quake will be selectable from the games selection menu at start up. You'll need a map converter to convert between Q3/Q map formats and some compile tools. I prefer to use Sleepwalkers mapconverter, the non java version, if you wanted that version and can't find it, I can send it to you, and aguirRe's compile tools. All you really need to know can be found at the link below. It really isn't as complicated as it may seem, and once you have it set up, you'll be laughing.

http://industri.sourceforge.net/howto.php 

at http://user.tninet.se/~xir870k . Main features are a new ShadowSense feature in Light, updated Win/GLQuake engines with support for up to 64k clipnodes and a new enhanced Nehahra engine. Please also see readmes for more details.

Any comments are welcome. 

Thx for the info Vorelord, but i have already set up to versions of GTKRadiant, one with 1.2.13 and one with 1.5, i got it working now, both of them, now i just got a new problem, if using curves and whatnot it creates something called patch in the map file, and the converter don't know what to do with this, nor does the map exporter in 1.5. So it just deletes the parts made as patch, is there someway to convert patch to brush? since the curve features is really the reason why i want to use radiant 

You are not going to get curve/patch geometry in a quake 1 map. Fundamentally impossible. 

Maybe I misunderstand something, but isn't having curves/patches/other q3 bsp features the main reason for q3 bsp support in engines like Darkplaces? You can have a q3 bsp be a q1 map, so why wouldn't it be able to have curves and whatnot? 

Yes yes. You're talking about q3 bsps, which of course will run in DarkPlaces.

I was under the impression that Zalon somehow wanted a way to get q3 curve information compiled into a q1 bsp, which as I stated before, is not possible. 

that will accurately decompile Q3 bsp meshes to brushes. I use bspc myself. You will probably want to convert these brushes to func_walls if you decide to do this as they add quite a few brushes to your count.

Personally, I believe it isn't necessary though. Pingu's curves never suffered due to the fact he was limited to the Quake1 format. 

The float/integer-problems has nearly driven me insane, so ^^
I trust in your map-experience: What editor shall I choose for quake1-maps? I know it's quite a general question and I don't want any kind of flame war! But maybe you could give me some advices. Thanks;) 

I prefer version 1.5 (beta) 

How can you 'accurately' convert patches to brushes? Assuming a patch is just a set of control points, which can have a varying level of detail (depending on the settings in the game engine)? Who decides what is the 'correct' number of subdivisions/polys/whatever to describe that curve with brushes? 

as in not distorted to an extent that is noticeable in game, and the brushes are not divided to the extent that they are overly simplified.

I have converted all of the original Q3 Arena maps using bspc and then converted over to Q1 maps for testing purposes, and it works fine without a hic-up. 

moving ones, like the expanding intestine like things in Q3DM4 do not translate well. 

I contacted the guy who wrote the md2, md3 and Q3 bsp converters for Blender several months ago (http://scourage.servebeer.com/programming/blender/index.html) to throw some ideas around and this idea is something we discussed.

Mesh to brush conversion has been a holygrail of mine for a long time now, since that article advanced brushes appeared on Rust that makes it sound like the easiest thing in the world to accomplish.

Any inaccuracies of the fallowing are my fault and not his.

The formula would perhaps go something like this -- deviding the surface into trigs you determine the width and legnth of the mesh from the visibility set of the adjacent normals, with the normal direction being the eventual thickness.

Brushes are volumetric, so you will have to determine a volume of at least 1.0 when calculating the thickness (width * height(thickness) = 1.0) So, a trig side of .25 will need a height of .40 to be an actual brush.

After this, determine within the group of touching trigs which of them is the thickest (and therefore the smallest brush) and adjust the height for the other brushes of the set to this size for a more coherent brush model unit. 

Good to see you got it going. And like everyone has said, you can't use Curves/patches with Quake, well without using engines that allow it. Also somethng that I forgot about (Blame DooM3}, is that aguirRe's tools will do the Q3/Q map format converting for you (with the use of the switch), doing away with the need for a seperate prog to do that step. 

Is it my imagination, or do I recall someone once wrote a cool interface for QuakeC editing. Googling doesn't yield much. Any thoughts? 

somehow, i doubt it would be any good. i am pesimistic hero. 

I have a gangway over some slime made of bars.
Monsters (knights, ogres) can't walk over this bars. Is there any way to enable this?
Check the picture:
http://republika.pl/quake_1/way1.jpg 

If you mean that monsters fall between the bars, just uses clip brush in order to plug the holes... I can't see another way to do that... 

I want monsters to walk over the bars. The distance between bars isn't big. The player can walk over easily. I have tried to use clip brush to cover the whole thing but it didn't help 

over the bars and see if it works then or not. 

That's due to a bug in the monster AI... You can attempt to place a clip over those bars, may even that may not work... I know last time someone had this issue, the best solution was to place monster jumps at either end that just so slightly hopped them onto them. Still not a perfect solution, but may work with some experimentation.

Otherwise, you may have to bite the bullet and remove the bars, making a flat bridge for them to walk over. 

...and used a single clip brush that was one unit taller than the offending brushes. The clip brush is invisible to the player and the one unit difference is not noticable as a 'step' during play. The monsters happily walked on the clip brush.

That may help in this case. 

Line traces used in the walkmonster movement code are done in hull0, rather than the correct hull for the monster's bbox. Therefore, a monster attempting to navigate "broken ground" thinks he's a point object and therefore won't attempt to pass over small gaps in the geometry, that would otherwise be filled in the larger hulls. Placing clip brushes will have no effect sadly.

You could place an invisible, but solid bmodel in the gaps, and monsters will "see" it as solid, but it will block everything, including gibs and missiles, so that may not be the ideal solution. 

oh if that's the case, I stand corrected ^_^ 

Another suggestion would be to alter the design from bars to a grill, like the one in dm1 near the YA alcove. The monsters will still wander slightly erratically but they should be able to navigate down the length of the longitudinal brushes.