Another post responding to topics from func_msgboard, this time we’re looking at gaining finer control on the classic
func_door_secret entity. In particular we’ll be looking at rick’s question on
func_door_secret from the Mapping Help thread, although lots of the earlier posts had similar requests. So we first will create a
func_door_secret that moves horizontally, then moves upwards vertically. Later we’ll get a bit deeper into how editors usually do angles, and why we need this hack.
We make the
func_door_secret pretty much like normal, but for reasons we’ll get into later, do not set the angle of the door in the usual way. Instead, add the following key/value:
"angles" "-90 90 0"
Note that it’s
angles with an ‘s’. Now compile, and watch the door slide horizontal first and vertical second. How does it work? Well, the
angles set on the
func_door_secret primarily sets the direction of the second movement. In the
angles we have set, the first value is pitch, so -90 points straight up (90 would point straight down).
The second number in the angles is the yaw – and the effect of the yaw in this situation is quite subtle. If you are facing directly up, however far left or right you turn does not change the direction your weapon is pointing. However, it does change what part of the level is directly to the right of your screen. The direction of the first movement is determined exactly like this – which direction is due right of a player facing along the angles we specify. In particular, if you need your door to move in a different horizontal direction, change the second value accordingly.
You can also do even more exotic angles like
'30 45 0' or
'12 57 31' or something, although the two movements will always be at right angles to each other. The first two spawnflags are badly named once you do this, but they switch from right to left or up on the first movement, so sometimes that’s handy if your first movement is 90 or 180 degrees in the wrong direction.
On the angle key
So if we’ve got such freedom with our
angles key, what goes so wrong with the normal angle control? Well, we need to know how it works first. In both worldcraft and the original radiant the control for setting the facing of entities gives you the ability to set an angle between 0 and 360, or fixed angles “up” and “down”. This actually works in a strange, cludgy combination of hacks split between the engine and the QuakeC code.
So when you use the facing control, you don’t actually set an “
angles” key with three values. Instead, your entity gets given an “
angle” key with just a single value. When you set an angle in degrees, that value is set on the entity normally, like
"angle" "45". If you set the direction to be “up”, you get a key
"angle" "-1", and “down” is
In standard quake, entities don’t actually have an “
angle” key on them. Instead, when the engine loads entities from a map, it automatically translates
"angle" "x" into a key
"angles" "0 x 0" – basically just setting the yaw value on the entity. So how do “up” and “down” work? Well, they are sorted out as special cases by the QuakeC code – in particular the
SetMovedir function does the work. Because it’s left up to the QuakeC, not every entity remembers to do it, and
func_door_secret is one of the ones that doesn’t bother. So setting the
angles key is the only option here.
So you might wonder: what happens if you set the facing in the editor, and manually add the
angles key as well? The entity gets added with both keys, and basically the key which is later in the map file (and so loaded second by the engine) will overwrite the former entry and “win”. So if you want to avoid a 50% gamble on this map hack working, avoid setting the angle using the editor control – well behaved editors won’t write an
angle key if it hasn’t been set!