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). 

shape of the teleporter: 1291 6 695
teleporter destination : 2291 288 500

The error occurs when one passes point 0.0.0
in the map. With the teleporter itself is nothing wrong. 

is your teleport trigger just a simple rectangular brush? 

cheque your email 

to be just two orphaned trigger_teleport entities without any brushes attached. The engine (or QC) probably just put them at (0 0 0) and hope noone will notice. 

hi, just got your email. Dl'd and installed your pak. I managed to find the "Facade" map and the area in question. To be honest, it's a bit difficult to troubleshoot with just the .bsp - but I think aguirRe is the man to listen to here :) (see his post above). 

didn't i say that?