Once the BSP is compiled, none of that matters. So as long as it's building correctly, you picked the right option. 

To clarify, Quake stores textures inside the BSP file so the WAD path only matters during compilation. 

But I did actually google this, but found nothing :/

For some reason textures don't appear to be aligned correctly in game even when they are in the editor. For example if I change the angle of a texture in the editor it will look correctly there, but once in the game it will still be the wrong angle. Whati is causing this?

Oh, and as a gift in return for asking all these questions, here are a few screens from the level I am working on:

https://imgur.com/a/LbuLB

https://imgur.com/a/IFIzn

https://imgur.com/a/dtRof 

The options are related to where your texture .wad(s) are in relation to the map file. Relative to game directory or application file tells it to check within the folder of either Quake itself or Trenchbroom's install folder respectively- if you have your wads stored someplace else, these choices will often fail because it requires going up a level from the starting point and changing folders, which tends to get screwy. Relative to map file is the same thing but relative to where the .map file you're making is saved- this one fails often as well, and will obviously not work if you haven't saved your map yet (i.e. loading texture wads before starting actually mapping), because then you're telling it to figure out a directory path from the texture wad to nothing. Absolute is the full file path to the wad and is the most reliable.

No real reason to pick one over the other if multiple options work- the only place it shows up in-game is if someone uses the edict (or edicts) command, specifically for edict 0 (worldspawn) which will include a list of what .wads were used when compiling the map and their filepaths, like these examples- the first one is id's own E1M1 which uses only their own base.wad and had the file located within their editor's folder, the second one is an example of the full file path showing up if you use the 'absolute path' option. 

Check your tools and editor are up to date.

tyrutils (Tyrann's original, not my fork) required the "-oldaxis" option to be used for qbsp.

TrenchBroom hasn't had any issues like this in quite a while except for this one: https://github.com/kduske/TrenchBroom/issues/1821 which only comes up if you use the "rotation" tool, and even then only under specific conditions. 

 

http://ericwa.github.io/ericw-tools/

Download some more recent compiling tools and you wont have to use oldaxis 

I'm testing a map, that starts with a warning: 765 efrags exceed standard limits of 640.
The light.log shows:736 entities read, 329 are lights. FindLights: 962 total lights.
I used a lot of lightmaps on a texture in the hope to reduce the lightcount, but it seems to go much too far. I added quiet a lot of new monsters.

While playing I can't reach the end of the map, because of an overload. It looks as if I can't make a room with more than three monsters.

Should I just start removing lights to see what happens? 

Ordinary lights (non-dynamic ones, and ones with no model) don't use up any resources except light.exe compile time, so removing lights probably won't help anything. Removing walltorches will help if you're going over static ent / signon buffer limits, but those would prevent the map from loading at all.

efrags are created when entities span multiple BSP leaves. e.g. the most extreme case: if you made a trigger_once that covers your entire map, and the map has 10k leafs, it would create 10k efrags.

While playing I can't reach the end of the map, because of an overload.
What is the error message and what happens (engine crashes, dropped to console, etc?) which engine? 

I placed a range of secret doors, that were all working independed. When I couldn't make them work on one side without the backside, I placed them all on one trigger_once. So that could be reason.

I can play the whole map (116 ent), untill the last stage, where an overload starts.
The reason is a Launcher_Touch that is in use with one of the baddies. If I delete the monster, another one complains again about its Laser_Touch.

Here are a screenshot and log.
overload
log 

Thanks for posting the log madfox, it turns out that the efrags message is just a warning. The real error which ends your map is "Stack overflow". The rest of the error message shows that the stack overflow is happening inside a chain of triggers.

The simplest way this can happen is that you build a really long chain of triggers which target each other (without any delay):

trigger1 ---targets---> trigger2
trigger2 ---targets---> trigger3
trigger3 ---targets---> trigger4
...

If you have 10 or more triggers connected in a row the game runs out of space on the stack, and you get a stack overflow error. Add a delay somewhere and it should be fixed

In practice most people don't have ten triggers in a row, it gets too complex to be useful. The other way that it can happen is you create a loop. If you have two triggers that target each other, they go into a loop

trigger1 ---targets---> trigger2
trigger2 ---targets---> trigger1
trigger1 ---targets---> trigger2
trigger2 ---targets---> trigger1
...

This loop never ends, so you hit the limit of 10 and the error appears. Check your triggers to see if any of them are targeting themselves, or if they are creating a loop of targets. 

Anyone have any experience with this?

I've successfully created a couple that work fine in KmQuake2 but in other engines they don't render correctly.

Any useful links, tips or suggestions would be appreciated. 

The map had a teleporter with a loose target.
Still I'm a bit confused, because the WARNING: couldn't nudge light in solid at seems strange as there are no lights at that point. 

If you are using light from surfaces, the light tool generates light entities just off of the surface. Could be you have a func_ with a light texture butting against a wall. 

It's safe to ignore that warning. Glad you got the stack overflow fixed! 

I recently made a map hack using a 'clock', trigger_relays targeting each other but with delay so they would give a trigger output every 2 seconds. I used this, so moving parts of my level would light correctly. 

 

The issue is when triggers target themselves with no delay key set. If you have a delay set them there is no risk of overflow. 

Hi everyone!

I found out that Preach has some pretty cool map object models at his website, and I thought about using them as prefabs in my map. I've never stepped into custom model territory before, so I'm a complete newb here; please be understanding. T_T

Ericw told in his post (#18366) that you can use AD's misc_model and Quoth's mapobject_custom to add custom models to your map. But if I want to go vanilla so to speak, is my only option to overcome the model precaching dilemma by going to some QuakeC editing to add the necessary precaching lines?

(I guess it means that then it would technically no longer be considered vanilla anymore, huh?) xD 

It's not possible to get the necessary models precached without a bit of QuakeC. The good news is that it's basically the perfect "my first mod" exercise.

Download the source code, and open up misc.qc. Add the following lines:

void() misc_model = //we are defining a function
{
// precache whatever model the mapper stored
// in the "model" key
precache_model(self.model);

// apply this model to ourself
setmodel(self, self.model);
}

Download fteqcc.exe and save a copy in the source code directory. Run it and it will compile the mod into a progs.dat file. Add that progs into your mod directory.

How do you use this entity? You add an entity to your map with the classname "misc_model". Notice this is the same as the name we gave our function. When the game loads a map, each time it creates an entity it looks at the classname of that entity. It then lets that entity runs the function in the QuakeC with the same name, which lets the function prepare the entity for use. 

fte and qss both implement misc_model engineside should the mod (like vanilla) fail to support it. 

I am talking about things like lowering walls to reveal traps, or lowering pilars that previously blocked the player. Do I use func_plat for this? Or something else? 

 

plats tend to be a special-case thing. if you want to trigger something then func_doors generally work better. set the angle to -1 or -2 to have them 'open' upwards or downwards. you can have them toggle too. 

Hey, trying to make some tree textures here:

So I want to make a tree texture used as a func_illusionary, just like the spider web textures from Daikatana that 'skip' over all of the texture except the web. How do I do this?

I have drawn a tree over a pinkish background and named it {tree this appears to be the same convention as these web textures. How does the compiler interpret the texture and skip the background? I must have missed something because so far the tree is drawn along with the pink wall. Any ideas here?

Thanks.