Multiple
path_corners
form a path that can be followed by various moving entities, including some monsters and the
func_train
. The corresponding entity for
func_tracktrain
(which can not use
path_corner
) is
path_track.
Attributes
- Name (targetname) - Property used to identify entities.
- Pitch Yaw Roll (angles) - Sets the pitch (up / down), yaw (left / right) and roll (bank) respectively. The compass in Hammer corresponds to Yaw. The settings are not always (or not all) used.
- Next stop target (target) - Name of the next path_corner in the path.
- Fire On Pass (message) - Trigger this event when this path_corner is passed by the entity using the path (blah!).
- Wait here (wait) - Wait for this number of seconds before moving to next corner.
- New Train Speed (speed) - Speed of the train once it passes this path_corner.
Flags
- Wait for retrigger (1) - Moving entity will wait and will only continue when triggered.
- Teleport (2) - Makes a
func_train
entity teleport to the current path_corner
.
- Fire once (4) - Will only fire its Fire On Pass" target once.
Notes
- It's a good idea to establish a simple
path_corner
naming convention. E.g. mypath1_1
, mypath1_2
, mypath1_3
...
- A better idea is to use the level editor's path tool if available. This greatly reduces the chore of manually naming every single entity and its targets. The generated entities follow the above advice as well.
- Monsters will ignore the 'Wait here' setting, and once they are interrupted, they will not proceed to the next
path_corner
anymore. scripted_sequence
offer more control and are more reliable.
- A
trigger_changetarget
can be used to make an object move to a specific path_corner
, regardless of which path_corner
they're currently heading towards.
monster_apache
and monster_osprey
both use the path_corner
's angles to orient themselves on flight.
afaik, it's only happened once, but something to keep in mind if you're having trouble with path corners.
func_train
is entirely within func_train itself. It is therefore possible to make a valid path with other entities mixed in. I've successfully mixed path_corners withmomentary_doors
like this:p1
)target
=m1
wait
=0
spawnflags
= Teleport (2)m1
)target
=p2
wait
=0
p2
)target
=m2
wait
=0
spawnflags
= Teleport (2)m2
)target
=p1
wait
=0
It is a setup for an experiment where I can vary the time a func_train spends on one part of the map vs the other because it's being used to occlude LOS between me and a monster to test its AI schedule but that's off topic.
But you can likewise use it to have dynamically timed sequence with the mom_doors and func_trains off the playable areas.
My theory is that func_trains check the keyvalues of the entities it uses as paths (usually path_corners) without checking that their classname is actually
path_corner
. You can therefore use any entity as long as it has keyvalues that concur with that of path_corners: atarget
, optionally await
,message
(fire on pass) orspeed
, andspawnflags
that don't conflict with that of a path_corner (therefore flag 1 will stop the func_train, flag 2 will teleport, etc.)