Attachment

Your character has a sword. The sword has an Attachment at its tip — a tiny invisible marker, parented to the sword. You want sparks to fly off that tip as the character swings.

Linking is one way to do this: transform a separate Part as the emitter (any helper instance in your scene), and point its Link Dir. at the tip Attachment. The link target itself never has to be transformed; Linking only needs the emitter side to be transformed, and from there it tracks whatever instance you hand it. That path works, but you’ve now got a helper Part in your scene that exists only to host the emitter machinery.

The plugin gives you a more direct route: transform the Attachment itself.

When you transform an Attachment, every emitted particle spawns at the Attachment’s current world position and orientation. Roblox derives an Attachment’s world position from its parent’s CFrame composed with the Attachment’s own local CFrame (Parent.CFrame * Attachment.CFrame — the same composition behind the WorldCFrame property). As the sword swings, the parent moves, and the spawn point moves with it — no Linking needed.

Attachment is Part with the parent-tracking already wired up.

What it transforms

Any Attachment instance.

The Attachment doesn’t need to be inside a Part for transformation to succeed, but parent-relative behaviour assumes there is a parent — the typical case is an Attachment inside a sword tip, a character limb, a tool, or a weapon model. An orphaned Attachment (parented directly to workspace) still emits, but its CFrame is treated as world-space.

Why reach for Attachment instead of Part

Three reasons:

• Parent-following is automatic. You don’t need to wire up Link, LinkMode, or per-frame tracking. The Attachment’s parent moves, and the spawn point follows.
• No spatial properties to misconfigure. Attachment has no bounding region, so the plugin doesn’t expose Shape, Spawn on, or Hollow. You can’t accidentally fill a sphere when you wanted a point source.
• The visual is whatever you nest inside it. Attachment’s Render Template is a container — drop a Decal to draw a flat sprite, drop a Beam to draw a textured streak between two Attachments, drop a PointLight for an emitted glow. Each emitted particle is a duplicate of the container, with whatever children you put inside.

When not to reach for Attachment: when the visual you want is a 3D mesh with three-axis sizing and material rendering. That’s Part’s territory; Attachment doesn’t have Color, Transparency, Brightness, or Size graphs.

Properties at a glance

The full surface area, grouped by panel section. Every row links to the shared chapter — Attachment has no type-specific properties beyond what’s covered there.

Spawning (shared)

Panel label	Data attribute	Type	Default	What it does
Rate	Rate	number	10	Particles per second
Lifetime	Lifetime	NumberRange	1	Seconds each particle lives, with random variation
SpreadAngle	SpreadAngle	Vector2	(0, 0)	Cone of random deviation, in degrees
Direction	EmissionDirection	enum	Top	Which face of the Attachment’s frame particles fly out of
Position	PosX, PosY, PosZ	three NumberRange	0	Random offset from the Attachment at spawn
Pos. Mode	PosMode	enum	Local	Frame the position offsets roll in
Orientation	Orientation	enum	None	How particles face camera or velocity
Z-Offset	ZOffset	number	0	Render-depth bias for layering
EmitCount	EmitCount	number	0	One-shot burst count
EmitDelay	EmitDelay	number	0	Wait before first particle
EmitDuration	EmitDuration	number	0	Seconds of continuous loop after the initial bursts. 0 skips the loop

Movement (shared)

Panel label	Data attribute	Type	Default	What it does
Speed	Speed	NumberSequence	0	Velocity magnitude over life
Acceleration	Acceleration	Vector3	(0,0,0)	Constant force vector each frame
Drag	Drag	number	0	Exponential velocity decay
Dir. Mode	DirMode	enum	RigidLocal	Which frame the direction is in
Reverse Motion	InvertMotion	boolean	false	Plays trajectory in reverse
Rotation	RotX, RotY, RotZ	three NumberRange	0	Random initial rotation per axis at spawn
Rotation Mode	RotMode	enum	OverLife	Whether RotSpeed is per-life or per-second
Rotation Speed	RotSpeedX, Y, Z	three NumberSequence	0	Rotation speed per axis

Advanced (shared)

Panel label	Data attribute	Type	Default	What it does
Anim. Steps	TotalKeyFrames	number	100	Simulation sample steps per particle
Linger	PartLife	number	0	Seconds the particle lingers after Lifetime

That’s the entire panel. No Appearance section, no Shape section, no Flipbook section — those are absent because Attachment doesn’t have a self-rendered visual to colour, a bounding region to spawn within, or a texture to flip through. The visual comes from whatever you nest inside the Render Template.

The Render Template, for Attachment

When you transform an Attachment, the plugin creates a RenderTemplate child as a clone of the Attachment itself — with its CFrame reset to origin, so the duplicate sits at zero rather than wherever the source Attachment is currently positioned.

By itself that clone draws nothing. Attachments aren’t rendered. Whatever child instances you put inside the Render Template — Decal, Beam, Trail, PointLight, BillboardGui, anything visible — those are what each emitted duplicate carries.

A few worked-out cases:

