nyuuzyou/wikis huggingface dataset:
Particle System Operators/render animated sprites

;Render Animated Sprites
:This render type renders the particle as a sprite, a simple quad. Depending on the .vmt parameters and renderer settings, this can be a camera facing sprite, a vertically, horizontally, or per-particle oriented sprite.
----
Generic Operator Options
Generic Render Operator Visibility Options
;Animation Rate [float]
:Determines the framerate of the animation sequence if the material has one. By default, 1.0 will map to playing the entire sequence length over 1 second.
;Animation Fit Lifetime [bool]
:If set, the animation will map to the lifespan of the particle (not currently functional)
;Orientation Type [integer]
:0 = Camera Facing
:1 = Rotates on Vertical Axis but otherwise faces camera.
:2 = Horizontal
:3 = Per Particle Normal Orientation (requires material have $orientation 3 set)
;Orientation Control Point [integer]
: (not currently functional)
;Second Sequence Animation Rate [float]
:Determines the framerate of the second animation sequence if the material has one. By default, 1.0 will map to playing the entire sequence length over 1 second.
;use animation rate as FPS [bool]
:If set, treats the animation rate setting as Frames Per Second. Useful in combination with Lifetime from Sequence initializer to match framerates to lifespans.
Category: Particle System
Particle System Operators/render blobs

;Render Blobs
:This render type renders the particle as a mesh isosurface, or a 'blob'. Nearby particles will glom together into a single continuous mesh depending on the parameters set in the renderer.
----
Generic Operator Options
Generic Render Operator Visibility Options
;cube_width
:This is the density of the matrix through which the blob is meshed. Smaller numbers give higher precision at higher performance cost, while larger number will cause more swimming with movement but at a much cheaper cost.
;cutoff_radius
:The distance at which particles will attempt to connect with other particles to create a continuous mesh. Larger distances are more expensive, should be balanced carefully with cube_width for best performance.
;render_radius
:The visual radius of each particle. Note that this should be kept smaller than the cutoff radius or multiple particles will potentially overlap each other visually, which may cause a variety of visual errors.
;scale CP
:Allows the other visual properties to be scaled via an external Control Point. X = cube_width / Y = cutoff radius / Z = render radius
Category: Particle System
Particle System Operators/render rope

;Render Rope
:This render type renders the particles as a ribbon or rope, connected in series from the oldest particle to the newest. Ropes require a specific .vmt type to render properly - it must have $splinetype set to 1 or 2. Additionally, ropes which have $orientation 3 set in their .vmt will use the normal to render oriented to the per-particle normal.
----
Generic Operator Options
Generic Render Operator Visibility Options
;subdivision_count [integer]
:The number of polygons, or subdivisions between each particle. More subdivisions will create smoother curves at a performance cost.
;texel_size [float]
:The visual density of the rope along its length. Quite small numbers may be required.
;texture_scroll_rate [float]
:The rate at which the texture will scroll along its length
;texture_offset
:The offset to the initial texture placement. Note that as each new particle is created or as they move, the rope will "scroll" along the length to maintain the specified texel density.
;scale CP start/end
:Setting these two control points which switch the texture mapping mode of the ropes to be relative to the two control points. This will allow the other "scale" options to work.
;scale texture by CP distance
:If set, will treat the texel_size as relative to the distance between the two control points, with 1 being a single span of the texture between the two.
;scale scroll by CP distance
:If set, will treat the texture_scroll_rate as relative to the distance between the two control points.
;scale offset by CP distance
:If set, will treat the texture_offset as relative to the distance between the two control points.
Category: Particle System
Particle System Operators/render screen velocity rotate

;Render screen velocity rotate
:This render type is rather unique in that it is run alongside a render sprites renderer. It orients the rotation of the sprite to be relative to its on screen velocity.
----
Generic Operator Options
Generic Render Operator Visibility Options
;rotate_rate [float]
:The degrees per second that the rotation should happen at
;forward angle [float]
:The rotation for what is "forward" on the sprite.
Category: Particle System
Particle System Operators/render sprite trail

