Point EntityMultiple 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 convension. E.g. 'mypath1_1', 'mypath1_2', 'mypath1_3'.
- Monsters will ignore the 'Wait here' setting, and once they are interrupted, they will not proceed to the next path_corner anymore. scripted_sequences 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.
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.)