roblox-core git:20260919.e20f73cA

Immutable. This exact content never changes and is served at /api/v1/blob/d63eed537b7005e4.

---
name: roblox-core
description: "Choose Roblox services, script locations, and execution contexts. Use for Luau types, serialization, module loading, streaming, and client-server data model questions."
last_reviewed: 2026-06-17
---

# roblox-core

**Key sources:** https://create.roblox.com/docs/en-us/scripting/services, https://create.roblox.com/docs/en-us/luau, https://create.roblox.com/docs/en-us/luau/tables, https://create.roblox.com/docs/en-us/luau/type-checking, https://create.roblox.com/docs/en-us/scripting/locations, https://create.roblox.com/docs/en-us/projects/data-model, https://create.roblox.com/docs/en-us/projects/client-server, https://create.roblox.com/docs/en-us/workspace/streaming, https://create.roblox.com/docs/en-us/scripting/multithreading, https://create.roblox.com/docs/en-us/scripting/attributes

## Script initialization

1. `local Service = game:GetService("ServiceName")`. Do this once, name the variable after the service.
2. `local Module = require(ReplicatedStorage:WaitForChild("Module"))`
3. Local helper functions.
4. Connect to events.

Services are the primary way you access engine functionality instead of a traditional standard library.

## Modern task library

Use the modern `task` API; the legacy globals `wait()`, `spawn()`, and `delay()` are deprecated/soft-deprecated:

- `task.wait(n?)`: yields for about `n` seconds (default one frame) and returns elapsed time.
- `task.spawn(f, ...)`: schedules `f` to run asynchronously.
- `task.defer(f, ...)`: defers `f` until after the current event cycle.
- `task.cancel(thread)`: cancels a thread returned by `task.spawn`/`task.defer`.

For parallel code, `task.desynchronize()` and `task.synchronize()` move the current thread between the parallel and serial phases.

## Services by purpose

**Container / hierarchy services** (visible in Explorer, part of the DataModel):
- Workspace (3D content)
- Lighting (environment, atmosphere, post effects)
- ReplicatedStorage / ReplicatedFirst (shared code & assets)
- ServerScriptService (server-only logic)
- StarterGui / StarterPlayer / StarterPack (templates cloned to players)
- Players, Teams, SoundService, etc.

**Core runtime & scripting services:**
- RunService: Heartbeat fires after physics on both sides; PreSimulation fires before physics on both sides; PreRender is client-only and fires before rendering.
- TweenService (see animation skill)
- CollectionService (tags)
- ContextActionService, UserInputService, GuiService
- ContentProvider (preloading)

**Cloud / persistence / cross-server:**
- DataStoreService, MemoryStoreService, MessagingService (see roblox-datastores skill)

**Monetization:**
- MarketplaceService (gamepasses, dev products; see dedicated skill)
- BadgeService, etc.

**Other high-value ones:** TeleportService, AnalyticsService, HttpService (outbound only + JSONEncode/Decode), PathfindingService, etc.

Discover services with `game:GetService` (known services) or `game:FindService` (optional). Avoid using `game:GetChildren()` for service discovery. Not every DataModel child is a service, and services can be lazily created. Acquire each service once per script/module.

## Instance creation best practice

Configure an instance before parenting it to avoid redundant replication and extra changed events:

```lua
local part = Instance.new("Part")
part.Anchored = true
part.Size = Vector3.new(4, 1, 2)
part.Position = Vector3.new(0, 10, 0)
part.Parent = workspace
```

Set `Parent` last; do not use the `Instance.new("Part", parent)` two-argument form.

## Types and serialization

Read [luau-data-types-and-serialization.md](references/luau-data-types-and-serialization.md) before designing persisted values or debugging serialization. DataStores, JSON, and remotes have different supported types. A successful `JSONEncode` is a useful check, but it does not prove that a value meets every DataStore constraint.

## Type checking

Gradual and opt-in. Use `--!strict` at the top of a file (it is file-level) or a `.luaurc` project configuration for project-wide type checking. Add annotations (`local x: number`, function signatures) for large modules. Inference does a lot of the work. Catches bugs at edit time with zero runtime cost.

