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. 

what you mean, the trigger brush doesn't touch other brushes or is in the area of the 0.0.0 point. 

well, you are using quark.

i know quark uses some kind of trick to get trigger_relays and such to work without actually requiring a brush. it's possible you muffed up some how and maybe, renamed a trigger_relay to trigger_teleport (which would work in other editors) and not the trigger field is set to '0 0 0'. beyond that, i don't know... 

Describe the shape of your teleport trigger brush(es).

If you have (for example) a trigger made up from two rectangular brushes joined to form an "L" shape, then the trigger field would encompass not just the space occupied by the brushes, but also the space inbetween, defined by the combined mins/maxs of all the brushes that comprise your trigger entity. eg:

x p
x
x x x

say a trigger is defined by brushes occupying the 'x's - a player at point 'p' would still activate the trigger. 

the func_ gremlins screwed up that "diagram" somewhat, but just imagine the 'p' shifted along a few spaces to the right (above the last 'x' on the bottom row).