You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/world/ai-goals.md
+17-17Lines changed: 17 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: AI & Goals
3
3
description: Mob AI behavior system in LCEMP.
4
4
---
5
5
6
-
LCEMP uses a priority-based goal system for mob AI. Each mob owns two `GoalSelector` instances -- one for general behaviors and one for targeting -- and each selector manages a list of `Goal` objects that compete for execution based on priority and control flag compatibility.
6
+
LCEMP uses a priority-based goal system for mob AI. Each mob owns two `GoalSelector` instances, one for general behaviors and one for targeting. Each selector manages a list of `Goal` objects that compete for execution based on priority and control flag compatibility.
7
7
8
8
## Goal (base class)
9
9
@@ -17,13 +17,13 @@ Every AI behavior inherits from `Goal` and implements its lifecycle methods:
17
17
|`start()`| No-op | Called once when the goal begins executing |
18
18
|`stop()`| No-op | Called once when the goal stops executing |
19
19
|`tick()`| No-op | Called every tick while the goal is running |
20
-
|`setRequiredControlFlags(flags)`|--| Sets the bitmask of control channels this goal uses |
20
+
|`setRequiredControlFlags(flags)`|(none)| Sets the bitmask of control channels this goal uses |
21
21
|`getRequiredControlFlags()`| Returns `0`| Returns the control flag bitmask |
22
22
|`setLevel(level)`| No-op | 4J addition: updates level pointer when loading from schematics |
23
23
24
24
### Control flags
25
25
26
-
Goals declare which "control channels" they require via a bitmask passed to `setRequiredControlFlags()`. Two goals can run simultaneously only if their control flags do not overlap (bitwise AND is zero). This prevents, for example, two movement goals from conflicting.
26
+
Goals declare which "control channels" they need through a bitmask passed to `setRequiredControlFlags()`. Two goals can run at the same time only if their control flags don't overlap (bitwise AND is zero). This prevents things like two movement goals from conflicting with each other.
27
27
28
28
The `TargetGoal` base class defines `TargetFlag = 1` as a standard flag for targeting behaviors.
29
29
@@ -34,21 +34,21 @@ The scheduler that manages and ticks a set of goals.
34
34
### Internal structure
35
35
36
36
Goals are wrapped in `InternalGoal` objects that store:
-`canDeletePointer`: ownership flag for memory management (4J addition)
40
40
41
41
Two lists are maintained:
42
-
-`goals` -- all registered goals
43
-
-`usingGoals` -- goals currently executing
42
+
-`goals`: all registered goals
43
+
-`usingGoals`: goals currently executing
44
44
45
45
### Tick behavior
46
46
47
-
Every `newGoalRate` ticks (default: 3), the selector performs a full evaluation cycle:
47
+
Every `newGoalRate` ticks (default: 3), the selector runs a full evaluation cycle:
48
48
49
49
1.**For each registered goal:**
50
-
- If currently running and either `canUseInSystem()` fails or `canContinueToUse()` returns false, call `stop()` and remove from `usingGoals`
51
-
- If not running and both `canUseInSystem()` and `canUse()` pass, add to start list and `usingGoals`
50
+
- If it's currently running and either `canUseInSystem()` fails or `canContinueToUse()` returns false, call `stop()` and remove from `usingGoals`
51
+
- If it's not running and both `canUseInSystem()` and `canUse()` pass, add to start list and `usingGoals`
52
52
2.**Call `start()` on all newly added goals**
53
53
3.**Call `tick()` on all running goals**
54
54
@@ -65,18 +65,18 @@ On non-evaluation ticks, only `canContinueToUse()` is checked for running goals,
65
65
66
66
### Configuration
67
67
68
-
-`addGoal(priority, goal, canDeletePointer)` -- registers a goal at the given priority. The `canDeletePointer` flag (default `true`) controls whether the selector owns the goal memory.
69
-
-`setNewGoalRate(rate)` -- changes how often full evaluation occurs (default every 3 ticks)
70
-
-`setLevel(level)` -- propagates a level pointer change to all goals (4J addition for schematic loading)
68
+
-`addGoal(priority, goal, canDeletePointer)`: registers a goal at the given priority. The `canDeletePointer` flag (default `true`) controls whether the selector owns the goal memory.
69
+
-`setNewGoalRate(rate)`: changes how often full evaluation happens (default every 3 ticks)
70
+
-`setLevel(level)`: sends a level pointer change to all goals (4J addition for schematic loading)
71
71
72
72
## TargetGoal (base class for targeting)
73
73
74
-
Abstract base for goals that select an attack target. Provides shared logic for target validation.
74
+
Abstract base for goals that pick an attack target. Provides shared logic for target validation.
Copy file name to clipboardExpand all lines: src/content/docs/world/gamerules.md
+14-14Lines changed: 14 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,16 +3,16 @@ title: Game Rules
3
3
description: Configurable game rules in LCEMP.
4
4
---
5
5
6
-
LCEMP uses a **Console Game Rules** system that is fundamentally different from vanilla Minecraft's simple key-value game rules. Instead of boolean/integer rules like `keepInventory` or `doDaylightCycle`, LCEMP's game rules are a data-driven, hierarchical system primarily used for custom game modes (like Battle, Tumble, Glide) and DLC mashup packs.
6
+
LCEMP uses a **Console Game Rules** system that works completely differently from vanilla Minecraft's simple key-value game rules. Instead of boolean/integer rules like `keepInventory` or `doDaylightCycle`, LCEMP's game rules are a data-driven, hierarchical system mainly used for custom game modes (like Battle, Tumble, Glide) and DLC mashup packs.
7
7
8
8
## Architecture overview
9
9
10
10
The game rule system has four main layers:
11
11
12
-
1.**GameRuleManager** -- loads, saves, and manages rule definitions from DLC packs
13
-
2.**GameRuleDefinition** -- the static definition/template of a rule (what to do)
14
-
3.**GameRule** -- the runtime state of a rule for a specific player or server
15
-
4.**GameRulesInstance** -- extends `GameRule` as the top-level container for a player's or server's complete rule state
12
+
1.**GameRuleManager**: loads, saves, and manages rule definitions from DLC packs
13
+
2.**GameRuleDefinition**: the static definition/template of a rule (what to do)
14
+
3.**GameRule**: the runtime state of a rule for a specific player or server
15
+
4.**GameRulesInstance**: extends `GameRule` as the top-level container for a player's or server's complete rule state
16
16
17
17
## ConsoleGameRules constants
18
18
@@ -65,7 +65,7 @@ Rules are configured through attributes loaded from XML/binary data:
65
65
66
66
## GameRuleDefinition
67
67
68
-
The base class for all rule templates. Defines the static structure of a rule.
68
+
The base class for all rule templates. This defines the static structure of a rule.
69
69
70
70
**Key methods:**
71
71
@@ -87,19 +87,19 @@ The base class for all rule templates. Defines the static structure of a rule.
87
87
88
88
#### CompoundGameRuleDefinition
89
89
90
-
Base class for rules that contain child rules. Manages a `m_children` vector and delegates hooks to all children.
90
+
Base class for rules that contain child rules. Manages a `m_children` vector and passes hooks down to all children.
91
91
92
92
#### CompleteAllRuleDefinition
93
93
94
-
Extends `CompoundGameRuleDefinition`. Completes only when **all** child rules are complete. Broadcasts progress updates via`UpdateGameRuleProgressPacket`.
94
+
Extends `CompoundGameRuleDefinition`. This one only completes when **all** child rules are complete. It broadcasts progress updates through`UpdateGameRuleProgressPacket`.
95
95
96
96
#### CollectItemRuleDefinition
97
97
98
-
Tracks collection of a specific item. Configured with `m_itemId`, `m_auxValue`, and `m_quantity`. Increments progress each time the matching item is collected.
98
+
Tracks collection of a specific item. Configured with `m_itemId`, `m_auxValue`, and `m_quantity`. Each time the matching item is collected, the progress goes up.
99
99
100
100
#### UseTileRuleDefinition
101
101
102
-
Triggers when a player interacts with a specific tile (block). Can optionally require specific coordinates via`m_useCoords`.
102
+
Triggers when a player interacts with a specific tile (block). Can optionally require specific coordinates through`m_useCoords`.
103
103
104
104
#### UpdatePlayerRuleDefinition
105
105
@@ -117,12 +117,12 @@ Extends `CompoundGameRuleDefinition` as the root container for a level's rules.
117
117
118
118
Each `GameRule` instance tracks the runtime state of a definition for a specific connection (player).
119
119
120
-
**State storage:** Parameters are stored in `m_parameters`, an `unordered_map<wstring, ValueType>` where `ValueType` is a union of:
120
+
**State storage:** Parameters live in `m_parameters`, an `unordered_map<wstring, ValueType>` where `ValueType` is a union of:
-`GameRule*` (nested rule pointer, flagged with `isPointer = true`)
124
124
125
-
**Serialization:**`write()` and `read()` serialize all parameters to/from a `DataOutputStream`/`DataInputStream`. Pointer values are recursively serialized; primitive values are stored as `__int64`.
125
+
**Serialization:**`write()` and `read()` serialize all parameters to/from a `DataOutputStream`/`DataInputStream`. Pointer values are serialized recursively, and primitive values are stored as `__int64`.
126
126
127
127
## GameRulesInstance
128
128
@@ -133,7 +133,7 @@ Extends `GameRule` with an instance type:
0 commit comments