Appendix A. Model Examples

These examples of the model types may help to explain their use a little better. They were extracted from the three levels included in QTEST1.

A.1 Map TEST1

{
  "model" "*1"
  "angle" "-2"
  "classname" "func_door"
  "targetname" "t2"
}

min: x = 412, y = 1352, z = -144
max: x = 428, y = 1368, z =  -24

{
  "model" "*2"
  "angle" "-2"
  "classname" "func_door"
  "targetname" "t2"
}

min: x = 448, y = 1352, z = -144
max: x = 464, y = 1368, z =  -24

{
  "model" "*5"
  "classname" "func_button"
  "target" "t2"
}

min: x = 500, y = 1240, z = -104
max: x = 512, y = 1256, z =  -88

These are the columns that block the path to the teleport. *1 is the left column (looking from outside the room by the button) and *2 is the one one the right. *5 is the button that lowers the two columns.

Note the targetname t2 for both columns and the same one for the button (model *5) This is what ties the button to the lowering of the columns.

The angle specific here describes the direction to move the column. Changing it to "0" moves the column to the right instead of down (looking at it from by the button). The angle is in degrees for objects moving parallel to the normal line of sight but for movements perpendicular to this ``horizontal plane'', "-1" and "-2" are used for up and down respectively.

Note: When the angle of model *1 was changed to "-1", it moved up instead of down... After jumping through the teleporter the column could be seen protruding though the floor upstairs. This is important in that it showed that the model was in fact a 3D object that is simply being moved in the manner defined and not just some textures being manipulated in such a way as to make them appear to be solid.

{
  "model" "*3"
  "target" "t1"
  "classname" "trigger_teleport"
}

min: x = 244, y = 1576, z = -136
max: x = 284, y = 1624, z =  -40

{
  "targetname" "t1"
  "angle" "90"
  "origin" "448 1028 16"                   
  "classname" "info_teleport_destination"
  "light" "250"
}

Model *3 is the teleporter. The target specific points it to the info_teleporter_destination entity with the same tag (t1).

{
  "model" "*4"
  "classname" "func_door_secret"
  "angle" "180"
}

min: x = 448, y = 668, z =   8
max: x = 512, y = 684, z =  88

This is the ``secret'' door that leads out onto the ledge with the 100% health. Again the angle just tells the function which way to move it.

{
  "model" "*6"
  "classname" "func_door"
  "angle" "180"
  "spawnflags" "1"
  "targetname" "t3"
  "speed" "175"
  "wait" "8"
}

min: x = -304, y = 1360, z = -16
max: x =  -64, y = 1472, z =  -4

{
  "model" "*7"
  "classname" "func_button"
  "target" "t3"
  "angle" "-2"
  "lip" "4"
  "wait" "10"
}

min: x = -400, y = 1564 z =  -4
max: x = -344, y = 1616 z =   4

These are the bridge to the 150% armor and the button on the floor that causes it to extend. Note the lip arg in model *7, this defines the starting position in some way related to the surface that the model is being moved into or out of.

