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? 

I have already tried that, all it seems to achieve is that both messages are sent to the player, with the custom one only visible in the console. :( 

The message key/string works for any door that requires external activation. However, you probably can't remove the default message for doors that require a key. It's part of doors.qc

http://www.gamers.org/dEngine/quake/Qc/doors.htm

It would be easy enough to change if you didn't mind having a custom progs.dat 

Oh, how I love hardcoded messages like that. I guess i'll just ditch keys and trigger the doors instead. Pity, really... 

you can add several qc files to the prog.scr but chance will be there are strings that relay on eachother that prohibit the outcome of a progs.dat.

the compiler will send an error.txt or maybe in case if you're lucky not.
the missin pack qc are rather complex, I allready stumble in the usual one. 

I was building a house in Trenchbroom, and it became corrupted somehow. I'm wondering if there is a way to recover it? I've tried running the file in other map programs to no avail. Link to the map file is here:

http://s000.tinyupload.com/?file_id=32718139104686950661