;Render sprite trail
:This render type renders the sprites as a trail based on their velocity. The length of the trail can be altered by the particles "trail length" property. The easiest way to think about this is the trail length is a unit of time. So if it were set to 1, the trail would stretch from the particles current position to where it was one second ago. These sprites cannot have an arbitrary rotation, but can be flipped on yaw and/or pitch using normal rotation initializers/operators.
----
Generic Operator Options
Generic Render Operator Visibility Options
;Animation Rate [float]
:Determines the framerate of the animation sequence if the material has one. By default, 1.0 will map to playing the entire sequence length over 1 second.
;Length Fade In Time [float]
:The length of time over which the trail will fade in. Trails with a fast initial movement speed may appear to have a trail that goes past where they spawned, fade in time can compensate for this.
;max length [float]
:The maximum length in units for the trail
;min length [float]
:The minimum length in units for the trail
;constrain radius to length [bool]
:Don't allow the radius of the particle to exceed its length. If turned off, you can choose to have wide/short trails.
;ignore delta time
:This is used for treating trails not as normal trails. Normally, the velocity, and thereby the framerate/delta time is considered for rendering (at 2x framerate a particle moves half as far per frame and this must be taken into account when rendering the length of the trail). By ignoring the delta time, the trail is a raw distance between the current position and the previous position, regardless of framerate. This can be used to manually set the particles current and previous positions to create explosions, spikes, fur, grass, etc. Generally speaking this is authored by setting the trail length to 1 and placing the XYZ and Previous XYZ of the particle by hand, with no "movement basic" operator. Note that locking to control points, hitboxes, and offsetting movement will still function normally without a movement basic operator as they don't attempt to apply force to a particle, but rather just move it current and previous position without applying acceleration or force. The trail length can be ramped over time to create various effects.
;tail color and alpha scale factor
:This allows the trail to be faded over its length. The particle's color and alpha will be multiplied by these numbers over the length of the trail allowing it to change color and alpha from one end to the other.
Category: Particle System
Particle System Pre Emission Operators

Category: Particle System
== Pre Emission ==
Pre emission operators allows for further control of properties within a particle system, whether its changing cp locations, controlling child particles, setting simulation timescale, etc. Additionally, every operator has as run only once boolean, which only fires the operator one time.
== Pre Emission Operators ==
=== Set Single Control Point Position ===
Allows the manual positioning of a single control point.
: 
=== Selectively Enable Children ===
Choose which children should be active within the particle system.
: 
=== Play EndCap when Finished ===
Automatically plays the end cap states in this particle system when the emitter has stopped.
: 
=== Remap average scalar value to CP ===
Remaps the average value of a scalar value in the system to the control points location.
: 
=== Set control point orientation ===
Manually set the orientation of a CP.
: 
=== Set control point rotation ===
Sets the rotation rate of a control point.
: 
=== Set Control Point to Impact Point ===
Changes a control point location upon finding a traced path.
: 
=== Set Control Point to Random Active Control Point ===
Chooses from a minimum and maximum selection of control point locations and copy's itself to the chosen CP.
: 
=== Set control point to random position ===
Sets a CP to a random position within a box.
: 
=== Set CP orientation to point at second CP ===
Orientates a CP so that it looks at another CP.
: 
=== Set Simulation Timescale ===
Timescale of the entire particle simulation. (Can have unintended results)
: 
=== Repeatedly Trigger Child Group ===
Decides which children particles to enable based on the child particles group ID.
: 
=== Lightning Snapshot Generator ===
Creates a branch like positioning effect between 2 control points in a snapshot.
:
Particle scalar field

Particle systems have a number of properties that they can access, such as their alpha, position, color, etc. 
Some of these are Scalars, which are a single number. Some are vectors, which is a group of three numbers.
Particle Scalar Fields refer to all memory types which are Scalars, having a single number.
These include :
:Life Duration
:Radius
:Roll
:Roll Speed
:Alpha
:Creation Time
:Sequence Number
:Second Sequence Number / Alpha Window Threshold
:Trail Length
:Particle ID
:Yaw
:Hitbox Index
:Alpha Alternate
:Scratch Float
:Pitch
:Glow RGB
:Glow Alpha
Not all of these are user editable, such as Particle ID.
Particles In Animations

