I don't think anyone mentioned this already, but you can disable the water and slime sound effects using compiler flags. The sounds are added at compile time and whether you can hear them or not is dependent on whether they are in a visible leaf or not. This makes them absolutely suck for open maps, where it is usually much better to just add your own sounds.

add these to your vis command line options:
-noambientsky
-noambientwater
-noambientslime
-noambientlava (doesn't have a sound anyway...)
-noambient (disable them all)

http://user.tninet.se/~xir870k/readmevis.txt 

I have this map that uses point-sized triggers for monster teleports and centerprints as usual. For some reason, however, they are all messed up in Quoth, spawning with an actual bbox instead of a point. This might be related to bbox-borrow hacks I used, but it shouldn't affect the point triggers (and doesn't in other mods). Any idea/care to take a look? 

Quoth has built in support for point sized triggers:
http://www.quaddicted.com/webarchive/kell.quaddicted.com/quoth/quoth_tutorial.html#triggers

Essentially you position the entity where you want the lower corner of your trigger, and set mangle to the desired dimension of trigger. If you don't specify dimensions, the trigger defaults to 64x64x64, which is what you're seeing, I guess.

The best workaround would be to set mangle to something very small, like '0.1 0.1 0.1'. This should stop the point triggers overspilling. 

In retrospect this default size is badly done. Any default size could potentially break a map, but making it very small would probably avoid problems in 90% of cases. One more for the 2.2 patch... 

Funny I never noticed it before - and I always use point triggers for monsters. Probably because Quoth usually breaks so many things in my maps that I don't even test it carefully anymore. I'll try the low mangles. Thanks.
Disclaimer: this wouldn't be necessary if it wasn't for some specialists who always seem to run maps in the wrong mods without even realizing... :/ 

Does Quoth treat monster pathing differently? Is the next path_corner called on touching the point instead of the box? Several monsters have problems on their patrols through cramped areas. 

Yes, there are some changes to accommodate the extra features quoth path_corners use. It looks from the tutorial like they've never been documented though...Corners support the following extra field for monsters:

wait: When non-zero, monsters will stand at this path_corner for wait seconds before continuing. If wait is negative, the monster will stand indefinitely. While standing, the monster will turn to face the angles set on the path corner.

The code that handles this is lengthy and I've been trying to pick my way through it without breaking it. I do know that one of the changes is that the monster is expected to reach the centre of the path_corner before it stops - there's a 4 unit margin of error, but it's much closer to the centre than the usual quake behaviour.

This can cause compatibility problems - in fact I already know that it breaks some pathing in e4m2. Unfortunately that leaves us in a bind, because reverting the changes now would break paths in maps designed for the new behaviour. So I think it may have to stay broken... 

Is there a way to have a solid brush entity with a trigger (relay) functionality? Apparently a regular func_wall's use field can't be overridden just like that. It seems like this should be possible with a notnull, but I'm somewhat confused as what the think field has to be. Sure, I could use a door with multi_trigger in its use field (to enable delay) or even a button, but this seems like even more of a hack than a clean notnull setup. The impact on network packets/performance is the same in either case? 

func_wall already has a use function - it toggles the texture, which is why you can't set a custom use function directly. However, you should be able to use

"think" "trigger_relay"
"nextthink" "0.1"

to change the use function post-spawn. 

Awesome, thanks. I wonder if this creates a new set of possibilities that we haven't thought of before...

I knew you normally can't set custom use functions directly. However, strangely enough, it works on doors. At least setting it to multi_trigger allows for "delay" where originally the target is fired instantaneously. 

I think delay works on doors even if you don't set multi_trigger - the quake code is very good about using SUB_UseTargets for everything that fires an event. 

For years I was under the impression it could only fire the targets immediately after activation unless set to multi_trigger. Feeling incredibly silly now.... 

Quoth question:
Could I make func_breakable objects bleed when shot? Also would be cool if it could trigger something on being blown up :E 

you could wrap the func_breakable in a normal shootable trigger that targets the breakable. 

