You've made things so much clearer. 

Sometimes when you have a pair of doors they keep moving in the same direction, even though you've set different directions on each one. This is where you need to use the DONT_LINK spawnflag on the doors. You may also need to add a trigger_multiple to operate them to best effect. 

Thanks, Preach.

To use the DONT_LINK spawnflag, do I literally type "DONT_LINK" in the "spawnflags" field, or is there a number that I should use? (TrenchBroom doesn't let you select it from a set of options as far as I can see; the "spawnflags" field is simply empty, so one would need to know exactly what to type there). 

"spawnflags" is always a single number, it's the sum of the numbers corresponding to the flags you want. DONT_LINK=4

There are checkboxes in TB to set spawnflags (in both tb1 and tb2). Just under the key/value table. 

It appears once you click on "spawnflags". Thanks, ericw, I could've sworn I'd seen those checkboxes before, but thought they might have disappeared since the alpha builds or since TB1.

Thank you for also explaining about spawnflags being the sum of the numbers you want. Always good to understand what's happening even when you're simply clicking checkboxes. 

I added a "v_lava" to .fgd file, next I refresh the .fgd to TrrB, and the lava weapon looks weird; because appears with a lava nail in backside. When tested the map

I need to edit the model or something like that? 

I feel like the only way I've been making levels so far is by making interconnected rooms with monsters in it, a la Painkiller/D44M, and it's no fun both as a mapper and player.
Any ideas on how to make more organic-looking maps while having interesting level-design? Is there something like a tutorial around Doom/Quake-like level design?
I know the basic gist of it is making loops back to the main path for keys and others but for the real meat of things I have no real ideas on how to make a map interesting gameplay-wise. 

Think of the top down view as an actual paper map of the world hanging on the wall.
North is always up towards the ceiling

That would make north-east 315 degrees, wouldn't it? I tried to make a func_door move directly north-east when viewed from the top, like this: https://i.imgur.com/NipUnja.jpg (that's not the func_door in question, of course; that's the default TB brush and is just for illustrative purposes).

So I set the angle at 315 degrees. However, in-game it moved north-west (at what I would have assumed to be 225 degrees).

So after some experimentation I stumbled across the angle that made the func_door move where I wanted it to move, which was 45 degrees.

Does that mean that in TrenchBroom, up is east? Or have I misunderstood something? 

 

While mapping I discovered it looks good when
an eight shaped looped interconnection is changed with lifts at both ends make some a kind of moebius ring.

Now I'm trying an escher map relativity
and I can't see in nor outside anymore. 

And another question (sorry!), about setting the correct "lip" value:

I assume that if your func_door is made up of just one cuboid brush next to (or partly inside) another cuboid world brush, then "lip" is the number of Quake units of the func_door that sticks out of the world brush after it has opened. Is that correct?

Or is it calculated according to the size of your brush, so that e.g. a 32-unit-long brush with a "lip" value of eight will move 24 units?

What happens when the func_door moves diagonally? 

Or is it calculated according to the size of your brush, so that e.g. a 32-unit-long brush with a "lip" value of eight will move 24 units?
This is correct.

What happens when the func_door moves diagonally?
It tries to do the same thing, but it has some undefined behaviour that I don't really understand:
self.pos2 = self.pos1 + self.movedir*(fabs(self.movedir*self.size) - self.lip);
fabs is supposed to only operate on a single a float, but the result of vec3*vec3 is a vec3 I think? It does a per component multiply? Preach or someone will have to weigh in on this. I'm guessing it does the per component multiply, but fabs only returns the first non-zero component? This seems strange as hell to me.

Either way, the behavior with lip and diagonal movement is unpredictable, and I don't know anything except to just try different values until it looks right-ish. 

Either way, the behavior with lip and diagonal movement is unpredictable, and I don't know anything except to just try different values until it looks right-ish.

That's what I'll do in the mean time, then. 

Hi, this is probably an amateur mistake but I was having trouble finding solutions with the ol' Google.
http://puu.sh/pHkys/9f1da3acc7.jpg

I'm trying to make it so that when a monster dies in my map, a light turns on and reveals the location of a key needed to unlock a door. Everything works smoothly (monster dies, light turns on, pick up key, light turns off) except that the sound doesn't play!

http://puu.sh/pHkF2/8b308bd560.jpg Here's my entity setup in TrenchBroom.

As shown in the first picture, the game attempts to play the sound but fails because it isn't precached.

Does anyone here have any ideas as to how I might go about convincing the game to cache the sound, or if there's an error with my entity setup that's causing it to not cache?

Thanks! 

The easy solution is to map for a mod like AD that contains an entity designed for playing arbitrary sounds when triggered, these will handle precaching the sound for you.

You're using a so-called "map hack" method; I'm not too familiar with them but there is a thread here about the topic: http://celephais.net/board/view_thread.php?id=37116

It sounds like the fix may be to include some entity that normally plays misc/trigger1.wav, and make sure it is above the info_notnull in the .map file order (may require checking with a text editor) 

Thanks for the quick response! I am indeed using a "map hack", specifically an attempt at this one: https://quakewiki.org/wiki/Map_based_hacks#Triggered_sounds

My map is very small and simple (it's my first map) and so I don't really want to expand its scope to include a mod like AD, but the solution of including an entity to convince the game to cache my sound was something I had in mind already.

Problem is, I have no idea what usually plays that sound! I mean, I'm familiar with the sound from my time playing quake, but i'm not sure which entity to use that will cache the sound.

At this point I am thinking of moving towards a different solution, having the game post a message to the player when the light turns on, but it would be nice to have a solution to this issue for future users of this forum... 

Yeah totally understand not wanting to expand the scope to a mod like AD.

Best bet is do a "find in files" on the QuakeC source for that wav. Here is a download link.

Turns out a trigger_multiple with "sounds" "3" set will precache misc/trigger1.wav. In fact, I think you can just create a trigger_multiple as a point entity with "sounds" "3" and a targetname, and triggering it will play the sound? If that works you can avoid the complexity of the map hack :) 

I decided to go with the "show a message to the player" route with this particular challenge, but thanks for helping to solve my problem all the same!
:) 