Particle Effects can be created in animations by using an anim event. Particle effects specified in this manner will be created every time the entity fires that anim event. So if you really want a single particle effect that keeps pumping out particles over time, you want to specify the effect in the model instead.
The anim event is AE_CL_CREATE_PARTICLE_EFFECT. It takes a string parameter that contains the particle effect options, separated by spaces. So, the .qc entry format for this particle effect is as follows:
 { event AE_CL_CREATE_PARTICLE_EFFECT <frame number> "<particle effect name> <attachment type> <attachment point>" }
;<particle effect name>
:Must match the name of one of the PCF files in the particles/ directory.
;<attachment type>
:Must match one of the valid attachment types. These are:
:start_at_origin
::The particle effect is created at the origin of the entity it's attached to. The effect doesn't move.
:start_at_attachment
::The particle effect is created on an attachment point on the entity it's attached to. The effect doesn't move.
:follow_origin
::The particle effect is created at the origin of the entity it's attached to. The effect is updated to move with the entity's origin.
:follow_attachment
::The particle effect is created on an attachment point on the entity it's attached to. The effect is updated to move with the attachment point. 
;<attachment point>
:Must match the name of an attachment point in the model. This field is only needed if <attachment type> is one that uses an attachment point.
== Stopping Particle Effects ==
Similar to AE_CL_CREATE_PARTICLE_EFFECT, the .qc code for this is as follows:
 and later games:
{ event AE_CL_STOP_PARTICLE_EFFECT <frame number> "<particle effect name> <boolean>" }
older games (note the different name!)
{ event AE_CL_REMOVE_PARTICLE_EFFECT <frame number> "<particle effect name> <attachment name>" }
;<frame number>
:Frame number in the sequence smd that the particle is desired to be destroyed/stopped at.
;<particle effect name>
:The particle effect that you want to destroy/stop.
 and later games:
;<boolean>
:Whether or not to stop instantly. 
older games:
;<attachment name>
:Only particles attached to this attachment will be stopped. Ignored if set to "0"
Example of use:
 $sequence shoot "shoot" fps 30.00 {
 {	event AE_CL_CREATE_PARTICLE_EFFECT 34 "weapon_muzzle_flash_assaultrifle_c1 follow_attachment muzzle_flash" }
 {	event AE_CL_STOP_PARTICLE_EFFECT 81 "weapon_muzzle_flash_assaultrifle_c1 1" }
 }
Category:Particle System
Category:Modeling
Particles Troubleshooting

Q: I have an instantaneously emitted particle with a long lifetime that's supposed to attach to an object, but it's getting left behind when the object moves.
:A: Add a position_lock_to_controlpoint operator with a control point of 0. By default that control point is the emitter.
Q: When I used the rope render type, it flickers around for some reason!
:A: Rope rendering clicks onto the nearest particle when a particle dies, the only solution is to destroy and create all particles simultaneously. Another solution seems to be adding a Velocity Noise initializer - it's tricky to work with, but it seems to work. Note: this problem does not exist in the L4D2 or Alien Swarm engine branches.
Category:Particle System
Particles manifest.txt

Particle systems must be registered in a manifest file. These are:
* particles\particles_manifest.txt
* maps\<map name>_particles.txt (per-map) 
* particles.txt (only loaded if packed into BSP) 
== Syntax ==
 particles_manifest
 {
 	file	"particles/error.pcf"
 	file	"particles/fire_01.pcf"
 	file	"particles/burning_fx.pcf"
 	file	"particles/explosions.pcf"
 	file	"!particles/muzzleflashes.pcf"
 	file	"!particles/rockettrail.pcf"
 	file	"!particles/achievement.pcf"
 }
== Source 2007 usage ==
Due to the Steampipe update, particles now require VPK integration. This is because the VPK takes priority over non-VPK files, so the VPK's manifest will always overwrite your own.
This is a relatively simple procedure. To fix this issue, create a "custom" folder in your game's root folder, alongside maps, materials etc.
Inside Custom, create a folder, with any name you wish.
Place the particle manifest into this folder, under "/custom/*folder*/particles/particles_manifest.txt"
Then, drop and drag the named folder onto vpk.exe, located within the game's bin folder. For Half-Life 2, this is located in "common/Half-Life 2/bin/vpk.exe"
Please note, with this method, you are re-overwriting the manifest. It is highly advised to add to the original manifest of the game, rather than to recreate your own!
Category:Particle System
Category:Glossary
Particles on models