It is also notable that the buttons are activated by touch (walking over this one is as good as bumping model *5. Presumably you could put a button on the ceiling and have the player jump up into it.

A.2 Map TEST2

There are a lot of models/models in test2 (lots of moving stuff) and it is here that we start to see some of the real possibilities inherent in the engine.

{
  "model" "*7"
  "speed" "200"
  "classname" "func_door"  
  "angle" "0"
  "targetname" "t3"
  "spawnflags" "4"
  "dmg" "1000"
}

min: x = 1112, y = -1024, z =   0
max: x = 1240, y =  -832, z = 112

{
  "model" "*9"
  "speed" "200"
  "dmg" "1000"
  "targetname" "t3"
  "angle" "180"
  "spawnflags" "4"
  "classname" "func_door"
}

min: x = 2120, y = -1024, z =   0
max: x = 2248, y =  -832, z = 112

These are the walls that make up the two crushing traps on either side of the starting room that allow you to kill anyone who goes for the yellow armor in the cages.

Here is the first use of the dmg arg that defines how badly it hurts you if it closes on you. There are some doors that will hurt you slightly (3-5%) if they catch you as they are closing. There might be a default dmg value for certain types of doors but, clearly, setting this at 1000 as it is here, will kill you in one hit.

{
  "model" "*11"
  "target" "t4"
  "classname" "func_train"  
}

min: x = 1792, y = -1064, z = 304
max: x = 1888, y =  -984, z = 320

{
  "target" "t5"
  "targetname" "t4"
  "origin" "1792 -1064 304"
  "classname" "path_corner"
}

{
  "target" "t4"
  "targetname" "t5"
  "classname" "path_corner"
  "origin" "1472 -1064 304"
}

This is that sliding platform that goes back and forth above the starting room and carries you to the grenade-launcher and back again.

The model is the ferry itself and I have included it's two path_corners that define the extents of its route. The thing to note here is how the targets are set up pointing to each other's targetname to keep the platform moving to and fro. I imagine that if you were to set up a series of these corners, that just kept pointing to the next one in line, that you could have one of these things follow a long complex path through the level.

{
  "model" "*1"
  "classname" "func_door"
  "angle" "180"
  "targetname" "t1"
}

min: x = 1392, y = -1272, z = -16
max: x = 1696, y =  -840, z =  -4

{
  "model" "*2"
  "classname" "func_door"
  "angle" "0"
}

min: x = 1696, y = -1272, z = -16
max: x = 2000, y =  -840, z = -4

{
  "model" "*3"
  "classname" "func_button"
  "angle" "90"
  "target" "t1"
}

min: x = 1288, y = -832, z = 16
max: x = 1336, y = -816, z = 56

{
  "model" "*4"
  "spawnflags" "4"
  "targetname" "t1"
  "classname" "func_door"
  "angle" "270"
  "wait" "4"
}

min: x = 1632, y = -1408, z = -16
max: x = 1760, y = -1288, z =  -4

{
  "model" "*5"
  "classname" "func_door"
  "spawnflags" "4"
  "angle" "90"
  "targetname" "t1"
  "lip" "0"
  "wait" "4"
}

min: x = 1632, y = -824, z = -16
max: x = 1760, y = -688, z =  -4

{
  "model" "*8"
  "target" "t1"
  "angle" "90"
  "classname" "func_button"
}

min: x = 2024, y = -832, z = 16
max: x = 2072, y = -816, z = 56

Models *1 and *3 somehow define the targetname for model *2.

These are all the definitions that handle the two buttons in the yellow armor cages and the four floor surfaces that they cause to open. Notice that there are only five target/targetname specifics (t1) in the group.

Every once in a while, when calling two models into action, one of the targetnames will be missing. It turns out that you can wrap at least one targetname-less model in between two models that are targeted at one another. Quake, apparently, will assume that you mean to apply the action to the middle one as well.

{
  "model" "*25"
  "targetname" "t15"
  "angle" "180"
  "classname" "func_door"
}

min: x = 2336, y = -568, z = 32
max: x = 2400, y = -552, z = 96

{
  "model" "*26"
  "classname" "func_door"
}

min: x = 2400, y = -568, z = 32
max: x = 2464, y = -552, z = 96

{
  "model" "*27"
  "target" "t15"
  "classname" "trigger_multiple"
}

min: x = 2336, y = -616, z = 56
max: x = 2464, y = -560, z = 64

Here is another example of the dropped targetname whilst wrapping, using the trigger_multiple classname. This is the small double doors that let you out of the secret room with the red armor. Model *27 is walk-over activated (as are all triggers) and opens the doors when you approach them.

{
  "model" "*31"
  "classname" "func_plat"  
}

min: x = 1248, y = -704, z = 160
max: x = 1392, y = -576, z = 320

func_plats are the elevator/lifts that automatically rise as you step on them. If they have the angle arg included it would seem to be an indicator of the direction from which it is activated.

A.3 Map TEST3

{
  "model" "*5"
  "classname" "func_dm_only"  
}

min: x = 1184, y = -960, z = -48
max: x = 1200, y = -848, z =  48

{
  "model" "*6"
  "classname" "func_dm_only"
}

min: x = -576, y = -496, z = -40
max: x = -560, y = -400, z =  64

Map three is the only one that has these ... these models are obviously the two teleporters that are only available during deathmatch.