Bevy-rendszerek ütemezése
Rendezi, milyen sorrendben olvassák és módosítják a rendszerek az entitások adatait. Kimondja a tényleges függőségeket, hogy a létrehozás, mozgás és harc más rendszerek átrendezésekor is helyes maradjon.
bevy-ecs-scheduling
Nézd meg, miben segítMikor hasznos?
Akkor használd, ha Bevy-rendszereid ugyanabban a frissítésben más rendszerek által létrehozott adatra várnak.
Miben segít neked?
- A rendszerek szétválasztása előtt feltérképezi a komponensek gazdáit és ütköző hozzáféréseit.
- Kifejezett sorrendet állít fel, beleértve a halasztott parancsok eredményének láthatóságát.
- Szűk lekérdezésekkel és stabil azonosítókkal különíti el a globális beállítást az entitásállapottól.
Például ezt kérheted
Az arénában halasztott paranccsal hozz létre ellenfelet, amelyet a célzás a kijelölt frissítésben már megtalál. Térképezd fel a létrehozás, mozgás és sebzés függőségeit, majd rendezz át egy független animációs rendszert. A harc ne a regisztráció véletlen sorrendjére támaszkodjon.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
Bevy — ecs scheduling
Use when designing Bevy components, resources, queries, plugins or system ordering.
Version and project gate
Inspect Cargo.toml, Cargo.lock, Rust toolchain, exact Bevy release, plugin compatibility, feature selection, schedules, state definitions, asset roots and target backend. Read the matching migration guide before using newer examples. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Model data ownership and access conflicts before splitting systems. Express required ordering explicitly, including deferred command visibility. Keep global configuration distinct from per-entity state and inspect the pinned release’s resource semantics. Use narrow queries and stable domain IDs.
Deliver
A component/system dependency map and a focused plugin that expresses its ordering requirements. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
Registration order is not a substitute for an explicit dependency; resource/component behavior changes between releases.
Acceptance scenario
Spawn through deferred commands, consume the result in a dependent system and verify behavior after reordering unrelated systems. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Talon. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Csomagban lévő fájlok 1
SKILL.md