Particles can be attached to models with the $keyvalues QC command. Adding a particles section to it allows any number of effects to spawn on the model, and optionally to follow it around.
== Syntax ==
Within the $keyvalues block:
 particles
 {
 	effect
 	{
 		name			"<particle effect name>"
 		attachment_type		<attachment type>
 		attachment_point	<name of attachment point>
 	}
 
 	<further effects>
 }
; name
: The name of a particle system. NOT the name of a .pcf file!
; attachment_type
:Must match one of the valid attachment types. These are:
:; start_at_origin
:; start_at_attachment
:: The effect spawns at the origin or an attachment of the model. After this, it moves independently. Good for very short effects like explosions or blood spurts.
:; follow_origin
:; follow_attachment
:: The effect spawns at the origin or an attachment of the model. After this it follows the origin/attachment, rotating and moving to maintain its relative position. Good for long-term emmisive effects like smoke or trails.
; attachment_point
: The attachment point at which the particle system should spawn, if applicable.
From the point of view of the particle system, you can use several initialisers and operators which will affect how it behaves if it is set to follow an attachment or an origin. The motion of the particles can "follow" the control point by using the Movement Lock to Control Point operator. 
You can also use the Position on Model Random initializer to spawn the system dynamically across the model.
Category:Particle System
Category:QC Keyvalues
Patch

It is a special shader that allows materials to inherit from each other. This is achieved with two commands:
;include:The base material from which to inherit.
;insert:The parameters to add, inside { and }. Those that already exist are overridden.
;replace:The parameters to replace, inside { and }.
Patch's only limitations are that it cannot change a material's shader, and a Patch material cannot use include to inherit from another Patch material.
:
==Example==
 patch
 {
 	include materials\models\infected\common\common_infected_shared.vmt
 	insert
 	{
 		$basetexture models\infected\common\military_national_guard\common_military_upper_01
 	}
 }
Patching levels with lump files

added a simple system to allow mapmakers to patch levels by shipping only the level lumps that have been altered. It is usually used to update entity lumps, changing a .BSP file's entities without a recompile necessary.
Technically, it is written to handle any .BSP file lump, but there are lumps that itself heavily depend on other lumps. For example, altered geometry in a map, even slightly, changes many lumps, and thus each changed lump would need to be verified by hand. Once this many lumps have been changed, until tools made for checking altering lumps have been setup, you may as well compile a new .BSP file.
== Creating and using new entity lumps ==
The steps involved are as follows (assuming that a previous version of the .bsp file has already been shipped):
# Make a backup copy of the current .bsp.
# Make the desired changes to the level, and compile a new (revised) .bsp.
# Use "%sourcesdk%\bin\vbspinfo" -X bspname to extract the entity lump into a .lmp file.
#:
# Put the .lmp files into your gamedir\maps directory (if they aren't already), and ensure their <id> numbers are correct (see below).
# Make a backup copy of the revised .bsp.
# Restore the backup of the old .bsp, and run the map to test it with the new .lmp. Make sure it works properly with the updated entities.
# Ship the .lmp files only.
== ID numbers ==
.lmp files are automatically named in the following format:
 <bsp name>_l_<id>.lmp
After loading the .bsp, the engine will then load .lmp files starting at id 0, and stopping as soon as it fails to find a .lmp for the next id. Each .lmp file overrides an existing lump in the .bsp with the corresponding lump type, or preceding .lmp files. If a new lump has already been shipped as a<bsp_name>_l_0.lmpfile, that lump can be avoided being overridden with a<bsp_name>_l_1.lmpfile.
In the Left 4 Dead series, you may end up with lumps that contain the letters _h_ and _s_. These are specifically used for Survival and Scavenge respectively.
== Hammer compile profile ==
The following lines of code can be entered into Hammer's advanced compile dialogue to automate lump creation of the entity lump:
 $bsp_exe
 -game $gamedir -onlyents -keepstalezip $path\$file
 C:\Program Files\Steam\steamapps\common\<game-name>\bin\vbspinfo
 -x0 $path\$file.bsp
 Copy File
 $path\$file_l_0.lmp $bspdir\$file_l_0.lmp
 Delete File
 $path\$file_l_0.lmp
