> For the complete documentation index, see [llms.txt](https://morningheartgames.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit-ecs/reference/differences-from-core.md). # Differences from the GameObject runtime The ECS runtime applies the GameObject runtime's rules to the same assets: the same attribute sets, effects, abilities and tags. This page lists where the two differ, so you know what to expect when you move an actor to entities or when an ECS actor does not behave like its GameObject version. It has three parts: what the ECS runtime does not have, behavior that differs on purpose, and effect rules that are the same on both runtimes and easy to get wrong. Anything not listed is meant to behave the same. **Before you start** * You know the toolkit's GameObject runtime. Its [Architecture](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit/foundations/02-architecture) page describes it. * An actor runs on one runtime or the other, never both. `GasEntityAuthoring` does not create an `AbilitySystemComponent`. ## Not available on entities These parts of the toolkit work with GameObjects and scene objects, which the ECS runtime cannot use. The right column says what to use instead. | GameObject runtime | On the ECS runtime | | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ability code (`AbilityRuntime.OnActivate` and friends) | None. An ability ends at once, or when a wait or an end request ends it. See [Authoring](/docs/gameplay-ability-toolkit-ecs/build-with-it/authoring.md#abilities). | | [Ability tasks](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit/subsystems/tasks-timing) | Waits, declared on the ability. See [Waits](/docs/gameplay-ability-toolkit-ecs/build-with-it/authoring.md#waits-what-replaces-ability-tasks). | | [Montages](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit/subsystems/montage) and animation drivers | An ability's montages play in the runtime by the same rules as `MontagePlayer`: slots and slot groups, section links and jumps, notifies and notify states, the blend-out. Notifies become gameplay events. A wait steers the montage in place of a task's `JumpToSection` or `Stop` calls. Animation drivers have no counterpart: pose your characters from `GasMontagePlayback`, with any animation system. See [Montages](/docs/gameplay-ability-toolkit-ecs/build-with-it/authoring.md#montages). | | [Targeting](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit/subsystems/targeting) (collectors, indicators) | A delivery ability finds its targets from data: an area, an arc, the nearest actors or a projectile. See [Abilities that reach other actors](/docs/gameplay-ability-toolkit-ecs/build-with-it/delivery.md). For anything else, your systems choose the targets and pass them as the request's `AbilityTarget` or as effect targets. There are no indicators. | | [Input binding](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit/subsystems/input) | Your systems turn input into requests. A caster set to **Input Action** asks for an ability from a project-wide Input System action (single-player only). With Netcode for Entities, `GasAbilityInput` is the replicated input. | | [Cue notifies and the cue manager](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit/subsystems/gameplay-cues) | Cue events as data. See [Cues and presentation](/docs/gameplay-ability-toolkit-ecs/build-with-it/presentation.md). | | [Runtime UI components](https://morningheartgames.gitbook.io/docs/gameplay-ability-toolkit/subsystems/runtime-ui) | Read the actors' buffers. See [Showing state in UI](/docs/gameplay-ability-toolkit-ecs/build-with-it/presentation.md#showing-state-in-ui). | | An `EffectCalculation` that computes in `Execute` | A `BakedEffectCalculation`, which lists its contributions as modifiers. See [What the catalog reports](/docs/gameplay-ability-toolkit-ecs/build-with-it/authoring.md#what-the-catalog-reports). | ## Behavior that differs Each of these is deliberate. Most follow from the runtime working in a fixed order over data instead of calling methods on objects. **Requests are served by the runtime, in order.** On the GameObject runtime, `ActivateByDefinition` activates the ability inside the call. On the ECS runtime a request goes into a queue and the runtime serves it when it runs. A request queued in `GasRequestSystemGroup` is served in the same frame; one queued later is served on the next frame. See [the frame](/docs/gameplay-ability-toolkit-ecs/build-with-it/concepts.md#the-frame). The direct calls in [Writing gameplay code](/docs/gameplay-ability-toolkit-ecs/build-with-it/gameplay-code.md#doing-it-now-instead-of-queueing) act at once, as the GameObject runtime does. **Triggers start abilities on the next frame.** The GameObject runtime starts a triggered ability inside the call that raised the event or added the tag. The ECS runtime finds events and tag changes in one pass at the end of its update, so the ability is served on the next frame. **A tag added and removed within one frame triggers nothing.** The runtime finds tag changes by comparing each actor's tags with the previous frame's, so a tag that comes and goes inside one frame shows no change. The GameObject runtime fires when the tag is added. **Modifier tag filters read the actors' own tags.** On the GameObject runtime, a modifier's source and target tag filters read the tags passed in the application request (`EffectApplicationRequest.SourceTags` and `TargetTags`), which the caller fills in. A request that passes none fails every filter that names a tag. The ECS runtime has no such fields. It reads the source's and the target's tags when the application starts. The two agree when GameObject code passes copies of the actors' tags. **A live attribute capture lags by one recalculation.** A modifier that captures another attribute live sees that attribute's change on the next recalculation, one frame later. The GameObject runtime reads it on demand. **An input hold restarts instead of being cancelled.** The GameObject runtime cancels its hold task when the input is released, and ability code decides whether to start another. A wait cannot be restarted by code, so an `InputHeld` wait starts its count again on release. Holding the input long enough completes it, as on the GameObject runtime. **The clock is the runtime's own.** Durations, periods and cooldowns follow `GasTime`, which follows the world's time. Changing `Time.timeScale` affects both runtimes, because Entities' world time follows it. With Netcode for Entities the clock follows the network tick instead, so the client and the server agree on the time of every tick. See [Time](/docs/gameplay-ability-toolkit-ecs/build-with-it/concepts.md#time). **Levels are baked from 0 to 32.** The catalog samples level curves for levels 0 to 32 when it bakes. A level above 32 uses the value of level 32. The GameObject runtime uses the last entry of the curve, so the two differ only for a curve that has more than 33 entries. ## Rules that are the same on both runtimes These rules match on both runtimes. They are easy to assume wrong. * **Stacks do not multiply modifiers.** A `+5` modifier stays `+5` at three stacks. Stacks change how long an effect lasts and when it ticks, through its stacking policies, not how strong its modifiers are. * **The first Override wins.** When several Override modifiers apply to one attribute, the first one reached counts. * **A divisor that reaches zero gives zero.** The current value is `(base + sum of Add) * (1 + sum of (Multiply - 1)) / (1 + sum of (Divide - 1))`. When the divisor is 0, the attribute becomes 0 instead of the division being skipped. * **An inhibited periodic effect keeps its period.** While inhibition holds, the effect does not execute, but its next period time keeps advancing, so it resumes on schedule. An effect switched off by its ongoing requirements does not advance its period. When the requirements are met again, a period that came due in the meantime executes at once. * **Set-by-caller values are kept with the effect.** A periodic effect uses the values supplied when it was applied on every period. * **An execution's modifiers are combined, then clamped.** Several modifiers of one execution on one attribute are combined first, and the result is clamped once. * **Effects run in the order they were applied** when several expire or tick in the same frame. * **Durations are float seconds.** On a server that runs for days, a float cannot hold every moment exactly. See [Time](/docs/gameplay-ability-toolkit-ecs/build-with-it/concepts.md#time). ## Where to go next * [Authoring](/docs/gameplay-ability-toolkit-ecs/build-with-it/authoring.md): what the catalog bakes, and what it reports when it cannot represent something. * [Writing gameplay code](/docs/gameplay-ability-toolkit-ecs/build-with-it/gameplay-code.md): requests, results and the direct calls. * [How it works](/docs/gameplay-ability-toolkit-ecs/build-with-it/concepts.md): the frame order behind the timing differences above. * [Troubleshooting](/docs/gameplay-ability-toolkit-ecs/reference/troubleshooting.md): when an ECS actor does nothing.