There isn't much vocabulary that is specific too this guide, but there is still some.

• PCF - This stands for Particle Collection File, it is what your particle system will be saved as on your machine.
  
• Particle System - This is what you see when you open a file in the editor, it contains all of your particle definitions, what's parented too what etc.
  
• Particle Definition - This is a single part of your particle system, it is a specific particle you edit. For example, if you were to open item_fx.pcf, and scrolled down to superrare_beams1, and clicked on it, that would be it's own particle defition.
  
• VTF - This stands for Valve Texture File, and it is what stores your sprite. You will not be able to access your sprite in game without a VMT though.
  
• VMT - This stands for Valve Material File, and it is how you point to your sprite that you will be using. You also use VMTs too define how you want your sprite to behave, like being additive, blending frames, having a locked Z axis, etc.

While adding your own custom sprites may seem complex, it is actually very simple. You will need some tools to start off with though.

Tools you will need -

• VTFEdit [valvedev.info]
  
• Paint Dot NET [www.dotpdn.com]
  
• GCFScape [valvedev.info] (This is optional, but it allows you too open the file explorer specific to valve's .vpk files, and see how some VMT's are set up.)
  
• RonSkons' Animated Sprite Generator [github.com] (Optional, but highly recommended)

These are the things you use to make your particle actually show up, each one has a different use and some of them can be combined.

---

This is used for almost every single particle you will ever make. Despite it saying "Animated" in the title, it will render a still frame as just a still frame, it won't try to animate unless your sprite has multiple sprites in a single sequence.

This is used for some specific uses, it will not animate your sprite it will instead stretch your sprite between however many particles you have. This sounds complicated, but it is really simple. Say you have a max particle count of 2, and your first particle doesn't move, but your second one does. It will draw the sprite stretched out between these 2 particles. (They have to be in the same particle definition, it won't interact outside the single particle definition.)

I don't quite understand how this works, I will update this part once I figure it out.

These are what makes your particle run. Operators are constantly run through while your particle definition is alive. You can do things like define movement, scale your particle up & down, fade your particle in and out, etc.

---

All three of these operators do almost the same thing, but are slightly different. Alpha Fade In/Out are pretty self explanatory, and really all you'll need to do is add them to your effect. Remember that if you leave proportional to true (1) then the fade in/out will be proportional to your particle's life. For example, if you have a particle that lives for 10 seconds, a particle with 0.25 fade out time & proportional set to true will start fading out a 7.5 seconds until 10 seconds when it will be fully invisible & die.

Alpha Fade and Decay just combines Alpha Fade In, Alpha Fade Out, and Lifespan Decay together in one operator. It allows you a bit more control, with setting the start alpha to 1 or 100% of the alpha set in the initializer, or 0%.

Color fade allows you to set a color the particle will fade into, start and end times are proportional. Ease in and out will make it lerp between the start color & end color. I dunno why this is an option since it already does it pretty well.

I'll need to experiment with this to figure it out.

Again, need to experiment to learn what this does.

This allows you to make the particle die when it's velocity slows down to X value. This is good to use with something like drag in Movement Basic, allowing you to define the minimum speed of your particle before it dies.

Movement Basic
This is a simple Vector 3 movement system. You have a velocity, 0 0 0, with no limit to what value you can input into it, as long as it is a Vector 3 value. This Vector 3 is the same one used for your position initializers.
Movement Dampen Relative to Control Point
placeholder text
Movement Follow CP
placeholder text
Movement Lock to Bone
This locks your movement to be relative to the closest bone. Most commonly used with Position On Model Random.
Movement Lock to Control Point
This is used for most situations. It locks your particle's movement relative to the particle's control point 0. Without this your particle will not follow the player.
Movement Lock to Saved Position Along Path
placeholder text
Movement Maintain Position Along Path
placeholder text
Movement Max Velocity
Similar to Lifespan Minimum Velocity Decay, this allows you to set the absolute max velocity your particle can have. I really only use this if I have a problem with my particle going insane and flinging all of over the place, but other creators may have other uses for this listed below.
Movement Rotate Particle Around Axis
This is what most orbiting effects use. If you are going to use this, make sure your initial position has any position except for 0 0 X. If you have the initial position set to 0 0 X, it will not rotate your particle.

Noise Scalar and Noise Vector are similar, but Scalar is just a single value, with 11 different output fields.

• Radius
  
• Roll Speed
  
• Alpha
  
• Creation Time
  
• Sequence Number
  
• Trail Length
  
• Particle ID
  
• Yaw
  
• Sequence Number 1
  
• Alpha Alternate

While Noise Vector has only 3 different output fields.

• Color
  
• Position
  
• Roll*

*Roll should not be a Noise Vector, as only the first value in the Vector 3 works, effectively making it a Noise Scalar

