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? 

I seem to be doing everything right, and yet the results are still not what they should be.

I've made four func_door brushes, with angles set at 45, 135, 225 and 315 respectively, following the counterclockwise circle with 0 degrees = east and north being up like in a real-world map. Everything looks correct in-editor; when I select the individual brushes, they have little arrows that all point in the appropriate direction:
TB2 screenshot

When I compile and run the map, though, the 45 degree door and the 225 degree door do what they should, but the 135 and 315 degree doors move TOWARDS one another, and only by a few units.

I've tried so many different things and I keep getting bizarre results.

I've uploaded both the map file and the compiled bsp to quaketastic (I hope it's ok that I used it for this?). It's just a simple test map with only a box room, an info_player_start and four simple func_door brushes, as I wanted just to show the problem. If one or some of you could have a look at it and help me diagnose the problem I'd be very grateful...

It's at http://www.quaketastic.com/index.php?dir=files/single_player/maps and it's called "angles.zip" -- for some reason when I try to link to it directly like so:
http://www.quaketastic.com/index.php?dir=files/single_player/maps/angles.zip
it doesn't seem to work... 

That's very strange. I don't see why it would do that. I played around with it a bit also, but found no fix. One thing I did was set the angles to 0, 90, 180, and 270 and that worked exactly as you would expect. 

http://i.imgur.com/AISSXiE.png

Basically, the 45/225 doors calculate their movement lenght fairly correct, because their movement is parallell to the vector that stores the doors size, and when you adjust it with the lip it kinda looks correct.

The 135/315 doors though, their movement is perpendicular to the size vector, so the resulting dot product is zero. Subtract the lip and you get a net movement in the opposite direction of what you want!

The upside is then that you can use the lip to specify exactly how far you want it to move as long as you use a negative value.
Some simple trigonometry will let you calculate what distance it should move. (square root of width*width + height*height) 

design answer? 

Listen to Madfox. 

Thank you, that explains it very clearly. I have to admit that I find it hard to wrap my head around all of the maths, but it'll hopefully sink in at some point. And in the mean time I think I understand enough to (more or less) know what's going on with those doors and how to deal with it.

Rick, thanks for looking at it too.

And Preach, thank you for the earlier post (#16596), which I've read a few times by now and still don't fully understand, but it's certainly explained very clearly on your part. Those links also help a lot for someone like me who doesn't know what things like "dot product" are. As with czg's post, at some point it'll hopefully sink in. :) 

Nice pictures, what did you make 'em in? I was thinking of putting something up on my blog about this, but I didn't have a good way of making the diagrams.

I tried to think of a way round the problem with the perpendicular case. One idea would be to try a "size" vector going between a different pair of bbox corners. I think if you play around with it enough you discover that you need to negate the component of the size vector wherever the movedir component is negative. The following should be equivalent:

fabs(size_x * movedir_x) + fabs(size_y * movedir_y) + fabs(size_z * movedir_z)

Sadly we don't get to use the dot product feature in this version. 

If you did a fabs on each component of the movedir and size vectors you could just dot them and use that to multiply movedir with to get the final result.
We're just using the fabs of the result in the original algorithm as well, so doing abs before dot should work. I think? Ideally there should be a vabs function?

As for the pics, I first tried photoshop, but then I realized I don't know how to use photoshop, so I did it in Modo. Making the figures took like four minutes, then fifteen minutes for figuring out how to add the text in photoshop, and then another 20 minutes figuring out how to do the vertical lines between the series. I hate photoshop.