instead?

Surely this couldn't be broken. And having minus 1 unit isnt so bad. 

but what if you actually WANT the lip to be -1? 

You can add little brush for door in invisible zone (e.g. inside wall) and use neg. lip

http://s020.radikal.ru/i705/1406/8a/96603f4c1327.jpg 

Another way to do this is place the door on the position you want it to be when open (flush with frame). Set spawnflag "start open". Make the door 8 longer (or whatever the lip is) on the side that would be hidden in the frame and leave lip at default.

bam. kinda clunky, but it won't break. May wanna add a a trigger, depending on the situation. 

Just tested it. When I thought of it I pictured the default trigger to be hidden behind the wall for some reason, that's not the case it seems. Works fine, no extra trigger needed.

-0 doesn't work for me btw. 

Lighting the door properly would be a problem... lol, disregard everything i said. 

I've not tested this either, but if you tried it and it didn't work, it could be the result of your compiler or your map editor "correcting" a -0 to a 0. Checking the entities in the BSP file might be necessary to verify if this works.

There are other ways this could be fixed from a QC perspective. The first way would be to acknowledge that 0 is a valid value for lip and not apply a default to it - but obviously that's not backwards compatible. It is still a thing to consider for new entity classes.

The other thing to do would be to add a new spawnflag to the entity called NO_LIP, which would override the default (or any other value set) and make the lip zero. This would preserve backwards compatibility for doors. It might also be a useful pattern for some new entities, if zero is a permissible but rarely applicable value for the field, and the default value is much more sensible. 

I'm trying to make an info_trap shoot towards a moving func_train to emulate randomness, but the projectile keeps flying towards the map origin instead.

The next thing I tried is using func_train_rotate... which then keeps saying "Next target is not path_rotate" when it clearly is. :(

Any halp? 

After doing some really heavy duty optimising in one of my maps it's started saying I have a leak when I compile

Using a couple different compilers points to slightly different areas of the map... I'm at a loss as to where it is! 

my shoddy brushwork created some terrible microleaks...

Which idiot was it that was saying mitre'd corners were pointless??? 

Try using a func_train_point (or if that fails a misc_teleporttrain). The info_trap aims for the origin of the targeted entity, but brush-based entities in quake treat the origin key as "displacement from initial position", hence why it's firing near to the origin. I really must write a blog post which explains this properly, it's a common source of confusion. 

Teletrain did it, thanks. 

"Which idiot was it that was saying mitre'd corners were pointless???"

Probably me. Hey, welcome to Quake mapping. Leak hunting is part of the experience. 

A month or so ago I had a leak in a stupid big map. I had just done about and hour or so of mapping without checking, so it could have been anywhere (the pointfile wasn't much help).

Long story short, I just made a big box around the entire section of the map and would slowly shrink, recompile, shrink, recompile until I got the box to be about 128x128 with the leak in it. Takes only a few minutes and works when compilers fail. 

I had made some brushes in a way that I knew was a bit shitty... looks like they had finally degenerated to the point where they microleaked.

It's my fault really for not being more cautious. I put part of the blame on func though for putting pressure on me for saying that my map pack has to work on the normal quake exe (actually it works on winquake, there's no way I'm testing this shit on the dos version).

The worst part of this is I had already completed maybe 70% of the first episode but I have had to go back and redo huge areas (or restart some maps from scratch) to get them to work. Currently redoing one map entirely now that I had finished months ago, I have tried for a week to fix it but I can't optimise it properly so it's just going to be a different map with a similar theme. 

I've noticed in my maps recently that they do not have ambient sounds despite the map named *water or *04water

Any ideas? 

For particular texture names included in the id1 wad. And I think some of those don't work as well. 

Like sky a water not have sound if you compile map without VIS. 

which compiler are you using ?

I know there exist some options with aguirRe's RVIS and so maybe derivative, aka:

"-noambient", "-noambientlava", "-noambientsky", "-noambientslime", and "-noambientwater" to better control ambient sounds.

Are you sure you do not use one of these options ? 

None of those options are being used JPL. I'm using Tyranns tools (I think). It's kind of weird though. 

Did you try to change of water texture, and check whether the sounds is still away ? 

Any chance that the vis process is failing for some reason? You'd still end up with a valid bsp file and the failure would only show up in the logs. It just sounds like the map is unvised, so it might be worth investigating that step of the compile. 

I used r_showtris 1 and everything looks sound, I even get the sky ambience but no water ambience. The texture is appropriately named so I'm not sure what's happening. 

.. whether the water sound (don;t remeber the file name) is present in your pak file or sound folders... maybe it is just missing: in that case you may have an error/warning message in the console claiming the file cannot be found... hence the issue... though...

But I admit it is weird... never faced that issue before... 

some are *mwater which don't make sound.

they have to start specifically with *water