path_corner Last edited 4 months ago2024-06-29 18:16:24 UTC

You are viewing an older revision of this wiki page. The current revision may be more detailed and up-to-date. Click here to see the current revision of this page.

path_corner - Point Entity

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.

6 Comments

Captain Terror

Commented 15 years ago2009-06-09 00:07:41 UTC Comment #101117

weird bug i had once regarding path corners. I grouped 4 pathcorners together, and somehow the fire on pass value i had for only 1 out of 4 paths, was copy/pasted to all 4 path_corners!

afaik, it's only happened once, but something to keep in mind if you're having trouble with path corners.

stop!

Commented 11 years ago2013-03-31 19:01:13 UTC Comment #101118

better use func_tracktrain it doesn't need any corners

Oskar Potatis

Commented 2 years ago2022-04-01 12:04:54 UTC Comment #104293

New train rot. Speed (yaw_speed) was listed as an attribute but that doesn't seem to be implemented, so I removed it

C0JJ

Commented 2 years ago2022-07-09 18:58:44 UTC Comment #104631

does func_traintrack supports path_corner or its only path_tracks that makes it moves

Oskar Potatis

Commented 2 years ago2022-07-09 19:24:34 UTC Comment #104632

C0JJ, func_tracktrain uses path_track only. I have updated the article to clarify

kimilil

Commented 8 months ago2024-02-29 00:09:02 UTC Comment #106019

Fun fact: the logic of picking movement waypoints of a 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_corner's with momentary_doors like this:

path_corner (`p1`)

target = m1
wait = 0
spawnflags = Teleport (2)

momentary_door (`m1`)

target = p2
wait = 0

path_corner (`p2`)

target = m2
wait = 0
spawnflags = Teleport (2)

momentary_door (`m2`)

target = p1
wait = 0

I can then use momentary_rot_button to move the momentary_door's around and vary the distance the func_train has to travel.

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_train's off the playable areas.

My theory is that func_train's check the keyvalues of the entities it uses as paths (usually path_corner's) 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_corner's: a target, optionally a wait, message (fire on pass) or speed, and spawnflags that don't conflict with that of a path_corner (therefore flag 1 will stop the func_train, flag 2 will teleport, etc.)

[2024-09-22] Most monsters use "target" to patrol `path_corner`s. Should denote all attributes on whether they apply to [Apaches/Ospreys/Monsters/Trains].

[2024-09-23]
List of monsters that patrols path_corners in their target kvs: Need to update the target attribute in their pages. For all others, also need to update that target does nothing.

[2024-10-07]

tidied up formatting for this comment for some reason.
Added trigger_camera and func_guntarget to page
Changed lists to tables on account of there being like 6 different use cases for this entity now

You must log in to post a comment. You can login or register a new account.