API Reference
The plugin has two sides. The Studio side (every chapter up to this section) is for authoring effects — the property panel, graphs, the Inventory, the Toolbench. The runtime side, documented here, is for triggering those effects from your game’s scripts.
When you Transform an item in Studio, the plugin saves the transformed instance into your place file. The runtime module saves alongside it — usually in ReplicatedStorage (auto-placed when the Emit Code panel opens) or in workspace (placed by the QMenu’s Insert Module button). At play time, your scripts require the module, activate the engine, and call emit methods on the transformed items the player should see effects on.
The one-method shortcut. Most game code only needs three lines:
requirethe module, call:Activate()once at game start, then callPart_Icles:AbsoluteEmit(item)whenever a VFX should fire.:AbsoluteEmitaccepts any instance — a single transformed Part, a Folder full of mixed transformed and native emitters, an entire Model rig, evenworkspace— and triggers every emitter the subtree contains using each one’s authored timing. The rest of this section documents the precision-control methods you can graduate to when you outgrow the simplicity of fire-everything; the Emission chapter covers:AbsoluteEmitin full.
This section covers the full runtime API. About 30 public methods, grouped by purpose:
| Chapter | Methods covered |
|---|---|
| Getting Started | Where the module lives in your place, the require pattern, your first emit. |
| Lifecycle | :Activate, :Deactivate, :GetFolder. |
| Emission | The six top-level dispatchers: :Emit, :EmitAnimate, :Enable, :EnableEmit, :Disable, :AbsoluteEmit. |
| Per-type Methods | The 10 per-type emit methods + 9 per-type Animate-mode methods + :Transform/:TransformModel. |
| Texture Pinning | :Preload, :Deload for keeping asset bytes resident. |
| Examples | Four worked patterns: sword spark, fireball clone, on-screen-only emission, recursive :AbsoluteEmit. |
Studio vs runtime
Section titled “Studio vs runtime”In Studio, the plugin auto-manages its own runtime — clicking the toolbar button activates the engine, closing it deactivates. Authoring is live, the test particles emit, you see the effect immediately.
In a published game, the plugin isn’t running. Only the transformed instances it saved into your place are present, plus the runtime module. Your scripts have to call :Activate() themselves on game start, then call emit methods when the player triggers an action. The plugin’s UI doesn’t exist outside Studio — only the data and the runtime do.
This is a normal split for Roblox plugins. The plugin authors content in Studio; your scripts use the content at runtime. The runtime is small (a Heartbeat loop + per-type emit/update logic), and :Activate() only needs to be called once per game session.
Reading order
Section titled “Reading order”If you’ve never used the runtime API: read top-to-bottom. The chapters are ordered to build up.
If you’re looking up a specific method: jump straight to the chapter that owns it. Each method has its own section with signature, semantics, and example.
If you want a worked-example launch pad: start with Examples and back-fill the API chapters from the cross-links inside.
What’s next
Section titled “What’s next”Getting Started is the next chapter — where the runtime module is placed in your game, how to require it, and your first emit call.