I suggest QERadiant. It's what I use. If you can get GTKRadiant to work with Q2, then use that. 

I just remembered that SleepwalkR has released the source for two of his Q2DM maps. Click on "Projects."
http://rem.fov120.com/ 

Has a build specifically for quake2, I just finished downloading it from radiant's website. 

It hit me like a thunderbolt as soon as I saw SleepwalkR's name above I knew it was he that peekaboom had mentioned on his website. Alas the links on the site are not working but a google search turned up files on source forge. woohoo! I feel like Homer Simpson after eating a dozen doughnuts. Mmmm...Doughnuts...

Thanks! FaT. 

... you've been very kind... But, does anyone know why Quake crashes when I enter the slipgates? I just can't seem to begin the maps.... 

but try this.
when you get to then end of czg07a, instead of going through the teleporter, type in the console: "changelevel czg07b" and see if that crashes quake. (it will have the same effect as going through the endlevel trigger, but you won't see your stats.) 

running fitzquake in 1024x768, with gl_clear 1
when i load my map there is nothing.
it's completly gray. i can still move around, and the world is there (i can hear my self pushing buttons and monsters firing at me) but i just can't see anything. turning off gl_clear gives hom.

i understand that the map is unvised and pretty big with lots of wpoly (12000 in one area) but i was able to load the map in tyrann's glquake. is there a max wpoly limit in fq or something? :P

vising the map did fix the fq problem... i'm still confused why one engine was able to load it while the other wasn't...

i also noticed a fairly significant decrease in frame render time in fq as opposed to tyrglquake... fq was doing the same 5000 wpoly scene at around 14ms whilst tyrglquake did the same scene at around 25ms.
what's with that big discrepancy? is it even larger on slower machines?

whatever you did to fitzquake, metlslime, i like it! 

please mail me an unvised (and zipped) version of that bsp; i'd like to check out the bug you mention.

As for why it runs faster on high-poly scenes, this has to do with me rewriting the renderer last version. I'm glad to hear that it worked. 

� 

In some maps I get a peculiar FQ message "Backup past 0" when moving in certain areas, what does it mean? 

that QuakeI doesn't support multitextures on single brushes. Never thought it to be a big deal nor necessary though UnReal based games do (Dues Ex, yummmm) support it. And then, just a moment ago I was fiddling around with a decompiled version of Mr Elusive's Start map for Tale of Abbot's Rune, trying to figure out how he set up those staged combats, and I stumble upon this,

{ //brush 2
( -832 8192 8192 ) ( -832 -8192 8192 ) ( -832 8192 -8192 ) sky4 0 -32 0 1 1
( -808 -8192 8192 ) ( -808 8192 8192 ) ( -808 8192 -8192 ) sky4 -40 -32 180 1 1
( 8192 928 8192 ) ( -8192 928 8192 ) ( -8192 928 -8192 ) sky4 -40 -32 0 1 1
( 8192 -8192 32 ) ( 8192 8192 32 ) ( -8192 -8192 32 ) sky4 -40 0 0 1 1
( 8192 8192 64 ) ( 8192 -8192 64 ) ( -8192 -8192 64 ) sky4 -40 0 0 1 1
( -7406 3522 8192 ) ( 7703 -2813 8192 ) ( -7406 3522 -8192 ) sky4 -40 -32 0 1 1
( -4340 7059 8108 ) ( 2034 -8033 8108 ) ( -2856 7686 -8196 ) rock5_2 0 -32 0 1 1
}

And my faith in the sigularity of Quake surfacing is shattered into a million atoms.

I tested this out with an attempt of my own.

// brush 6
{
( 64 256 0 ) ( 64 240 0 ) ( 64 240 -48 ) wiz1_2 0 0 0 0.500000 0.500000
( 128 256 0 ) ( 64 256 0 ) ( 64 256 -48 ) wiz1_1 0 0 0 0.500000 0.500000
( 128 240 0 ) ( 128 256 0 ) ( 128 256 -48 ) wiz1_2 0 0 0 0.500000 0.500000
( 64 192 0 ) ( 128 192 0 ) ( 128 192 -48 ) wiz1_1 0 0 0 0.500000 0.500000
( 64 240 0 ) ( 64 256 0 ) ( 128 256 0 ) wiz1_2 0 0 0 0.500000 0.500000
( 128 256 -48 ) ( 64 256 -48 ) ( 64 240 -48 ) wiz1_1 0 0 0 0.500000 0.500000
}
// brush 7
{
( -64 64 0 ) ( -64 0 0 ) ( -64 0 -48 ) wizmet1_2 0 0 0 0.500000 0.500000
( 0 64 0 ) ( -64 64 0 ) ( -64 64 -48 ) wizmet1_1 0 0 0 0.500000 0.500000
( 0 0 0 ) ( 0 64 0 ) ( 0 64 -48 ) wizmet1_2 0 0 0 0.500000 0.500000
( -64 0 0 ) ( 0 0 0 ) ( 0 0 -48 ) wizmet1_1 0 0 0 0.500000 0.500000
( -64 0 0 ) ( -64 64 0 ) ( 0 64 0 ) wizmet1_2 0 0 0 0.500000 0.500000
( 0 64 -48 ) ( -64 64 -48 ) ( -64 0 -48 ) wizmet1_1 0 0 0 0.500000 0.500000
}
}
And the compiled version did as I expected, no surface textures for the offending sides. So I have come to one canonical conclusion. If you are Mr Elusive, the rule do not apply. 

