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. 

mmmm, yes. that tends to happen... but i don't think the map would have started leaking after the check because it basically does what qbsp does. when qbsp gets wierd brushes with duplicate planes and such, it tends to mutate them much in the same way the check does, so it's likely that qbsp would "make" the map leak as well. course, there could be some exceptions... (aguire, any input?)

the nice thing is that after the check is done, it selects all the modified brushes, so you can check to make sure the modifications didn't leak the map or somesuch. 

for including my 'itty, bitty' brushes in the hull. Oh well. Live. Learn. Get Luvs for those messy spills. 

when qbsp finds duplicate planes, planes with no normal etc, it just drops the plane, it doesn't change it.

What might happen though is that when this particular plane is dropped, the brush isn't closed anymore (i.e. doesn't form a closed volume) and this isn't good.

In the latest version of my compilers, I've added a check for simple axial brushes (i.e. cubes) being closed. I haven't figured out how to check non-axial brushes.

PuLSaR actually had this issue in his upcoming map and when fixing it, the # clipnodes went down pretty much and in a big map this might be crucial.

I've also added some info regarding this in my latest ToolTips. 

Well, I had a very recent back up copy of the map and compiled that successfully - error gone.
The last brushwork that I was adding before the error, involved some cloning of existing brushes ( to get the same variations of texturing on the faces and lock the brushes at the same height; they were wide steps ) and I started to use Radiant's edge manipulation. As is sometimes the case, the brush disappeared instantly, indicating an invalid of some sort.
I ran bobtoolz brush cleanup and it removed the offending step straight away.
Thing is, when I continued to work on the same feature in the same area, I created and deleted some brushes myself, then CTRL+Z'd. When the brushes returned, some of their faces were white, like a point entity. No texture. I couldn't change the texture afterwards either.
So a combination of Radiant and my sickly HDD probably cause some mutant brush error that I couldn't see properly in Radiant to fix. Even brush cleanup didn't recognise it.
So anyway, not entirely sure what the problem was, but it's gone.

The map's coming along nicely btw, due in no small measure to aguire's bsp coping easily with my huge terrain mesh. Thanks for that :) 

I've added coordinates to that error message, should it appear again. 

I remember having trouble with brushes that were edited in Radiant and then disappeared. That was back in the olden days, and David Hyde used one of my maps as a reference for getting MapSpy to detect those brushes. Even though it's targeted at Q2, Mapspy can be very useful in tracking down rogue brushes of that sort. It outputs the brush number, which makes it pretty easy to track it down even if the editor isn't displaying that brush. 

Hey guys, I'm new here - glad to see there's still people who mod for Q1 ;). Anyhow here's my question; do Hexen 2 maps require special compilers designed specifically for them or can I use ones for Quake1 as well? I tried to use aguirRe's bsp and light compilers but light gives me this error for one map (I used it for another map and it seemd to light fine):

************ ERROR ************
LoadBSPFile: odd Model lump size

while bsp gives me this error for any map I try to compile:

************ ERROR ************
Invalid brush plane format on line 14

This is line 14 in the .map file:

( 3630 525 -105 ) ( 3630 524 -105 ) ( 3960 524 -105 ) rtex066 0 0 0.0 1.000 1.000 -1

Meh, I wouldn't be trying this if the people in the H2 mod scene didn't amount to my hand's digits :(. 

i'm afraid you have to use h2 compilers only... 

Thanks, Well I'll just be off to bug the dude making NewHexen, he's done some pretty good stuff with both the compilers and engine so far.

I may be back! ;-)