> For the complete documentation index, see [llms.txt](https://rigonix3d.gitbook.io/rigonix3d-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rigonix3d.gitbook.io/rigonix3d-docs/documentation/the-modules/editor.md).

# Architecture: Core vs Controller

Why there's a Core and a Controller, and how modules fit together.

Rigonix splits a character into two MonoBehaviours: the **Core** (the body) and the **Controller** (the driver). Understanding this split explains almost every design decision in the asset, so it's worth five minutes up front.

### The one-sentence version

> The **Core** is *what the character is*. The **Controller** is *who's driving it*.

### RigonixCharacterCore — the body

`RigonixCharacterCore` owns everything a character *is*, regardless of who controls it: the input intent surface, locomotion, airborne physics, the animator bridge, audio, ragdoll, and foot IK. These are the **body modules**. A Core with no driver still initializes and works — it just stands there waiting for someone to fill in its intent.

### RigonixController — the driver

`RigonixController` is the **player** driver. It owns the things only a *player* needs: the camera, HUD, cursor lock, and the player-facing modules — health, dodge, inventory, interaction, emotes, teleport, footsteps, and head/torso IK. On Awake it registers itself with the Core via `core.SetDriver(this)` and kicks off `core.InitializeBody()`.

```csharp
void Awake()
{
    core = GetComponent<RigonixCharacterCore>();
    if (core == null) core = gameObject.AddComponent<RigonixCharacterCore>();
    core.SetDriver(this);      // "I'm driving this body"
    core.InitializeBody();     // wake the body modules
    // ... initialize driver modules
}
```

### Why bother splitting them?

Because the same body can be driven by different things. A player drives it from a keyboard and mouse. An AI agent drives the *exact same* body modules from its brain — no camera, no HUD, no cursor. Because locomotion, airborne, animator, and ragdoll live on the Core, an AI gets all of them for free without inheriting a single player-only dependency.

```mermaid
flowchart TD
    Player[RigonixController<br/>player driver] -->|SetDriver| Core
    AI[RigonixAIController<br/>AI driver] -->|SetDriver| Core
    Core[RigonixCharacterCore<br/>the body] --> Loco[Locomotion]
    Core --> Air[Airborne]
    Core --> Anim[Animator]
    Core --> Rag[Ragdoll]
    Core --> IK[Foot IK]
    Core --> Audio[Audio]
    Core --> Input[Input intent]
```

This is also the **add-on boundary**. Melee, AI, and shooting add-ons attach to the Core, never to the Controller. That means an add-on never forces a change on the player controller, and your buyer prefabs keep working across updates.

### How a module reads its world

Every module derives from `RigonixModule` and gets initialized with the Core. Inside, two references matter:

* **`core`** — always present. Body modules read `core.locomotion`, `core.input`, `core.airborne`, and so on.
* **`controller`** — the player driver, resolved from `core.driver`. It's `null` on a pure-AI character, which is correct: the player-only modules that use it don't run there anyway.

```csharp
public virtual void Initialize(RigonixCharacterCore owner)
{
    this.core = owner;
    this.controller = owner.driver as RigonixController; // null on AI
    this.transform = owner.transform;
    this.rb = owner.GetComponent<Rigidbody>();
    this.anim = owner.GetComponent<Animator>();
    this.col = owner.GetComponent<Collider>();
}
```

{% hint style="info" %}
**The golden input rule:** every module reads input *only* from `controller.input.*` (or `core.input.*`), the fields the Input module fills at the top of each frame. A module that calls `Input.GetKeyDown` directly is a bug — it breaks gamepad, touch, and AI control all at once.
{% endhint %}

### The module lifecycle

Modules mirror Unity's own lifecycle, called in a deliberate order. **Input always ticks first**, so every other module sees fresh intent:

```mermaid
flowchart LR
    A[Initialize] --> B[OnAwake] --> C[OnStart] --> D[OnUpdate] --> E[OnFixedUpdate] --> F[OnLateUpdate] --> G[OnAnimatorIK]
```

With the split understood, the rest of the module pages are just "what does this one do." Start wherever you like — Input and Locomotion are the natural first reads.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://rigonix3d.gitbook.io/rigonix3d-docs/documentation/the-modules/editor.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.