Getting Started

Three steps to your first runtime emission:

1. Find the module.
2. Require it.
3. Activate the engine and emit.

This chapter covers each. Detailed lifecycle methods (:Activate, :Deactivate, :GetFolder) are documented in the Lifecycle chapter.

Where the module gets placed

The plugin keeps the runtime module internal until you tell it to drop a copy into your place. There are two ways to get one:

Option A — Insert Module (workspace). Open the plugin’s QMenu, click Insert Module. The plugin destroys any existing workspace.Part_Icles and clones a fresh copy in:

workspace
└── Part_Icles  (ModuleScript)

Option B — open the Emit Code panel (ReplicatedStorage). The first time you open the Emit Code tool, the plugin clones a fresh copy into ReplicatedStorage (the convention used by the snippets that tool generates):

ReplicatedStorage
└── Part_Icles  (ModuleScript)

Either copy works at runtime. The choice is just where the module belongs in your hierarchy: workspace bundles the module with a specific scene, ReplicatedStorage matches the standard Roblox convention and is what Emit Code’s auto-generated snippets require from.

Both flows are idempotent — re-running them after the plugin auto-updates refreshes the existing copy to the current version rather than duplicating. The plugin also auto-refreshes any existing copies on Studio startup, so a stale module from a previous version will quietly catch up the next time you reopen the place.

The module saves with your place file, so when the game is published, the runtime travels with it. Players don’t need any plugin installed — only the module the plugin left behind. See the Toolbench Utilities chapter for the full tool description.

Requiring the module

Standard Roblox require pattern. Pick whichever path matches where the module is placed in your place file:

-- ReplicatedStorage copy (matches Emit Code's generated snippets)
local Part_Icles = require(game.ReplicatedStorage:WaitForChild("Part_Icles"))

-- Or, workspace copy (from Insert Module)
local Part_Icles = require(workspace:WaitForChild("Part_Icles"))

The rest of this guide uses the ReplicatedStorage form because it pairs with what the Emit Code tool generates. Substitute the workspace path freely if that’s where your copy is placed.

:WaitForChild matters on the client side — the module replicates from the server when the player joins, and may not be present at script-execution time on the very first frame. On the server, the module is there immediately, but WaitForChild is harmless either way.

Part_Icles is now a regular Lua table with methods on it. Call them with the colon syntax:

Part_Icles:Activate()
Part_Icles:Emit(someTransformedItem)

Require once at startup and reuse the reference across your codebase. The module is a singleton — requiring it twice returns the same table.

Your first emit

Smallest possible script. Drop into ServerScriptService (or as a LocalScript in StarterPlayerScripts for client emission):

local Part_Icles = require(game.ReplicatedStorage:WaitForChild("Part_Icles"))
Part_Icles:Activate()

local effect = workspace:WaitForChild("MyEffect")
Part_Icles:AbsoluteEmit(effect)

Three things happen:

1. require loads the module table.
2. :Activate connects the engine’s Heartbeat loop and prepares internal state. Without this step the emit calls don’t error — they spawn frozen clones that never tick, then accumulate forever. Always activate first.
3. :AbsoluteEmit walks the subtree under MyEffect and fires every emitter inside — every transformed Part / Beam / Attachment / Model / PointLight / ImageLabel / screen-space type plus every native ParticleEmitter and Trail. Each one uses its own authored timing (EmitCount, EmitDelay, EmitDuration). One call. MyEffect can be a single transformed item, a Folder of many emitters, an entire Model rig, even workspace itself — :AbsoluteEmit accepts any input.

That’s the whole pattern. The other emit dispatchers — :Emit, :EmitAnimate, :Enable, :EnableEmit, :Disable — exist for the cases where you want precision control over a single emitter (one burst, continuous loop with explicit duration, mid-flight cancel). For most game code, :AbsoluteEmit is the call. The plugin’s Emit Code tool generates :AbsoluteEmit calls by default for the same reason.

Server-side vs client-side

Both work. Pick based on where you want the emission to be authoritative:

• Server-side emission — the server calls :Emit, the resulting particle clones replicate to every client. Consistent across all players, but adds replication cost.
• Client-side emission — each client runs its own runtime, emits its own particles. No replication cost. Common pattern for cosmetic effects (sparks, bloom flashes) where small per-client variation doesn’t matter.

You can use both in the same game. Each runtime activates independently — call :Activate once on the server (in ServerScriptService) and once per client (in StarterPlayerScripts’s LocalScript).

What’s next

With the runtime activated and your first emit fired, the next chapter — Lifecycle — documents :Activate, :Deactivate, and :GetFolder in full. Then Emission covers the six dispatcher methods.