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. 

Just FYI. 

Is there something I'm missing here? I'm this close to finishing my map, but this one showstopper is really annoying me.

Here's a visual demonstration: https://gfycat.com/WaryRichEyas

See how the columns don't raise up until the shambler is almost entirely revealed? That's not what they're supposed to do. They share a targetname with the big door, shown in these two images:
http://puu.sh/pLd9y/35c6517ed9.jpg
http://puu.sh/pLda7/2d4b27959e.jpg

but as you can see in that short clip, they don't start moving at the same time as it.

To me, the worst part is the fact that at an earlier stage, before that area became quite as "scripted", they worked perfectly.

Now, it certainly seems like they're responding to the same targetname as the light textures (working well now, at least. The same ones I posted about earlier!), but they really shouldn't be.
Here's my setup for entities:

the super nailgun targets two trigger_relays
trigger_relay one has a 3.5 delay that is used to switch the lights and the column topper textures at the appropriate time
trigger_relay two has no delay and is used to start the descent of the big door and the ascent of the two columns.

Seems simple enough, but alas, it remains nonfunctional. At one point the doors were simply targeted directly by the supernailgun but I changed it to see if it made a difference (it didn't).

So, any advice? At this point, i'm starting to consider giving up and just letting players stand on the columns and get squished if they want... 

Door don't link? 

I swore I had tried that.

Why is door linking the bane of my existence?
And can someone please explain how the damn thing works? It's given me no end of trouble... 

I've been wondering, is there an IRC or other chat service room/channel that I can join for getting help with Quake mapping? I keep coming up with questions I want to ask, but I don't really want to clog up this thread with them. 

 

#terrafusion on quakenet
For TB questions come to #trenchbroom 

 

It'll link doors if their bounding boxes touch.
Thing is, it is not smart enough to recognize anything other than doors that open in opposite directions and it 'fixes' doors it thinks are not opening in the right direction.

whenever you're working with doors in close proximity, just put door_dont_link on anyway. in some ways, it's better even for doors that would normally link because then both doors will emit a sound instead of just one. 

I Need to make a new progs.dat with DOE & SOA features... 

http://www.gamers.org/pub/idgames2/more_idstuff/ 

At this point I think it's safe to say that func_door is my favorite func_... except for func_msgboard!

This question's probably been asked before, but searching this thread is a real pain. It's also really short:

How do I suppress/replace the message that a door that requires a key shows?

Hopefully this is possible... 

I want to have a low gravity map like Ziggurat Vertigo, but unlike that map, I want it to be self contained. How do I change sv_gravity using a trigger? 

Like hipnotic, Quoth or AD. 

Func_door has a message code that you can fill in as soon as the player reaches the door. It goes something like:

"classname" "func_door"
"message" "stop calling that key funtion"
 

Can I put the .qc files directly to the progs.scr for combine mods in a progs.dat?

example: I add hipscor.qc and wrath.qc to a same progs.scr.

Also in monsters.qc is need to add their respective info?