Fixed inconsistencies in the docs

Author: Gesee-y

Manifest.toml

@@ -15,6 +15,7 @@ Outdoors = "d3598698-a7e3-42d2-87cb-a7a1f294c746"
 Reexport = "189a3867-3050-52da-a836-e630ba90ab69"
 
 [compat]
+CRHorizons = "0.1"
 EventNotifiers = "1.0"
 GDMathLib = "1.3"
 Graphs = "1.12,1.13"

Project.toml

@@ -111,10 +111,10 @@ Cruise.shutdown!(node::CRPluginNode{Sys2}) = setstatus(node, PLUGIN_OFF)
 
 ## Merging and Running
 
-Merge the plugin into Cruise at the correct phase:
+Merge the plugin into Cruise:
 
 ```julia
-merge_plugin!(app, plugin, :preupdate)
+merge_plugin!(app, plugin)
 ```
 
 > Even after merging, you can still manage the plugin from the CRPlugin instance you created.
@@ -179,60 +179,6 @@ node.deps[TYPE]  # Returns a WeakRef to the capability of the dependency of type
 
 ---
 
-### Plugin Serialization
-
-Persistent plugin must overload the serialization functions `encode_state` that outputs a dictionary with exactly 3 top-level sections with the last 2 following the enumeration:
-
-```julia
-@enum PluginSerializationInfo begin
-    PLUGIN_STATE_INFO
-    PLUGIN_DEBUG_INFO
-end
-```
-
-1. `PLUGIN_STATE_INFO` : the core runtime state of the plugin. It should provides enough informations for you to reconstruct the data of you `CRPluginNode`.
-
-2. `PLUGIN_DEBUG_INFO`: optional info for debugging, monitoring, or health-checks (e.g., counters, last error, timestamps). Anything that could help debug abnormal behaviors in your plugin.
-
-#### Restoring your plugin's state
-
-You should overload the `restore_state` methods which will have the following signature:
-
-```julia
-restore_state(::Val{:YourPluginName}, data::Dict{String, Any})
-```
-
-This function should returns an instance of the object contained in your plugin. You will have to use the informations you previously gave to serialize to create your object
-
-#### Serialization Rules
-
-- Non-serializable fields (callbacks, Tasks, WeakRefs) must be skipped.
-
-- `restore_state` must be able to restore both state and data fully.
-
-- debug can be ignored during restore; it is purely informational.
-
-
-#### Example
-
-```julia
-Dict(
-    "Name" => "TimerPlugin"
-    PLUGIN_STATE_INFO => Dict("current_time" => 12.5, "active" => true),
-    PLUGIN_DEBUG_INFO => Dict("last_update" => DateTime("2025-11-08T10:00:00"))
-)
-```
-
-#### Why this ?
-
-Because it offers:
-
-- Clear separation between runtime, persistent, and debug info
-
-- Easier logging and debugging
-
-- Uniform format for all plugins, making save/load logic generic
-
 ### Registering plugin
 
 In order for your plugin to be registered, it need to meet the following guidelines:

docs/Plugins/index.md

@@ -62,7 +62,7 @@ using Cruise, PausePlugin
 
 app = CruiseApp()
 
-merge_plugin!(app, PAUSEPLUGIN, :preupdate)
+merge_plugin!(app, PAUSEPLUGIN)
 ```
 
 Now we can simply use the plugin in the game loop.

docs/Plugins/pauser.md

@@ -111,6 +111,7 @@ Now we can happily use our plugin:
 ```julia
 i = 0
 @gameloop maxfps=60 begin
+    LOOP_VAR = LOOP_VAR_REF[]
     if LOOP_VAR.frame_idx % 50 == 0
         timer = addtimer!(rand())
 

docs/Plugins/timer.md

@@ -1,36 +1,105 @@
-# Cruise v0.3.0 documentation: Game logics
+# Cruise v0.3.0 documentation: Game Logics
 
-A game logic is a chunk of code that execute a specific task in your code.
-In regular game engines they are often called **scripts**. These scripts are then tied to an object. when the object is active, his script execute, when it's not, the script isn't executed.
+A **game logic** is a self-contained block of code that performs a specific task in your game.
+In most engines these are called *scripts*, and they’re attached to game objects: if the object is active, its script runs; if not, it doesn’t.
 
-With Cruise, it's a little bit different. Scripts are called **game logics** and are independent of objects. They can be activated/desactivated at will. Their purpose is to accomplish a specific task in your game.
+Cruise doesn’t follow that model.
+Here, a game logic is **not tied to any object**.
+It can be enabled or disabled at any time, connected to other logics, and integrated directly into the main execution graph.
+Its only responsibility is to perform a clearly defined operation inside your game.
 
-One can create a new game logic like this
+---
+
+## Declaring a Game Logic
 
 ```julia
-app = CruiseApp() # Make sure to have called this at least once
+app = CruiseApp()  # Must be called at least once
 
 logic_id = @gamelogic logic_name begin
-    # My code
+    # Logic code
 end
 ```
 
-So here we made a new game logic that we named `logic_name`. The `@gamelogic` macro will return the id of our new logic.
-Why an id ?
-Because a game logic is in fact a system in the main plugin graph. This means that all your logic benefits from all the features a regular plugin node have (capabilities, dependencies, enabling/disabling, etc). Your logic is automatically added to the main plugin, but you can optionnaly pas the keyword argument `plugin=myplugin` so the logic is added to your custom plugin instead.
+`@gamelogic` creates the logic, registers it inside the plugin graph, and returns its **ID**.
+Why an ID?
+Because a game logic is essentially a **system node in the main plugin graph**, with all the same features as any plugin node:
+
+* capabilities
+* dependencies
+* enable/disable
+* ordered execution
 
-Each game logic is an intace of the object `GameCode{Name}` where `Name` is the name of your logic as a `Symbol`.
-So when getting it from adependency for example, you will just do
+By default, the logic is added to the main plugin, but you can place it elsewhere:
 
 ```julia
-pluginnode.deps[GameCode{:name}]
+@gamelogic logic_name plugin=myplugin begin
+    ...
+end
+```
+
+---
+
+## Identity and Access
+
+Each logic is an instance of:
+
+```
+GameCode{Name}
 ```
 
-In your logics, the internal representation of your logic (the node of the graph) is called `self`. for example
+where `Name` is your logic’s name as a `Symbol`.
+
+Example: accessing it from a dependency list:
+
+```julia
+pluginnode.deps[GameCode{:logic_name}]
+```
+
+---
+
+## The `self` Variable
+
+Inside every game logic, Cruise injects a variable called `self`.
+This is the actual node in the plugin graph that represents your system.
 
 ```julia
 @gamelogic logic begin
-    println(self) # self are is a variable specific to the logic that is the node containing the logic
-    # You can use it as with any other node
+    println(self)  # The node itself
+    # You can use it exactly like any other graph node
 end
 ```
+
+`self` gives you:
+
+* access to your capability
+* access to your dependencies
+* node state information
+* full interaction with the graph
+
+---
+
+## Keyword Arguments
+
+Game logics accept several optional keywords:
+
+### `mainthread=false`
+
+Forces the system to always run on the main thread.
+
+### `plugin=<plugin>`
+
+Places the logic inside a specific plugin instead of the main one.
+
+### `capability=<obj>`
+
+Associates a capability to the logic.
+Other systems depending on this logic can query that capability.
+
+Example:
+
+```julia
+@gamelogic movement capability=MovementCap() begin
+    # ...
+end
+```
+