pics to demonstrate, please? 

I just installed GTKRadiant to try some Quake editing, and I set up the paths all right, but it won't load any textures other than the SHADER NOT FOUND one. When I look in the console it says:
Texture load failed: "textures/"
Any hints on what could be going wrong? 

In the latest version of GTKR 1.5, I just put the .WAD files in C:\Games\Quake\id1 and point the editor to C:\Games\Quake for the game engine path. 

How do I extract the WADS from the PAKS? I've tried several programs but I can't see any .wad files anywhere... 

the wads aren't in the pak files at all, but you can get the textures from the individual BSP files.

But you can also get the wads here: http://www.quaddicted.com/wads/ (look for "quakewad" i think") 

Downloaded the quakewad file and put it in id1... Now works perfectly! Thanks! Although you need to rename the quake101.wad to quake1.wad. 

What light program and command line options? How many light entities? (relative to the number of brushes maybe, just to give perspective). Do you use minlight or skylight or both? How long does it take to run the light part of compiling the level.

I'm real curious about this cause I read a post where Than said the Plumbers Carry Shotguns level took about 25 seconds to light, and my current map is taking almost 10 mins for a high quality pass. There were 2758 brushes and 16621 faces at the time of this run:

----- Light 1.43 ---- Modified by Bengt Jardrup

Extra 4x4 sampling enabled
Soft light 3 enabled
Soft distance 16 set
File: c:\quake\id1\maps\wish16.bsp
Using minlight value 15 from worldspawn
1079 entities read, 625 are lights, 13879 faces, 3.9G casts
4 switchable light styles

lightdatasize: 467 kb

Elapsed time : 9:58 

Many of my maps have taken double that (like 20 mins) in the past.

Plumbers Dont Wear Ties is a detailed map, but not too detailed, but also its not really that big. Its a realistic scale, and its condensed, but its not very big compared to say the Warp maps or Marcher Fortress. Load Bengts engine and load the Plumbers map and type into the console "lightmaps" and try it with your own map too. Lightmaps are if you like "X amount of texture worth of light info", so the bigger the map (so long as the texture scale is 1:1) the more lightmaps.
Also if you have plenty detail in your map that wont help the speed (but it will make the map look sexier :).

I wouldnt worry about it too much! 

I probably should have mentioned I used a Core2Duo e6850 (2x 3.0 GHz) with 2 GB RAM.

I wasn't worried really, it just seemed like 25 secs was way low for a map like that. I ran id's e3m1 this morning with the same settings as I used for my map and it took 2 mins 14 secs.

Anyway, I'm still curious how other people light their maps. 

this is my understanding of the issue...

When you have multiple lights with inverse falloffs hitting the same surfaces over a long distance, the light time tends to go up. With inverse and inverse square falloffs, the light level never completely hits zero, so if a light using those formulas is in a wide open area, all the surfaces within line of sight of that light have to be calculated, even if the light level only increases infitesimally.

APSP2 was a fairly narrow and cramped map, so while it was detailed, none of the lights had to cast very far.

The extra 4x4 sampling and soft stuff increases the time as well. But thankfully, light calculation time is not painfully exponential like vis, it seems to increase fairly linearly. 

Rick: are you sure Than didn't say 25 minutes? to me, that would seem more realistic for a map of that size with the amount of lights present. but maybe he just has a monster machine...

grahf: aguirRe and i had a discussion about this kind of phenomenon with inverse square lights. mostly it was regarding how using that delay type with switchable lights could quickly run up to the max lightstyles on a face warning.
he implemented the 'fade gate' command line. essentially, it will cut the light off once it's light level has been attenuated below a cutoff point.

setting -gate 1 on aguirRe's light util will cut down on lighting times by a large margin because it's disregarding a lot of lighting that wouldn't even be seen.

back to Rick: as for light utils and settings, for preview compiles, i use:
light -gate 1.0 -fast -soft
and final compiles is:
light -gate 1.0 -soft -extra
i don't use extra4 though, because that is just insane and will take millennia to compile. aguirRe recommends -fast -soft -extra4, but i haven't tried that yet.
it's really worth your time to look through all the info aguirRe has on how to use his tools: http://user.tninet.se/~xir870k/readmevis.txt the lighting tool has a huge amount of options in there. 

Yeah, extra4 basically takes about 10x as long on my maps, so for a quick look I don't use it, with just -soft it'll light in about one minute.

I did read through all that documentation and it was very helpful, I've been experimenting with a lot of the new stuff.

I wasn't real clear on the Gate thing, but now I think I understand it. I'm also not certain exactly how the -softdist is supposed to be used, but it seems like I get a lot fewer of those abnormally dark faces when I use that option. The documentation (I think)indicated using small numbers like 3 or 4, but I've been using -softdist 16 

i guess it's impossible to change the player model's angle without having to use fixangle = 1 (thus changing the angle the player is looking?

it seems i will have to replace the player with an invisible sprite and then make a dummy model that follows the player's position in order for me to get the results i want? 

but you probably need to use an .mdl, otherwise there might be engine issues (i know the weaponmodel expects to be a mdl, not sure about playermodel) 

i got it working with a sprite so seems everything's ok.

btw, your chase camera is kind of wonky and is prone to being shaky at times. it seems to pick up on stairs and angled floors in front of the player, where the crosshair is pointing or something. just fyi :)
i've also noticed a bug with the camera where, if you are looking down, and the camera is higher than the player, and you enter into a tunnel where the ceiling is lower than where your camera is, the camera goes psycho and starts moving in huge arcs outside the map. (this is with chase_up set at 32, which is higher than the default) 

yeah, it kind of sucks. I sort of stopped trying to fix it once i realized it's pretty much a gimmick and Quake is better in first-person mode anyway :) 

Cannot compile in GTKRadiant 1.5 for Quake. Anyone know how to fix this for GTKRadiant 1.5? 

Try the "search on this page" option while vieuwing all posts of this thread upwards with the word GTKRadiant. 

but helpfull. 

just looking around at the quake sources.......

how the fuck did they get any of that to even compile? o.0 

I know it's easy to point and laugh at the original Quake maps but those guys built some pretty cool levels with technology that was changing on a daily basis. That's tough to do. 

Not to mention the primitive tools. QuakeEd was ... pretty rough. 

i'm not laughing. i'm serious. the original qbsp was incredibly finicky which is what taught me to map with incredible precision making sure everything lined up properly etc etc.
looking at maps like e2m2, it's almost like divine luck or arcane power that would have allowed it to compile without exploding. 

But when you look at it you can see that they're at the minimum level of compilability.

Which means each of those maps must have undergone loads of iterations to reach that level, probably starting with something resembling Escher vomit.

Like Willem says, after ten years of trial and error with bsp it's impossible to make a comparison. 

I constructed a terrain map with triangles.
After fitting all polyhedrons well tight the light seem to cast all kind of rare shadows.

Is there a way to avoid this odd behaviour?