• A flat sprite. Drop a Decal inside RenderTemplate. Each emitted particle is now an Attachment with a Decal billboard child. The Decal’s Texture property is the image your particles look like.
• A trail-streak. Drop a Trail inside RenderTemplate connected between this Attachment and a sibling. Each emitted Attachment drags its own trail through space — useful for sparking comet effects.
• A glowing emitter. Drop a PointLight inside RenderTemplate. Each particle emits light as it travels.
• Multiple visuals composed. Drop a Decal and a PointLight inside one Render Template. Each particle is a glowing sprite. The Render Template can hold any number of children.

The trade-off is that Color, Transparency, and Brightness graphs don’t apply at the Attachment level. If you want fading sprites, the fade has to be authored on the child instance — for instance, the Decal’s Transparency is read at emission, but it doesn’t animate over the particle’s life. For per-life colour fades, reach for Part instead.

Parent-relative motion in detail

Each emitted Attachment-particle is parented to the original Attachment’s Parent (or to EmitParent if you’ve overridden it — covered below). Its CFrame is set to a particle-local position that adds to whatever the parent’s CFrame happens to be at that frame.

The engine path is straightforward: at emission time, the particle’s local CFrame is computed once. Each frame, the engine updates the particle’s local CFrame for motion (Speed, Acceleration, Drag all act on it), but the on-screen position is implicitly the parent’s CFrame composed with the local CFrame. As the parent (the sword, the limb, the tool) rotates and translates, the particles move with it for free.

This is the behaviour you’d otherwise wire up by hand with a Part emitter and Link Mode = Weld. Attachment makes it the default.

EmitParent — choosing where particles parent

By default, emitted Attachment-particles parent to the Attachment’s own parent. A sword-tip Attachment’s particles end up inside the sword model.

If you set EmitParent to a different instance — a folder named Effects in workspace, say — the plugin reprojects the spawn CFrame through world space so the particles still spawn at the Attachment’s current location, but live as children of the chosen container instead.

Why bother? Two reasons. First, cleanliness: if you have many emitters across many tools and characters, gathering all their particles in one container makes inspection and bulk cleanup easier. Second, parent independence: particles parented inside a sword are destroyed when the sword is destroyed (a death animation, a tool unequip). Particles parented to workspace outlive their source. The choice depends on whether you want particles to persist past the source.

Direction — which way is “up” for an Attachment

Same enum as Part: Top, Bottom, Front, Back, Left, Right. But for an Attachment, the faces are derived from the Attachment’s own orientation — its CFrame.UpVector, RightVector, etc. — composed with the parent’s frame.

If the Attachment is rotated 90° relative to its parent, its Top face points sideways from the parent’s perspective. This is why Direction works intuitively: the sword tip’s Top is whichever way the tip points, regardless of how the sword is held.

Linking, briefly

Attachment supports the Link ObjectValue, but the parent-relative model handles tracking automatically — you only need Link when you want particles to follow something other than the Attachment’s own parent.

The classic case: an Attachment inside a sword that should emit particles tracking the character’s head instead of the sword. Drop the head as the Link Dir. target and the particles follow the head’s CFrame, ignoring the sword’s motion.

For most uses, leave Link Dir. empty. The Attachment’s parent provides the tracking on its own.

Worth knowing

A few Attachment-specific quirks.

An orphaned Attachment falls back to world-space. If the Attachment is parented directly to workspace (no Part or Model ancestor), there’s no parent-relative frame to compose with — the engine treats the Attachment’s CFrame as world-space and the particles spawn there directly. This works, but the parent-following advantage disappears. If you want world-space emission with no parent-following, a Part emitter is more honest about the choice.

The Render Template is empty by default. Transforming an Attachment doesn’t pre-populate the Render Template with anything to look at — you have to drop a visual instance inside. A first-time user might transform an Attachment, set Rate = 100, and see… no particles. They’re emitting; they just have no visual. Open the Attachment in Studio’s Explorer, find the RenderTemplate, and add a Decal or whatever visual fits your effect.

No LinkSource row in the panel. Transform stamps a LinkSource = "None" attribute on Attachment the same way it does on Part, but the Attachment property panel doesn’t surface a LinkSource dropdown — Attachment’s parent-relative emit model already provides the parent-following spawn behaviour without needing an explicit link source. LinkMode is also omitted from the Attachment panel for the same reason. If you need a non-parent link target, set Link Dir. and edit LinkSource directly via Studio’s Attributes panel — or switch to a Part emitter where both rows are first-class.

The Pos. Mode = RigidLocal corner case. If you set RigidLocal on an Attachment with PosX/Y/Z ranges, the position offset is sampled in local space and then locked to world-space at spawn. Combined with parent rotation mid-flight, this produces particles that don’t rotate with the parent after spawn — the spawn point follows the parent, but the spread cone freezes at world-space. Useful for “shower” effects where the source moves but particles drift on their own.

What’s next

Attachment was the simplest of the workspace types — Part with the spatial wiring built in. The next type is more interesting: a Beam doesn’t fly anywhere. It connects two Attachments with a textured line and animates the look of that line over time. The motion model is something we haven’t seen yet — the geometry doesn’t move, the texture does.