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. 

See aguiRe's Tool Tips file at http://user.tninet.se/~xir870k/tooltips.txt 

Ankhgod: it's 'ok' in that it only gives a warning and not a show stopping error, but the brush will only use the properties of the first face as defined in the .map source, which is difficult to tell in the editor. It's generally better to just use 1 type of texture per brush (solids only, water/lava/slime only, sky only). 

If you're using my compilers and if it's only a warning (i.e. one of the contents is Empty), it's caused by small brush misalignments and not any actual "mixed face contents" like mixing sky and *lava.

Brush misalignments are usually a good idea to look into and get rid of, otherwise they have a tendency to come up later as nasty clipping errors, HOMs etc. 

Simple map, added a teleporter and a target.
Now when I cross the 0.0.0 in the map I suddenly get teleported. This is not the place of the teleporter, which is at the outer edges. 

trigger fields are based on the mins/maxs of the trigger brush, it doesn't work like bsp collision.

I don't know if that is the problem, but it's useful info nonetheless.