The decompilation is a faithful reproduction of the QBSP file (I use the Q3 BSPC-GUI for Windows 95/NT which never adds much glut when I decompile my own maps) and not of the map. So the liberties taken are in the compilation process. Whew, my faith is restored unless someone has more to add, 

don't look nice in msgboard format ...

Anyway, having different textures on a brush is absolutely no problem for Q1. As long as they're of the same type (solid/sky/liquid), they won't disappear or otherwise act strangely.

However, if they're of different type (like your example above with sky4 and rock5_2), you might get weird behaviour in the engine. This is probably a bspc (the decompiler) bug that normally needs to be fixed manually.

If you check out my ConvMap tool, you'll find a fixup mode that will help compensating for this bug. 

Good to know and I'll definitely check your tools out. Could the problem with my own attempt be the result of keeping the Q3 .500000 scaling? Perhaps, this is why I have had this misconception for some time. 

However, if they're of different type (like your example above with sky4 and rock5_2), you might get weird behaviour in the engine.

I had a map where I used a lot of brushes with solid and sky textures on them. There wasn't any problem with engine (even with dosquake). Only rockets couldn't pass through such sky textures, they acted like solid textures.

I hope you understand what I tried to explain :) 

to get a liquid brush with solid textures... i'm not quite sure how to do it, but i think as long as the last texture on the brush in the .map file is a liquid, the bsp program will treat it as a liquid of that type.

i was experimenting with this in my most recent map, and i might go for it with an animated texture. the only downside (but this could also be a plus) is that the unliquid textures of the liquid brush are not fullbright, so you need to light them as normal. 

I always knew it was possible in Q2 (with the edition of the surface inspector) and Q3, but I assumed the problems I've run into with Q1 multisurfacing was inherent in the engine. 

@R.P.G. & FaTbOy!: thank you for your feedback. It looks like the latest version of GTKRad-classic hates my system - I tried with version 1.3.13 and it seems to be working well. I've also mailed SleepwalkR and hopefully he'll fix the links, because id's base1 source isn't exactly what I was expecting in terms of build quality. Or am I missing something?

1. Is it worthless to clip brushes that are sticking out of playable area? I mean, doesn't this have a bad effect on performance?

2. I heard sky texture can be used in similar way as caulk in Quake 3. Is this true?

3. Should I care about aligning brushes so they fit perfectly like one should do when making Q3 maps? Is there any big difference between Q2 and Q3-mapping in this aspect?

4. Are there any differences between Q2's and Q3's hint brushes? 

anyone who watched the demo i recorded of xen's latest speedmap will see i had a lot of trouble getting onto the one func_plat in his map.

the way quake works for the func_plat, is it takes the largest coordinates of the brush and makes a cubic trigger roughly the same size of those coordinates. the reason i had trouble getting onto the plat was because the trigger is square while the brush itself was a triangle, thus, the plat was getting triggered too early before i could get onto the plat.

if you plan to do something like that, you should instead use a func_door and make the trigger yourself so you can control the size of it manually. or make a square lift.

cheers!

this small bit of info brought to you by necros... 

1. Clip brushes have no effect on proformance, they only serve to smooth out areas that may be rough navigating.

2. I suppose it could be... but I'd think it'd be better to use some standard textures and apply 'solid' content and 'nodraw' surface properties.

3. You should always align brushes neatly, yes. This applys for all Quake engines, there is very little differance between them in terms of how your brushes are split up in BSP.

4. There's a few differances I believe, http://test.gamedesign.net/book/view/52 shows their use in Q2.


and no, you're not missing anything looking at id's q1 released sources... they really are that bad of mappers... :D 

Looking at the source, that's coming from the function that does line traces through bsps. The comment nearby says "shouldn't really happen, but does occasionally." It's also a dprint.

From my quick glance at the code it appears to mean that a trace impacted a wall just behind the start of the trace. In other words, the distance to impact was slightly negative. 

info, it usually happens in areas with complex brush shapes.

Another question: If I noclip through a map, why does sometimes something push me up very high as if there was a trigger_push (there isn't)? It's repeatable and very annoying if I try to inspect an area of the map.

It's happened in several engines and it's really weird. 

Ahh.. thanks for the tip :)

Thought I could solve it by sticking the button there but it didn't work.. ah well

aguire I've noticed that too.. usually happens above lava, or at least liquids, i've found 

I think that's quake's "jump up out of liquids" code giving you a bump. But, since there's no gravity, you'll coast upwards forever. 

that connection with liquids, but next time I'll look for nearby liquid. My suspicion was that it had something to do with odd-angled brushes (or rather, planes), it think I recall it happening just outside tunnels (in the void).

It also doesn't push forever, it just keeps pushing until it thinks I'm high enough and then my pushing down suddenly starts working again. Hopeless fight though ...

There's also that weird phenomenon when in fly mode, suddenly moving speed gets extremely slow (inside map of course). Normally I have to leave fly mode and then back again to regain normal speed.