If you go to the view menu/toggle, select top, side, front etc, they will open, but they are stacked on top of each other, so just drag them aside, position and resize them to your liking.

Inspector window, no I don't beleive it can be closed,(well it can, but then you have trouble reopening it, without restarting the editor) you can manualy move it out of the way, a pain I know, I have started just having it on the lower right, and leaving it there, you can also double click the individual tabs in the inspector window, and they will undock, when you close them they automatically redock in the inspector window.

I have settled for one half screen for the autho veiews, quarter screen 3d view, and quarter view inspector window. I wish I could get rid of the Z window all together, but it just gets hidden out of view anyway. 

I wish it could be set up just like I use GTK 1.4 and previous. I have basically one window open at a time (maximised) and just toggle through the top, side and front views when needed, or ctrl/shift/c for the camera view, and you just hit T, O, or N to bring up the tex,con or ent windows, but alas........... having to use little windows makes me feel like I have to bend down and try to peek in, I much rather the full screen area (maximised) for each window, much better. GTK 1.5 doesn't seem to allow me to do this either. But beggers can't be choosers 

When looking at the "Carved In Flesh" thread here I noticed that cyBeAr also had the same problem with the positron gun with Win/FitzQuake, but DarkPlaces handled it better.

After some investigation, it appears to be fixable in the engine so I've done the same in my engines. It might still be a problem caused in QC of course. 

well... one could argue it is a problem with the engine, because, really, it should check and refresh the list when a change is made to an entity's solid type, however, it's easily fixable (by using a setorigin function right after) so it can also be argued that it is the qc coder's fault that he/she did not take this into account.
therefore, i'd suggest you actually leave it as it was (broke) so that when people test their mods out on your engine, they will get that error, find out what it is and fix it so it works in all engines.

0.02 ;) 

make the coders work for their crust! 

since the major goal with my engines is to be able to load (and play) maps that others can't, I can hardly leave it broken if there's an easy way around it.

Also, using my engines as a test for classic engine load/playability, is not really recommended since they have significantly higher limits. 

well, ultimatly it's your choice, but this is simply a bug that should have been fixed in the progs.dat. changing the engine so it doesn't complain about a bug that could have been fixed doesn't make sense to me. 

useful explanations of some BSP tech stuff, e.g. marksurfaces: http://forums.quakesrc.org/viewtopic.php?t=4056

Scroll down to Spike's post from today. 

Does anyone know where I can find a good, windows compatible editor for old school doom? I tried DCK v3.62, but it only works in DOS mode as far as I can tell.
Thanks! 

At least we can point you in the correct direction:
http://www.doomworld.com/classicdoom/utils/editors.php 

For a good, straight forward doom mapping tool, wadc is clearly the only correct choice. 

the best editor for classic doom is doombuilder
www.doombuilder.com 

Hey all -- I'm working on a Quake map for a mod, and I'm trying to set a door to be triggered by a button. I've done it a million times in my maps but for some reason, it's not working here. I've checked everything a million times and I dunno what's wrong. So I have given up, and I seek your help.

http://home.comcast.net/~teh_blitz/blitvbal.bsp
http://home.comcast.net/~teh_blitz/blitvbal.map

Thanks for your help. 

you've got two doors touching and being triggered at different times.

you need to check the "doors don't link" spawnflag so that each can be trig'd seperatly. 

dude, i've got some pretty funky problems with the light program...

i'm not sure what's going on... it happens on a rotating torus brush... basically, the brush should be lit more or less uniformly, but in-game, the top, bottom, left and right areas of the torus are the only parts the proper lighting, the rest is fullblack...
anything i can do about that?

also, would it be possible to have light.exe to check, not only target-targetname sets, but also target2,3,4 and targetname2,3,4 sets? (numbers to do reference each other, target2 can target targetname4, etc...) 

Thanks necros -- Lordhavoc told me the same thing right as read your post -- I totally forgot they were touching. My intention was to leave the smallest unit of space between them. Thanks. 

Rotating brush lighting: I've some faint memory that rot brushes are actually positioned in the middle of the map (0 0 0) and this affects lighting (of course). I don't know if it's fixable. Please send me the zipped map+wad and I'll see what I can do.

Multiple target checking: Certainly possible, but I assume this must be some QC hack to get it to work in-game, right? I'm not sure I want to adapt a standard light tool for a specific progs.dat.

I've not even disabled the normal light complaints about missing target lighting although it's in the standard progs.dat for a similar reason.

Would you also like to have the light style handling on these additional keypairs or is it just a matching check? 

I've some faint memory that rot brushes are actually positioned in the middle of the map (0 0 0) and this affects lighting (of course)

Hmmm...I had loads of rotators in Bastion and they all seemed to light correctly. (I was using the Hip rotator code btw). 

i think it might have been in custents where the brushes light like theyre at (0 0 0). Wait, didnt that use the Hip rotate code? I dunno. 

IIRC, the wierd lighting on rotating brushes has to do with the dynamic lights (e.g. muzzle flash, etc.), so it's more of an engine or QC problem. Static lighting should work fine.

I also found some wierdness where the position of the rotate_origin (I think) would affect the texture offsets. I may be able to dig up my example maps somewhere... 

i've been having some strange trouble with convmap (not mapconv, btw)...

mapconv packed up and left, spouting german obscenities, so i'm using convmap now, but when using the command line:
convmap -i -f32 mapfile
it refuses to write a file, however, if i omit the -i, and then say "Y" when it asks me if i wish to convert the file it will do it.

since i'm using this in a batch file, i'd like to get it to convert without asking me and requiring a keystroke...

any ideas? 

Grab this file and note the subtle differences in the map files and how they affect the dynamic lighting and texturing of the func_rotate_door (hipnotic progs):
http://planetquake.com/tyrann/files/rot_test.zip

(this is stuff I discovered during the OUM project) 

The ConvMap option groups are order sensitive; use the line convmap -f32 -i mapfile instead. The first group is the conversion group and the 2nd is the file selection group. It's certainly not the most user-friendly interface I've done ...

In the next version of my compilers you can omit the conversion step and use the new -q2map option in qbsp instead. 

I've got a level that has tons of monsters spawning in, mostly using func_spawn and func_spawn_small. Now, for some reason, some of these func_spawns (some of the last ones placed) spawn in monster_dog rather than the monster specified by spawnclassfunction and spawnclassname. See, but I don't want dogs I want ogres and fiends. Any idea on why this might be? 

[nt]