Well, I had hoped I wouldn't be the very next person to come asking for help again, but here I am...

This time, it seems i've run into a bona-fide bug.
Here's the breakdown:

I'm trying to create an encounter with a shambler for the end of my map, and part of that involves having the lights black out for a moment as the shambler is revealed.
The first issue I had was that the textures I wanted to use for the lights were still "lit" when I switched the actual entities:
http://puu.sh/pHDkv/139eddb1e5.jpg

After a bit of headscratching, I came up with the solution of using two very fast door entities (99999 speed) to "switch" the brushes that had the lit and unlit versions of the texture on them.
This works great!

Except it doesn't.
Here's a breakdown of the two func_doors: http://puu.sh/pHDqA/67b33ae3ab.png

Normally, they're occupying the exact same space, but I split them up for that picture. Anyway, only SOME of them work properly!

Here's what happens ingame:
http://puu.sh/pHDxm/3fc7fcd6da.jpg (lights off)
http://puu.sh/pHDyw/c82a8bda12.jpg (lights on)

As far as I know, all of my brushes are identical, save for position in the map. But there are two of them that consistently don't appear with their lit versions!

I'm completely stumped on this, so any advice would be greatly appreciated. I can post the .map file if necessary. 

Despite spending a good half hour agonizing over the problem, I never thought to check the console in-game.

It turned out that the doors were coming up with an error about being "cross-linked" or something, so I set the "don't link" spawnflag and now...

Everything is fine.

Sorry for posting without checking something so obvious before! D: 

The post nobody was waiting 48 hours for!

self.pos2 = self.pos1 + self.movedir*(fabs(self.movedir*self.size) - self.lip);

fabs is supposed to only operate on a single a float, but the result of vec3*vec3 is a vec3 I think? It does a per component multiply?

vec3*vec3 in quake performs the dot product. self.movedir is a unit vector (length 1), so the result is the length of the projection of self.size in the direction of motion.

To get an idea of what that does, we need to understand self.size as a vector. The easy definition is that it's the length/width/height of the axis-aligned bounding box containing the BSP object (bbox for the rest of the post). For projection, it's better to think of it as the vector going from the minimum corner of the bbox to the maximum.

When you project that onto an axis-aligned movedir, then it's easy to check that you just get the bbox length/width/height respectively. When it's any other angle, you can guarantee the following: if one corner of the object bbox exactly touches the wall, the other corner of the bbox will protrude from the wall by exactly lip units.

The usual issue with that guarantee is that doors moving at irregular angles are often built from rotated at the same angle. Crucially the bbox does not rotate, so you get a little empty space at each corner.

----
|� /
| /door
|/

Figure 1: diagonal edge of the door leaves a gap with the orthogonal bbox

This has a double-whammy effect on how much the door protrudes. Firstly the lip only controls how far the empty space in the corner sticks out, the visible door will not stick out as far. Secondly, you tend to embed the opposite empty-space corner in the wall so that the visible brush is flush with it. This again reduces how much the door protrudes.

In conclusion, you need to add a bit to the lip value when the door is moving at an unusual angle. Try adding twice the thickness of the door as a rule of thumb, then adjust as necessary. 

When it's any other angle, you can guarantee the following: if one corner of the object bbox exactly touches the wall when the door is closed, the other corner of the bbox will protrude from the wall by exactly lip units after the door opens. 

vec3*vec3 in quake performs the dot product.
Holy shit I had no idea. I thought dot product just plain didn't exist in qc. 

Yeah, it's really neat. You have to do the cross product by hand though...

One handy trick you can do with the dot product is skip calls to vlen in some cases. For example, if you want to know whether the vector offset is greater than 70, you can use the test

offset * offset > 70 * 70

This works because the dot product of a vector with itself equals it's length squared, and the inequality still holds if you square both sides.

You can't use it everywhere - radius damage from an explosion uses the exact length of the vector in the damage calculation, so vlen is necessary. But where you just need to test if the length is bigger or smaller than a target value, then this trick works well. 

...what?