If you are creating a lump file with an ID number other than zero, change the last two commands accordingly.
Note also that a Hammer bug currently prevents the use of $SteamUserDir or %sourcesdk% in the second command; using either will lead to "access denied" error messages.
== See also ==
* Source BSP File Format
* Lump file format
Category:Source
Category:Level Design
Category:Publicity & Publication
Path corner

==Entity description==
===Notes===
* A path_corner is a corner in a path, either for a func_train or an NPC. path_corners can be chained together to form complex routes. To create a path_corner chain simply shift+drag an existing path_corner. The values will automatically be filled in. To manually make a chain (or link one up in a circle), edit the Next stop target property.
* A path_corner_crash is identical to a path_corner, but can be enabled and disabled for a crash point; when an NPC is searching for a crash point, it will not search for generic path_corners
* The path_corner entity is for base.fgd, so it only will appear in Hammer for Half-Life 2
===NPCs===
A path_corner can be a destination for an NPC. When told to, NPCs will stop other movement and walk steadily towards a path_corner. It is entirely scripted behavior. Note that the Train Speed and wait values do not affect NPCs.
To make an NPC move to a path_corner edit the Target Path Corner keyvalue, either in Hammer or through the I/O system. Alternatively, an NPC can be made to follow a path_corner chain by using the aiscripted_schedule or scripted_sequence entities.
* See also Assaults for an alternative way to create NPC routes without using path_corner.
====Limitations and bugs====
* A path_corner (or the first path_corner on a chain) must be within 576 units for NPCs to find it.
* It is either difficult or impossible to tell an NPC which direction to face once they've reached a path corner. If this is important, you may want to consider using Assaults instead.
====Examples====
* See the apc_on_path and the npc_scanner_on_path prefabs for examples on usage.
* Download Example (VMF)
Note that the example map does not have any info_nodes. They are not needed to have an NPC follow a path.
==Keyvalues==
==Flags==
==Inputs==
==Outputs==
== See also ==
* 
Category:AI
Category:Entities
Path track

It is used to build paths for other entities to follow. Each path_track is a node in the path, each holding the name of the next path_track in the path.
=== Automated track creation ===
Cloning (Shift-drag) this entity will activate a feature used to automatically and quickly create a track. This feature will alter both the Name keyvalue, and the Next Stop Target keyvalue, so that a track is created between the source and the clone. More specifically, Hammer will add a counter after the Name keyvalue of the clone, or increment this counter if it already exists, creating a unique name in a series. If a name is completely omitted, it will simply name the clone "path".
If a Next Stop Target keyvalue has been specified, it will also alter this keyvalue of the source, to the name of the clone, resulting in a track being drawn between them.
=== Reversing over a path_track ===
== Parenting ==
A set of tracks can be parented. However, all tracks and the train running on them must be parented to the same object for movement to behave correctly. Failure to do so will lead to an intentional crash.
== Keyvalues ==
:* 0 : No change
:* 1 : Face direction of motion
:* 2 : Face this path_track's angles
:
== Flags ==
== Inputs ==
 
== Outputs ==
== See also ==
* 
* - The entity that moves between these paths, and Trains.
Peaces Like Us

Peaces Like Us is a Half-Life 1 single player mod by Koumei Satou with a Xen setting.
== Story ==
Mankind found an entrance to XEN world. an investigation team met with the uncanny alien in that place. Then, mankind succeeded in becoming a friend with them. After that, a scientist team built a joint laboratory in the world of XEN. But, something bad there was approaching.....
== Media ==
* Screenshots: , 
* Music, wallpapers, splash screens: 
== See also ==
* Sweet Half-Life (HL1)
* Mistake Of Pythagoras (HL2)
== External links ==
* Official website
* All mods created by Koumei Satou
* Weird Comic Art
Category:Single Player Mods