path_corner Last edited 4 weeks ago2024-10-07 15:25:01 UTC

Redirected from path_corner_(Half-Life)

path_corner - Point Entity

Multiple path_corners form a path that can be followed by various moving entities, including some monsters, the Apache, the Osprey, trigger_camera, func_guntarget, and func_train. The corresponding entity for func_tracktrain (which can not use path_corner) is path_track.

Throughout this page, attributes and flags that apply to the different entities will be marked as follows: [Apache/Osprey/Monsters/Camera/GunTarget/Train]

Attributes

Name	KV	Description	Ap	Os	Mo	Ca	GT	Tr
Name	`targetname`	Property used to identify entities.	✔️	✔️	✔️	✔️	✔️	✔️
Pitch Yaw Roll	`angles`	Sets angles. The compass in Hammer corresponds to Yaw. Used to aim Apaches/Ospreys in flight.	✔️	✔️	❌	❌	❌	❌
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 an entity using the path.	❌	❌	❌	✔️	✔️	✔️
Wait here	`wait`	Makes the entity wait for this number of seconds before moving to next `path_corner`.	❌	❌	❌	✔️	✔️	✔️
New train speed	`speed`	Set new speed for the entity once it passes this `path_corner`.	❌	✔️	❌	✔️	❌	✔️

Flags

Name	Value	Description	Ap	Os	Mo	Ca	GT	Tr
Wait for retrigger	1	Entity will wait and will only continue when triggered.	❌	❌	❌	❌	❌	✔️
Teleport	2	Makes entity teleport to this `path_corner`.	❌	❌	❌	❌	❌	✔️
Fire once	4	The entity will only fire the path's "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.
As a general rule, this entity has barely any logic. All the logic of following the path, waiting, firing targets, etc., are implemented within the respective entities using this entity, hence the 6 different implementations.
Only unnamed monsters would follow path_corners, and once they are interrupted, they would not proceed to the next path_corner anymore. It makes sense to think of path_corners as "patrol paths" for monsters, where anything that raises alert makes them stop their rounds. scripted_sequence offer more control and are more reliable.
A trigger_changetarget can be used to make a func_train move to a specific path_corner, regardless of which path_corner they're currently heading towards.

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.