These will use noise generated based off of the seed value you input or as it is in game, Noise Coordinate Scale, and will output a value between your minimum and maximum values, to edit your output. Most are obvious and can be figured out through a bit of experimentation but there are a few that require some explanation.

Creation Time
Honestly no clue, if someone could help me figure this out in the comments that would be amazing.
Particle ID
Again I have no idea how this works, but I would not mess with it.
Alpha Alternate
Just another way to mess with the particle's Alpha & will behave a bit different.

Similar to the Noise Operators, the Oscilate Operators have a Scalar and a Vector alternative. The only difference between this and noise is that this will act like a sine wave, where rate is your amplitude and frequency is, well, your frequency. You also have Start/End proportional which I always turn off, as it tends to mess up the oscilation.
There's the start and end times, which act the same as every other operator's start/end times.


This is where you define the starting values of a particle. Here you can set where your particle spawns, what color & size it will be (which can be actively changed via operators).

---

Here is where you can define some weird parameters. Such as pull to CP, random force and the like.

---

Here is where you set constraints for your particle, such as constrain distance, or set up a collision system for your particle, like how Marigold Ritual has the DEBRIS parameter here, allowing it too collide with the floor.

---

The following tips are for basic use that I feel are important when trying to make a good looking particle that stands out, I will not be explaining any of the Advanced Mechanics since they're more like gears for making something work while this is what makes them look good.

---

Making sure your particles are always visible while in the chaos of battle is very important which its why having a nice and simple background is quite useful but not always a must!

Examples
With:

• https://youtu.be/N-Zt2N_3Lz8
  
• https://youtu.be/S240lcUxj6A

Without:

• https://youtu.be/cF8anwNONu0
  
• https://youtu.be/i0cJZVFRp7Q

---

If you feel that your particles look a bit monochrome you can always try using Color Fade to give your particles a stunning and smooth color transition that will for sure make them stand out!

Examples
With:

• https://youtu.be/me7r4Q5UQUo
  
• https://youtu.be/GyIIRIRdOio

Without:

• https://youtu.be/eTpT75wTw14
  
• https://youtu.be/0iWnREwyUCo

---

Locked Rotation / Horn Effects / 3D Particles are particles which take on a 3D shape, I will be calling them Objects, you want to make these type of Unsuals as clean as possible, you want all the attention to be going to your object while also sometimes having, you guessed it! particle background, but make sure its simple and also fits the effect!.

Examples
With:

• https://youtu.be/FaPRLGEuagA

Without:

• https://youtu.be/d8ibTs8VbvQ

