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. 

I don't think I've experienced that error before, but I've seen it mentioned at QuakeLab http://www.planetquake.com/QuakeLab/bsp.htm . The original error message was CheckFace: BUGUS_RANGE ....

It appears to be a face that the compiler thinks is too big. I can't find any limit that indicates that there are too many of anything.

If you wish, you can send me the zipped map+wad and I'll take a look at it. 

RPG: yeah, I know the difference. I just prefered illusionaries in this case because of the collision thing as well. I can then build simpler, rectangular solids inside them ( out of clip or black ) to approximate collision.
By 'only some ' I meant, there is some pseudo-curved stuff that needs to be solid to cast shadows, or interiors will look floodlit :/

aguirRe: thanks, I may send it to you. I hope it is something to do with size of a face rather than total number; the map's almost finished and culling superfluous detail always makes me anxious.
I'll have a look around the map when I get home and send it to you tomorrow.

Thanks for the info guys. 

that's done the trick :) 

you can run the map through the brush checker and it usually gets rid of busted brushes. 

Last map I brush checked like that started leaking like a sieve.