## Script locations and execution contexts

- ServerScriptService + Script (`RunContext.Server`) → server only, with access to server APIs such as DataStores.
- ReplicatedStorage → stores shared ModuleScripts/assets. A Script here only runs if its `RunContext` is set to `Client` or `Server`; use ModuleScripts for shared logic.
- StarterGui + LocalScript → per-player client only (inside the cloned PlayerGui).
- ReplicatedFirst + LocalScript → very early client execution (loading screens).
- Actor + Script with `RunContext.Client/Server` → can run Parallel Luau when the code calls `task.desynchronize()` or uses `ConnectParallel()`. The Actor must be parented to the DataModel and the Script must have an explicit RunContext; placing a Script inside an Actor alone does not parallelize it. `require()` can be called from parallel contexts only when the module itself is parallel-safe; most engine APIs and many modules are not.
- Tools have special execution contexts. HopperBins are deprecated/legacy and should not be used for new work.

Modern Roblox uses `BaseScript.RunContext` (`Legacy`, `Server`, `Client`, `Plugin`). `Legacy` exists only for backward compatibility and is location-dependent; prefer explicit `Server` or `Client` for new code. `RunContext` is set in Studio's Properties window and is read-only at runtime.

Always branch runtime authority with `RunService:IsServer()` and `IsClient()`. `IsStudio()` detects the environment (Studio vs. live), not runtime context, so use it only for test/development guards.

**Never** put datastore writes, economy, or authoritative gameplay logic anywhere a client can influence it directly.

## "Files" and data in Luau/Roblox

Inside a running experience there is **no direct filesystem access** (security). You cannot open arbitrary files or write player-visible logs.

What you have instead:
- DataStores / MemoryStores for persistent or temporary "save data".
- ModuleScripts for reusable code (`require` works like a cached module system: a ModuleScript runs once and returns the same value on subsequent requires).
- HttpService:JSONEncode/Decode + web calls for external data exchange.
- In Studio: plugins have limited file APIs, and external tools (Rojo, Script Sync) can sync code from the filesystem, but experience scripts never have arbitrary filesystem access.

For complex data you often serialize tables to JSON strings for storage or transmission.

## Additional runtime considerations

- **Attributes**: use `:SetAttribute`/`GetAttribute` for lightweight per-instance data; prefer them over legacy Value objects.
- **Random**: use the `Random` class (`Random.new(seed)`) for deterministic or independent random streams instead of global `math.randomseed`.
- **StreamingEnabled**: on the client, instances can stream in/out; always use `WaitForChild`/`Instance.StreamingMode` defensively and avoid hard references to far-away parts.
- **table utilities**: `table.create(n, value)`, `table.find(t, value)`, `table.clone(t)`, and `table.freeze(t)`/`table.isfrozen(t)` are the modern helpers.
- **BaseScript.Enabled**: disables/enables a script without deleting it.
- **ModuleScript caching**: `require` executes a ModuleScript once per environment and caches the returned value.
- **Sequence / physical types**: `NumberSequence`, `ColorSequence`, and `PhysicalProperties` are common Roblox datatypes for particles, beams, and part materials.

## Architecture foundations

- Server authority is the default safe posture.
- Replication is selective and streaming-aware.
- Use ReplicatedStorage for shared modules/assets, ServerScriptService for server logic, StarterGui for client UI entry points.
- CollectionService tags + Attributes for lightweight grouping and data without heavy Instance hierarchies.
- Parallel Luau + Actors when you need CPU-bound work off the main thread.

## Scripts

- `scripts/ServiceHelper.lua`: small utilities for safely acquiring services and requiring modules with timeouts.

<!-- catalog:references:start -->
## Reference index

- [luau-data-types-and-serialization.md](references/luau-data-types-and-serialization.md): Choose data types or diagnose serialization failures.
- [script-locations-contexts-and-architecture.md](references/script-locations-contexts-and-architecture.md): Decide where scripts run or debug loading and replication.
- [services-catalog-and-usage.md](references/services-catalog-and-usage.md): Choose a service or load services and modules.
<!-- catalog:references:end -->