public sealed class BehaviorUpdateSystemCalls Update on every enabled, started behaviour.
No guide page documents this yet — the page shows what the code says about itself.
As a system
- Phase
- Update
Remarks
Declares no access, and so conflicts with every other system in its phase. That is correct rather than lazy: a behaviour is arbitrary user code and may touch anything, and the scheduler's only honest reading of that is "assume everything". A game that wants its behaviour work to overlap with a system writes an ISystem instead, which is the trade doc 04 states in as many words.
⚠ Which is why it hands the scheduler over and still returns dependency. A BehaviorJobAttribute batch is dispatched and completed inside RunUpdate, at a sync point where this system conflicts with everything and nothing else is running. That parallelises the indices of one bucket, which is what doc 04 § Making it fast item 3 asks for; returning a handle instead would be the other question — a behaviour's work overlapping a system's — and that needs an access declaration behaviours do not have.
Methods (2)
public BehaviorUpdateSystem(BehaviorStore store)Calls Update on every enabled, started behaviour.
public override JobHandle Update(in SystemContext context, JobHandle dependency)Runs the system.
Used by (1)
- EngineLoopVixen.Engine