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 

Any good rock textures for quake? 

rtex066
rtex413m 

cavern_dk


It's kind of a shame we don't have a system for searching wads like we do for maps on quaddicted. If we could type in "rock" or "tech" or "crate" then it would be awesome.

Or how about some kind of "wad builder" where you basically shop for textures and then download your custom wad. (it could also write a .txt file which you could copy/paste into your readme)

If only I knew how to code! 

that actually sounds like it would be an interesting project. certainly not overly difficult, but would require a lot of 'manual labour' to set up the initial index and tagging all the individual textures.

the back end stuff would probably be the easiest part. basically a db which links logical texture metadata with the appropriate wad files. you'd probably either want to extract everything as loose png files or something for speed.

the web app component-- getting search results xferred over to the client browsers while maintaining responsiveness etc... would probably be the worst.
you'd definitely need some ajax async stuff so you can load images as they come in, not sure how much of a load on the server that would be. most textures are 64x64 or 128x128 which isn't all that much, but loads of tiny requests like that would probably still be bad. maybe each wad file would be stored as one large spritesheet image or maybe the backend itself could generate these spritesheets grouping textures that have the same tag. 

That Clipnodes and Marksurfaces exceed normal engine max error.
What is the easiest way to handle?
Deleting brushes, scaling up hull textures?

For some reason I always exceed the limits. 

clipnodes can be reduced by putting clip brushes over parts where the player can't go.

they are created by things that the player can collide with, so putting clip brushes over them makes less places the player can go, thus less clipnodes.

marksurfaces are weird and will randomly go up and down. 

That helped stopping the clipnode warning.

I keep that shade blackouts on some brushes.
I've been trying with light settings, but the complete black brushsides seem hard to avoid. 

 

* Never place symmetrical light sources in a room
* Never use global ambient light, learn to light maps properly
* Place strong light source first before placing additive fill lights
* If a room lacks strong shadows, tone down fill lights
* Consider shadow area contrast when placing source lights
* Understand the advanced features of wait/delay
* Try to keep light/wait values consistent for light source types
* Always sync light entities to actual light sources
* Always Illuminate the primary path
* Light Flicker (style 1) can be useful for focus in a room
* Play with up lights for ceiling detail focus
* Lights can use mangle/angle parameters for directional spotlights
* Lights should always create interesting shadows
* Place strong lights for large shadows, fill lights to soften the edges
* Switchable lights are perfect for creating dynamic detail
* Place identical light sources at the top and bottom of platforms so that when the platform is in both positions it looks right for the light source 

Hi all, I'm just starting to learn TrenchBroom with no prior mapping experience for any game whatsoever. All of this is entirely new to me, and now I have a stupid question:

Can water brushes overlap with solid brushes? I mean, when you want to create a body of water in a map (like say you've created a pool that is not just a rectangular box, but has sloping edges etc.), do you then have to create a water brush/brushes fitting that space exactly? Or can you just create a huge rectangular water brush that overlaps with the edges of the pool/lake, as long as it fills the space you've "carved out", as it were? 

 

 

How the bloody hell do you remove mouse invert? And which evil bastard decided this should be the default behaviour for mouse look?!?! 

 

 

can't yet make heretic 2 maps, the version of QED you get with the latest heretic 2 patch doesnt work properly. Plus I have no idea how to properly compile Heretic 2 maps outside of Quark (Spent a good few hours trying to compile manually with no luck)

Ironically the brushwork was mostly created in trenchbroom, I just opened 2 instances of quark and copied the brushes over. 

those are some good tips sock, but how am I supposed to learn how to do lighting properly? 

RoQ,

Make a small map and light it. Start the game and go look around in the map. Make notes of what looks good and what doesn't. Go back to the editor and change the stuff that didn't look good. Use sock's guide to go by.

As with most things, you learn by doing.