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. 

This will be because of Texmex; if you paste a texture into a wad then alter the graphic later, TexMex prompts you to 'generate new submips?'. One assumes that in this instance, Kona selected 'No'. 

I also had an interesting TexMex issue when loading the bsp, re-miping that texture and then exiting and answering 'Yes' on save file.

After loading the bsp and checking out the weird texture in WinQuake, it was still not re-mipped. Then I noticed that TexMex had saved my changed data into a new wad file instead of the bsp and forgot to tell me ...

Btw, after inspecting the GLQuake source, I think I can confirm that it doesn't use the smaller mip levels but generates them on the fly. 

Yeah, it's just another example of why you should always playtest your maps in both Gl and software engines. Kona's maps also sometimes suffer from stray fullbrights; another glitch that won't get picked up in vanilla GlQuake. 

is it normal, when loading a map with excessive clipnodes into aguire's glquake, for doors to become non solid? they still blocks rockets and grendades, but the player can walk through them... 

I'm experiencing the exact same problem in all engines I've tested my map in (aguirRe's, DarkPlaces). 

I have something truly strange going on in my map: as soon as the map loads, you hear the sound of an opening door although no door is opening and when you move around the first room of the map you hear the sound of a lift. There is no lift nearby... Does anyone have any idea what could be going on? I've tried fullvising the map, but that didn't help. 

The clipnodes are directly related to the clipping hulls for collision detection so it seems reasonable. Rockets and grenades are point entities and clip against hull 0 (visible hull). 

As far as I know, TexMex won't let you save the .bsp if you've made any changes to it, with the exception of pasting a new texture or submip image over the top of an existing one. You can't add, remove, rename, resize, or remip textures and then save the BSP again.

I might be wrong about the remip thing though; try specifically saving the file as whatever.bsp as the default behaviour for TexMex (with BSP files) is to save the file as mapname.wad anyways, since that's usually what you want to do. 

Thanks for the tips, I solved it by taking the wad TexMex generated and run it through the updbsp tool, which updates the bsp with the new wad. 

Is it ok to have mixed face contents in a Q1 map? I know what causes this warning in my map, but would like to leave it this way.