- Always use colour fade, have variation in colours in your effects.
- Make use of the workshop you have, use references and take inspiration from others (without making it obvious you're copying them)
- Download and use the update particles, looking over the new unusual effects that got into the game and using the values and knowledge to your advantage.
- The more you make stuff, the more you'll learn what mixes well when layering with other particles.
- One thing you must understand is that the particle editor sucks and has so many bugs, so some stuff might just break.
- Organise your files

PRACTICE MAKES PERFECT

If you'd like me to personally teach you how to make stuff, i do that for free, just add me and let me know you're wanting teaching (Lothudus#2137)

ALSO VOTE FOR MY STUFF!

As you should know by now childing your particle systems to a parent system is what makes the actual effect. What you may or may not have noticed is that the order in which you child them actually matters. Whichever your first system is in the list will render first, anything after that will render after and on top. (There are situations where this may not be the case but I will not go into that here.)





This easiest way you can utilize this is in your detailing sprites. Let's say you have a really nice space cloud set up but you want to make it a bit more special.

BASIC BLUE SPACE CLOUD EFFECT HERE

I personally like to use the plasma1 or the wispysmoke sprites and I typically choose a bright color that contrasts with the cloud's.

SHOW EXAMPLE SYSTEM

Looks good but lets radius random and radius scale them so it has a bit more life to it

EXAMPLE

Great so now what we want to do is make sure these highlight sprites are above the clouds in the parent list.

EXAMPLE

Lets see what it looks like

SHOW

-Never ever do pixel effects
-If possible, use different colors in an effect. It will make it look more dynamic and alive. You could do it with color random by putting 2 somewhat similar colors in, you can do it by making some definitions have a different color, a contrasting yellow sparkles on a purple background, for example. Color fade also works good, though i dont use it very often.
-Ask for feedback
-Collab with other particle lads to make cool-looking things even cooler
NERD ALERT
-Never use alpha fade and decay, use alpha fade in random + fade out random + lifespan decay.
If you are working with a cp-remapping color fade, you can change the speed of color fade by lowering the speed of the color cp, and change the rough colors its going through by changing rotation axis.
-All hat local space coordinates are twisted: instead of x y z its -y -z -x
-While you can't remap scalar to roll since roll isn't technically a scalar, you can either steal the broken
Script from the timewarp spiral or medibeam particles, or, as i do, you could do remap initial roll in initializers
-Remap position to player is client-sided, which allows for some fun i will not reveal just yet
-Operator fade parameters present in every function can be used to time offset specific particle functions, like setting operator fade in start and end to 2 on rotate around axis will make particles spawn as they should and then start to spin after 2 seconds. You can even make it oscillate to have some function operate in bursts
-Never use rotation speed random, nebula uses it and after some time the blue clouds start spinning rapidly
-You can use the same operator and initializer a couple times, for example: All stuff related to scalars and vectors, radius scales, offset randoms, rotation randoms, velocity randoms, movement basics, etc
-Never loop the child hierarchy. Rookie mistake.
-You dont need engine preview
-You can even use multiple instances render_animated_sprites to make a particle brighter than possible with color and alpha without having to copy it and add over eachother, works flawlessly with sparkles, making them bright but not additive
-You can add the same child to a hierarchy multiple times. This is useful when you have a particle with a rope trail that you need to have spawned multiple times, but you can't do it because of how position from parent particles works on ropes

One of the most helpful things I picked up on in particle editing (be Unity or Source) was the value of using additive particles. Additive Particles are a tag for particles to let the engine know it needs to add the alpha and color of each particle together, meaning that that more there are, the brighter it will be, at least in the Source engine.

Let's take a look at some techniques I use with additive particles.

For this effect, Mischievous Murk, I had several layers of additive particles. One being a glow at the center of the effect, and 2 very light additive layers to brighten up and blend the layers together. Making a layer of very light alpha (Eg. 16) glow particles can manage this effect.

Here is the difference of with the additive layers,


And without.


With another effect, here it is with,


And without.


Experiment with these, and you should have some very nice looking, smooth effects!

• In terms of size and scale, import and review the existing TF2 effects and compare them to your own effects. If your effect is bigger than any of the effects that are accepted in the game then chances are that you need to scale your effect down to a reasonable size. You can try adding a game effect as a child of your custom effect for a size comparison.
  
  
• Before shipping an effect, reduce the maximum particle limit per particle system definition. Don't leave the default limit as 0/1000. For example, if a particle's maximum emission count is 40/1000 then set the limit to 40/45. It isn't necessary to do this but it helps with finalising an effect.
  
  
• Before shipping an effect, attempt to test the effect in different lighting environments and on different classes doing different taunts. This is important for taunt effects because some effects may not look great with different taunts. An example is with the "I See You" taunt, (one of the shortest taunts in the game) make sure the effect emits enough to be able to be seen before the taunt ends. For cases like the Box Trot taunt (Spy hides inside a box), make sure that some of the effect can at least be seen outside of it. Both of these examples are extreme cases but they are at least a guideline to follow.
  
  
• Before shipping an effect, it's best practice to use the command: host_timescale in the console in order to test if the effect breaks after being emitted for a long time. An example of a broken effect is one with oscillation that may desync over time if their parameters are incorrect.
  
  
• It is best practice to not use other people's sprites that are already available in the workshop directory. Make the sprites yourself or use the existing sprites that are in the base game. Some accepted effects already use sprites that are in the workshop directory but they are usually small things like glows. It is best to not use existing well drawn workshop assets.
  
  
• It is not necessary for internal particle filenames to match the name of the effect. Valve reads the title and description of the workshop submission for effect names.
  
  
• Internally, most effect names for TF2 are lowercase and titled something similar to the following:
  
  Hat effects:
  unusual_effectname_parent
  Hat effects (team coloured):
  unusual_effectname_teamcolor_red
  unusual_effectname_teamcolor_blue
  
  Taunt effects:
  utaunt_effectname_parent
  Taunt effects (team coloured):
  utaunt_effectname_teamcolor_red
  utaunt_effectname_teamcolor_blue
  
  Do not worry about this too much because Valve do internally rename the effects in TF2 to work with the game.
  
  
• When you are making custom names and custom sprites for your particle effect, make the names unique so that they don't clash with other effects and sprite names that are already in the game. For example, don't name a sprite "circle", name it something like "incandescent_fire_circle".
  
  
• The directories for the workshop particle systems are:
  
  foldername/particles/unusual_effectname.pcf
  foldername/materials/effects/workshop/spritename.vtf
  foldername/materials/effects/workshop/spritename.vmt
  
  Alternatively, some workshoppers put their sprites into a custom folder:
  
  foldername/materials/effects/workshop/animated_spritename/spritename.vtf
  foldername/materials/effects/workshop/animated_spritename/spritename.vmt
  
  This is usually done for sprites that are animated or have multiple frames but it's not always necessary.