That's what I'm doing atm but it's a bit awkward, especially if you want the player to stand on the breakable (don't ask me why k? :p ) cause they ice skate around :( 

But why not add the blood trail flag to the gibs it fires? It won't bleed when hit but will splat when destroyed. 

I know you can run a mod using another mod as a base using e.g. fitzquake.exe -quoth +game warpspasm, but is there a way to do that from the console? 

No. 

I'm working on a map, the problem is that I've exceeded marksurfaces limit, the map will run, but I want to make the map "standard" (it's an experiment, I want to use default Quake textures, respect standard limits, etc).

I've deleted some details, so I managed yo get from 32.893 to 32.237, but I need to go lower because I need to add some areas to connect some parts of the map with other parts.

So I started to delete small rooms and I had a huge unpleasant surprise. I deleted a small room behind a wall, it's a very simple room, but still... it has 4 walls, floor and ceiling, plus the entrance to the room is a digger made in the wall, that should take quite a few marksurfaces.

I was hoping in a nice drop, but marksurface went from 32.237 to 32.275. Jow is that possible? That room is completly isolated, the only area that connected the room to the map is a wall...

I work with Quark.

Any suggestions? 

are all (most) of the vertexes on the grid and none (few) of the brushes penetrating each other at weird angles?

I had similar problems with dom3m1 (deleting simple architecture that wasn't even touching anything and having it destroy the entire map) and it really all came down to being lazy and not respecting the grid.

As negke could tell you. :P 

Yes, thanks for the very fast response. Unfortunately I started the map back in 98, I even finished the map (but it was a simple DM map and it was quite ugly). Almost everything in that map was off the grid and instead of starting again I continued that map.

But I still cannot understand, it's beyond logic how deleting a room behind a wall will increase the marksurfaces number.

I understand that the compiler will "break" the "walls" into smaller "chunks", but it's only a simple wall that has a digger cut into it (deleting only that digger should decrease the marksurfaces greatly). And then there's the entire room behind the wall.

Weird, very, very weird :( 

The more floating vertices and odd intersections your map has, the more desperate measures qbsp needs to take to make it presentable. In every case, you're basically giving the compiler a rubik's cube and saying "solve this" and your .bsp file will always be the programs saying "I did the best I could!"

While on the subject, you should be happy a weird marksurface count is all you have to deal with. I had to delete two torch-holders THAT WEREN'T EVEN TOUCHING ANYTHING because somehow having them float there in the middle of the room made compile time jump up 5 hours, outleafs drop to 0, and the map unloadable

Incidentally have you tried lighting the map yet? Because I think I'm still the only mapper to build something with such horrible brushwork that running tyrlite on it literally broke the hull. 

Lights are there (except a few tunnels that are still "pitch black").

I think I understand what you are trying to say, but it's still very frustrating for me.

I just tried something else, I've deleted the "entrance" to the room by deleting the digger, the room is still there, the compiler didn't elimiated it because it has a light and a weapon inside, marksurfaces dropped from 32.237 to 32.228.

But if I delete now the cubic room (4 walls, floor and ceiling) will make the marksurfaces go up to 32.275.

If anyone has any other suggestions or ideas, please let me know.

Thanks. 

Because to me it seems like the compiler randomly changes the number to make fun of me.
Optimizing a map to get under the limit can be a real bitch - especially since the behavior doesn't seem to follow logical patterns.
You saw it yourself, removing or simplifying stuff sounds like it should lower the count, but in reality sometimes it actually makes it rise. In my current map, for example, I had the strangest actions affect the mocksurfaces: moving a door one unit made the count jump up by 100, when moving it by two units it remained the same as before; or even better, at one point I could influence the count by, I don't know, maybe up to 300 points simply by moving the monster teleporter room up and down by a couple of units. Weird shit. The position of the brushes in the map list (old vs new) also affects the outcome.

In consequence, I don't really have a definite suggestion on how to effectively lower the count. Try the usual measures first - turn details into funcs etc, simplify walls (e.g. make new textures that have wall+trim) etc. 

marksurfaces are a different thing than just vertices or faces so deleting stuff does not always reduce them. I don't really know much more than that though.

Stock engines can run a map with slightly higher than max marksurfaces, iirc.