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 

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.