Advanced

Used by: every emitter type except Trail. Beam exposes only Anim. Steps and Timescale; every other type (Part, Attachment, Model, PointLight, Blur, Bloom, ColorCorrection, Atmosphere, ImageLabel) has the full set: Anim. Steps, Linger, Timescale.

You won’t reach for these properties on the first day. They live under the Advanced section of the property panel for a reason — they fine-tune simulation behaviour, fix specific corner cases, and trade off resolution against cost. Most authoring works fine with their defaults.

But when you need them, knowing what each one does matters. This chapter covers the three shared advanced properties.

A note on VelocityVectored: older saved emitters may have a VelocityVectored = true boolean attribute. The plugin reads it for backwards compatibility — it’s equivalent to DirMode = "Local" (covered in Motion). New emitters set DirMode directly; the old attribute lingers only on legacy data.

Properties at a glance

Panel label	Data attribute	Type	Default	What it does
Anim. Steps	TotalKeyFrames	number	100	How many discrete sample-steps the simulator uses per particle
Linger	PartLife	number	0	Seconds a particle persists after its Lifetime expires
Timescale	Timescale	NumberSequence	1	Per-frame time scaling on the appearance graphs

Anim. Steps

UI label: Anim. Steps. Data attribute: TotalKeyFrames.

The number of discrete simulation steps the engine takes over each particle’s lifetime.

Here’s the situation. A particle lives for some duration — say, two seconds. During that time, the engine has to evaluate its Speed graph, its Size graphs, its RotSpeed graphs to advance the particle’s CFrame. Doing that work every frame at high frame-rate is expensive when many particles are live.

The plugin solves this by quantizing the simulation. It divides each particle’s lifetime into TotalKeyFrames discrete steps — 100 steps by default. Each frame, the engine computes which step the particle is currently at, and only advances the simulation when the step actually changes. Within a single step the visual interpolates between the two endpoint CFrames smoothly, but the underlying graph queries happen once per step, not once per frame.

Higher TotalKeyFrames means finer time granularity — more graph samples across the lifetime, smoother motion that follows the graphs more faithfully. Lower means coarser steps that cost less but show visible stepping on long-lived particles.

100 is the sweet spot for most particles. A long-lived particle (5+ seconds) might benefit from 200 or 300 if you can see step-changes in motion. A very short-lived particle (under a second) can drop to 50 without anyone noticing — its lifetime is already too short for the sampling resolution to matter.

You’d lower TotalKeyFrames only when you have many particles and need every microsecond. You’d raise it only when you can see visible stepping in long-lived effects.

Linger

UI label: Linger. Data attribute: PartLife.

Seconds a particle persists after its Lifetime expires, before the engine destroys it.

Wait, didn’t Lifetime decide when the particle dies?

Yes. But sometimes you want the visual to linger a moment after the simulation has stopped — the particle stays in place, frozen at its last state, then disappears. Smoke that hangs in the air after the wind has stopped pushing it; sparks that sit briefly before fading.

PartLife gives you that linger window. With PartLife = 0 (the default), the particle is destroyed immediately when its Lifetime ends. With PartLife = 0.5, it stays for an extra half-second after — frozen at whatever state the graphs ended on — then is destroyed.

This is purely a visual extension. The simulation has stopped; nothing is updating during the linger. It’s the equivalent of pausing on the last frame.

A small PartLife of 0.1 to 0.3 often makes effects feel more grounded — particles don’t blink out the moment their motion ends; they have a moment of stillness first.

PartLife is constrained to non-negative values. The Randomizer respects this — randomising Linger will roll a value between 0 and the configured upper bound, never a negative one.

Timescale

UI label: Timescale. Data attribute: Timescale.

A NumberSequence graph that scales each particle’s playback rate over its lifetime. Constant 1 is normal playback. 0.5 plays the appearance graphs (Color, Transparency, Size, RotSpeed, and every other per-life graph) at half speed. 0 freezes the animation at whatever frame each particle is currently at. Negative values rewind playback.

The graph is sampled per particle, per frame, in real time — so changing the Timescale curve mid-emission takes effect immediately for every live particle, with no waiting for the next emission. Most authoring leaves this at constant 1; reach for it when you want a slow-mo group of particles inside a faster burst, when one cluster should pause and resume mid-flight, or when you want a “reversed” sweep that retraces its own motion.

The death gate

Particles only despawn when both conditions hold: the graph has finished playing and effective time sits at a lifetime boundary (effective ≥ Lifetime for forward playback, or effective ≤ 0 for reverse playback). The two-condition gate means:

• Timescale = 0 freezes a particle indefinitely — no auto-despawn. The particle stays frozen at its current state until you change Timescale away from 0 and let it run to a boundary.
• Negative Timescale rewinds without prematurely killing the particle. As long as the graph keeps it inside [0, Lifetime], it lives. Hit the 0 boundary going backward and it despawns; flip Timescale back to positive before that, and it survives.
• For everyday positive playback (Timescale > 0), the gate behaves like every other particle system: particle reaches Lifetime, particle dies.

Edge cases

• Beam exposes Timescale too. A Beam’s Timescale graph scales sampling for the appearance graphs (Width, CurveSize, GraphBlender state cycling) on each emitted Beam clone.
• TrailEmitter has a Timescale slot in its Advanced section as well — same semantics as the other transformed types.
• Negative values are allowed. The Randomizer doesn’t constrain Timescale to non-negative the way it does Linger.
• The SetTimescale script override (covered in Per-type Methods) wins over the graph for its active window — useful for slo-mo cinematics where you want every live particle paused or slowed for a beat.

What’s next

The advanced fine-tuning properties are now covered. The fourth and last shared chapter is Mesh Flipbooks — frame-by-frame texture animation, used by Part and Beam types.

Looking for “Rotation” (initial rotation ranges)? Initial rotation lives in the Motion section of the panel, alongside Rotation Mode and Rotation Speed — not Advanced. See Motion → Rotation (initial).