Linking

Imagine you have a sword. You want sparks to fly off the tip as the player swings it. You could write a script that moves your emitter every frame to match the sword’s position, but that’s tedious and easy to get wrong.

Linking does it for you. A linked emitter inherits another instance’s CFrame automatically. As the link target moves, the emitter’s particles move with it.

How linking is set up

Three things on your transformed item, all in the property panel’s Advanced section:

• Link Dir. is the ObjectValue you saw in chapter 2 (data attribute: Link). You point it at the instance you want to follow. The sword’s tip Attachment. A character’s RightHand. The handle of a wand.
• Link is a dropdown labelled with the same word (data attribute: LinkSource). It picks what kind of thing the linker should track. Three values: None (default — linking is off, the Link Dir. field is ignored), Object (the engine reads the Link Dir. ObjectValue and tracks whatever instance it points at), Camera (the engine tracks workspace.CurrentCamera directly, ignoring Link Dir.).
• Link Mode is an attribute on the item (data attribute: LinkMode). It picks one of four behaviours, described below. The property panel shows it as a dropdown.

You don’t have to use linking. Most emitters never need it. Reach for it when the emitter must move in step with something else — that’s what it’s for.

When to use Camera linking

Camera linking is the “track the player’s view” mode. The emitter’s particles spawn relative to wherever the camera currently is and what it’s looking at. Useful for screen-anchored effects that should feel locked to the viewport — a heat-haze emitter pinned in front of the player, a damage-vignette tinted over the camera’s forward direction, a UI-style sparkle that hovers in the player’s line of sight.

Set Link (the dropdown) to Camera and ignore Link Dir. entirely. The engine resolves workspace.CurrentCamera at emit time, so swapping cameras at runtime works correctly.

The four modes

Each mode interprets the link target’s CFrame differently. The four modes cover the cross-product of two binary choices: does position track the link continuously? and does rotation track the link continuously? Each mode picks one combination.

Mode	Position tracks link?	Rotation tracks link?
Weld	yes (every frame)	yes (every frame)
Follow	yes (every frame)	no (uses spawn rotation, world-axis-aligned thereafter)
Pivot	yes (every frame)	rotation baked at spawn, then frozen
WeldWithoutRotation	yes (every frame; orbits the link as link rotates)	no (mesh orientation stays at spawn rotation)

Weld

The emitter inherits the target’s full CFrame — position and rotation. Particles spawn at the target’s location, oriented to the target’s facing. As the target rotates, particles rotate with it. Weld is the default LinkMode value when you transform an item.

Use cases:

• Sparks at the tip of a sword — sparks rotate as the sword rotates, reading as if they’re physically attached to the blade.
• Exhaust at the back of a vehicle — the exhaust flame stays oriented with the engine; turning the vehicle turns the flame.
• Fire on a torch — flames lean as the torch tilts, like a real flame’s column relative to the torch.
• A trailing magic wisp anchored to a moving prop — the wisp’s facing-direction follows whatever the prop is “facing” through the animation.

Follow

The emitter inherits the target’s position but not its rotation. Particles spawn at the target’s location but use the emitter’s own (or world) rotation, ignoring whichever way the target is facing.

Use cases:

• A glowing aura around a moving character — the aura’s orientation should stay reasonable (always Up, always Camera-facing) regardless of which way the character is currently looking. Follow makes the aura travel with the character without rotating it.
• Smoke rising from a moving torch — the smoke should always rise vertically; the torch can tilt without dragging the smoke off its upward column.
• Damage numbers above an enemy — Follow the enemy’s position so the numbers track them through space, but the numbers themselves should stay world-up readable.
• A targeting reticle on a target — the reticle’s position tracks the target; its facing should stay screen-aligned (toward the camera) regardless of how the target is rotated.

Pivot

The link’s rotation is baked into the particle at the moment of emission, and from then on the particle tracks the link’s position only. The particle’s initial trajectory is relative to the link’s facing direction at spawn, but subsequent rotations of the link don’t reorient the particle.

Pivot is the middle ground between Weld (rotation tracks continuously) and Follow (rotation never matters).

Use cases:

• Muzzle flashes from a gun. The spark fires in the gun’s pointing direction at the moment of firing — but if the gun rotates immediately afterward (a recoil animation, a player flicking aim mid-burst), the already-emitted sparks don’t pivot with it. They keep flying in the original direction.
• Bow-shot arrow trails. The trail’s initial direction is relative to the bow’s aim at the moment of release, but the bow’s recoil doesn’t drag the in-flight trail.
• A jetpack burst. The thrust direction is whatever the player was facing when the burst fired; jetpack burst-particles continue in that direction even if the player pivots mid-flight.
• Casting a directional spell. The cast direction is locked at the moment of casting, even if the caster turns afterward — the projectile particles trail in the cast direction, not in the now-current aim direction.

WeldWithoutRotation

The particle’s position orbits the target as the target rotates — the relative-position offset rotates with the target’s CFrame, so the particle stays “glued to” the same point on the rotating link. But the particle’s mesh orientation stays fixed at whatever world rotation it was set to.

In short: the particle goes around with the link, but never tumbles itself.

Use cases:

• Glowing emblems on a spinning wheel. A logo or mark anchored to a specific spot on a wheel — the mark should travel around with the wheel, but should always read upright (not rotate with the wheel itself).
• Labels on a turning vehicle. A status icon pinned to a specific spot on a vehicle, visible from outside, that should stay readable regardless of which way the vehicle is currently pointed.
• Orbiting glints on a tumbling object. Star-shaped sparkles anchored to specific spots on a tumbling artefact — the sparkles travel around with the artefact’s surface but always read camera-flat.
• Position-locked but orientation-locked-too markers. Anything where “I want this to be at this specific point on a moving thing, but I don’t want it spinning.”

Per-frame link tracking

Independent of which Link Mode is selected, the plugin re-applies the link transform every frame for Part and Model emitters. This keeps emitters glued to fast-moving targets even between physics ticks. You don’t enable or configure this; the engine runs it automatically whenever a Link is set.

Picking a mode in practice

Most uses fall into four buckets:

• Stuck to a moving thing that rotates → Weld. Particle inherits position and rotation continuously.
• Stuck to a moving thing whose rotation should be ignored → Follow. Position only.
• Initial rotation matters but ongoing rotation doesn’t → Pivot. Bakes link rotation at spawn, then position only.
• Position revolves around the link but mesh stays upright → WeldWithoutRotation.

Reverse Motion is not a Link Mode

If you’ve come from older docs or seen the InvertMotion attribute, you might expect “play motion in reverse” to be a Link Mode. It isn’t. Reverse Motion (the InvertMotion attribute) is a separate Movement toggle that composes with linking — covered in Motion → Reverse Motion.

You can have Reverse Motion on with any Link Mode: Welded particles play their trajectory in reverse and stay welded, Follow particles play in reverse and follow the target, and so on. The two settings are orthogonal.

What you’ve learned so far

You’re now seven chapters in. You’ve seen what Transform does, why RenderTemplate is empty, what kinds of properties exist, how graphs work, the two emission modes, and how to bind an emitter to another instance. That’s the foundation.

So far we’ve talked about emitters in the abstract — “the emitter does this,” “the particle does that.” But what changes between a Part emitter and a Beam emitter? What’s different about an Atmosphere versus an ImageLabel? Why does the Trail type behave so differently from everything else? The Particiliary is where we meet the eleven kinds of emitter, one at a time, and find out what’s unique to each.