thanks man, this is awesome stuff.

first of all, the engine is a great idea. there are times when every engine i try to use packs up and leaves. i doubt i'll use it for much playing, because it doesn't look like you've made it any more efficient than the regular quake, and i doubt i'll make a map specifically for it either because of that, but this should help immensly with testing and such. at least now, when i hit a limit, i can keep building and testing while i try to figure out what's wrong as opposed to just stopping and searching and waiting and such. :)

also, i'm a big fan of delay 5. i didn't use many delay 2 lights in my maps after i started using fitzquake, because the overbright feature would make the lights way too bright, and i realised that this must be what it looks like in software... being able to specifiy a max light limit is great, and Kinn rocks hard for coming up with something like that. (but thanks for implementing it in your tools, aguire)

i haven't really experimented much with the new minlight setting though... i try to stay away from minlight as much as possible. :P

cheers on excellent work! 

like he said in the readme, there aren't really any features for mapper, the only feature is that almost all limits that would normally crash quake before even letting you see the map are bumped way up (ie: edicts from 600 to 2048)

it's not really meant for normal play or for mapping specifically for. 

one thing i forgot to mention, Aguire:
don't name your engine glquake.exe, because it's not meant to be a glquake replacement. glquakebjp is perfectly acceptable ;) besides, it makes unzipping it a pain, because now i have to unzip to another directory, rename then copy it into the quake directory. same me some steps, eh? ^_^ 

I have experienced the same problems. I've also reverted back to using the beta 1.3.11 because I find the changes in the interfaces of the newer versions iratating and counterproductive to what I try to accomplish. 

The "GLQuake Mapper version" just means that its focus is on loadability and viewing of large troublesome maps.

Since mappers at one time or another create maps that indirectly (e.g. via leaks) or directly exceed normal engine limits, I hope this version is of special use for them.

It's not meant as a replacement for FitzQuake or other engines, just a complement. 

I toyed with the idea of making up yet another engine name but decided against it, since all my other tools also kept their original names.

Since I don't plan to make that many more improvements to this engine (unless someone finds a reasonably valid bsp it can't load), I hope it won't be too cumbersome with the file renaming.

I'm glad you like the tools, let me know if you have problems with them. 

Sorry I didn't spot the readme..it isn't in the zip. That sounds very useful.

Headthump..I fine with 1.4 but I definitely need to turn freelook on. I've reported it as a bug. 

Day of the Lords was one that I tested the engine capacity on. Sometimes when compiling that map you get a leak near the beginning of the map.

The resulting bsp is normally not loadable in any engine, but now it is. Just fly around and inspect the whole outside of the map when it's not removed by the compiler. Then load the pts file and you can find the leak spot immediately.

Even the old SoE map soe2m4 which was mega huge before Tronyn decided to split it can now be loaded and inspected for the leak trail.

Maybe the engine can also handle the upcoming project that Tronyn is working on. 

with 1.4 the default settings uses the QeRadiant standard 'delete - insert' for the zoom-in, zoom-out instead of the 'shift mouse drag' that is second nature for me now. Changes like that are a bit irksome though I do have 1.4 set up for Half-Life mapping. 

Yes I had that problem intermittently - strangely I got it to compile (without a leak) by slightly moving one of the entities in the beginning outside area. Not sure why that would work other than perhaps reshuffling the entity order in the map file. Where is the leak?

HeadThump-shift RMB drag does work in 1.4 in the 2d windows. 

we discussed before; the leak is in the rocks to the left of the entrance cave in the open area.

When inspecting the leak, it seems to be one of those that there really isn't any explanation of; all brush junctions seem OK (although a bit complex) in the area. By manipulating one of the brushes, the leak goes away.

My only guess is that it's the size of the map that finally puts the numerical errors in the float calculations over the edge. 

Hi dude, I'm glad you like delay 5 (and massive thanks to AguiRe for implementing it in his light program). What I find looks awesome is to use it in conjunction with "wait 2", e.g. for a nice, dramatic walltorch, try:

light 600
delay 5
wait 2 

I wated to synchroon func_trains, as I am using 5 related through eachother.
Found it somewhere at 3D-Inside, but lost it.

Can't find it...again. 

Anyone know if it's possible to change the keyboard assignments for gtkrad 1.4 upwards? Specifically I'd like to change the freelook camera move arrow keys to a wasd set up. 

you can create your shortcuts.ini file with your key bindings. this file should be placed in your q3/rad1.4 dir. 

but..the freelook controls seem to be really buggy once I've changed them. They work fine using the default arrow keys but with a new set up (actually esdf) sometimes they work, sometimes not, sometimes the key off doesn't work so the camera carries on moving. I've changed the other shortcuts that clash. Any ideas? 

not really, cuz i avoid using freelook. sorry.
i use arrows and ctrl/shift modifiers to move in 3d view. 

I agree! (although I use RMB + ctrl)..but non-freelook in v1.5 (Spog's q1 branch) doesn't support it. If you feel like it you could encourage Spog to add support by commenting in this bug report:

http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=1005

See also:
http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=1004 

make sure caps lock is not on, because that will affect letter keys.
also, the key releases for the arrow keys are bugged as well. if you press up and then 't' or something that brings up a window, the view will continue to move forward, even if you let go of the forward key. you need to close the windows and press the same key to stop it. 

Where's the best site for Quake 1 texture sets? I've tried searching google but it's all QUake 3 stuff coming up with the occasional Q2 bits. 

in the Definite WAD Collection thread: http://celephais.net/board/view_thread.php?id=11317 

A quick texture question. I have a texture that's 128 x 8 pixels, and it crashes Winquake. Keeping the width at 128, what's the smallest height for it to be valid? 

Textures can't be smaller than 16 pixels in any direction. 

I'm making a Q1 terrain map. All goes well until I'm adding the last sections of detail and refining gameplay when:


TreeQBSP v1.96 -- Modified by Bengt Jardrup

Input file: C:\quake\id1\maps\kellmet4.map
Output file: C:\quake\id1\maps\kellmet4.bsp
---- LoadMapFile ----
*** WARNING 06: No info_player_deathmatch entities in level
Title: "Blah"
18989 faces
3486 brushes
270 entities
39 unique texnames
271 texinfo

Building hulls sequentially...
Processing hull 0...
---- Brush_LoadEntity ----
*** ERROR 32: Face coordinate out of range (100000.000000)

1 warning

Elapsed time : 0:02

Peak memory used : 3.5 MB


The terrain mesh is 32x32, though I have a smaller section to generate separately and bolt on to one of the corners.
The terrain squares are 128x128 units. I was using 256x256 but it looks cack and makes traversing the terrain awkward.
There are three large bits of architecture on the terrain and several smaller ones. All of the large bits contain pseudo-curves ( domes and pipes ) only some of which I was able to make into func_illusionarys.
Compiling worked fine up until I added just a few more brushes for a small chunk of techy architecture and *wham*...above error.

I suspect I simply have too many surfaces in the map now and will have to prudently chunk some of my detail.
Is this the case? 

You do know that you can use func_wall instead of func_illusionary if you want to have collision detection for it but not block vis, right? I dunno why you were only able to make some stuff into func_illusionary, but if it's due to lack of collision detection then that might help.

Err but I think you knew that.