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] 

is it possible to get the quick compile menu to work with batch files so i can compile maps in q1 format right from the gtkr menu? i tried experimenting a bit, but gtkr started talking about not being able to connect to 127.0.0.0 (me) so i gave up... 

are you sure the spawnclassname *and* spawnclassname are set? the func_spawn from hip (and custents) defaults to a random choice of dogs, fiends, shamblers and a few others. dogs are the most common in the random pick, so it's possible you just had a coincidence and you saw the dog on those occasions.
beyond that, i've never had any problems with the spawner code and i used is *extensivly* in ne_os1 without noticing a thing. 

Ok, I've got breakable floors in my map, but I can't get items on top to fall through once the floor has been removed. Monsters fall through fine, but items just stay hovering in the air.

Now, items are MOVETYPE_TOSS, which means they should obey gravity, right? Does the engine make them static shortly after placing them in the level? 

might want to keep an eye on the # vertexes in bsp, if the value exceeds 64k, the engine will probably have trouble loading it. 

AFAIK the only way to get around that without weird level-based hacks is to modify the engine. The bug itself can be exploited beneficially (see Vondur's Zed and Zed 2). I also exploited it in RPGSP1 when I had a MH float in the air, but then had to use a weird hack where I had a func_door nudge it for it to obey gravity again. (The source to RPGSP1 is available at my site if you want to look at what I did.)

I believe I was told something about it being a bug in fall-to-floor. The level loads, the item falls to the floor, and then it stays static until something forces it to move again (pushing down, up, or sideways). As an example, if it's on a func_train that starts moving up, you have no problem. But if it starts by moving down, then it will float like you've seen.

If you bump the item before the floor breaks, I wonder if it would stay dynamic so that it would fall after the breakage. 

RPG - thanks for the info, although I have taken a QC-based approach.

I created new QC where the floor and the items on top of it are linked through target/targetnames (basically the disappearing floor targets the items).

Now, when the floor is removed, it searches through the entity list for the matching targetnames, and takes off their FL_ONGROUND flag. Voila, the engine assumes the items are now in motion, and they magically obey normal physics and fall through the gap. 

interesting post; i wasn't aware of the "bump to make it obey physics again" hack. 

The boss-gate, which only appears after receiving the sigil.

Right, then you got four boss-gates closed, and one finnishes the end-level.
At that point

what option does the changelevel of the end.bsp has, to return to the start-level without the boss-gates again?

I tried "jrstart" but it won't work.
I tried "start" but then the boss-gates are still there, although it's the same option as in the original game. 

(and if I had the time today, I would double check it for you, sorry) that it is hard coded in client.qc. You would need to change it there to get it to work normally if you are in poseession of the sigil. 

Take a look at http://www.gamers.org/dEngine/quake/Qc/progs1.htm and select client.qc 

While playing through Kona's Ultramarine map, I noticed that in WinQuake some textures on the walls were flickering considerably when moving around. Up close the texture looked as it should, but after moving away the texture changed substantially. In GLQuake everything looked OK.

After loading the bsp into TexMex, I noticed that this texture didn't have the same look in all its mip levels; some white stripes were missing. Re-miping the texture did the the trick.

I've never noticed this before, is there a reason not to have the same texture in all mip levels or is it just a mishap? 

he just forgot to remip the texture after making some adjustments.

i don't think there's any real reason to do it, unless you were looking for a very specific effect. (perhaps getting the textures to fade in the distance?) 

that it was for visual quality, I don't think I've ever seen the mip level switch so obviously. I first thought it was some switchable light, func_wall flickering or even z-fighting.

The interesting thing is that it's not visible at all in GLQuake; it appears as if GLQ doesn't use the smaller mip levels but generates them on the fly from the biggest texture.