Если у вас есть какие-то команды в командном буфере барьера, выданного из JobComponentSystem, вы могли забыть поместить deps в барьер, предполагая, что он наследует зависимость группировки/до-после от системы, которая использует командный буфер.
На этом рисунке я хотел, чтобы барьер работал после этого родительского класса. Но присмотритесь, нет никакой гарантии, что барьер сработает позже. Вы можете получить странное поведение, если барьер решит запуститься раньше, в зависимости от того, как Unity решит для вас «лучший» порядок. Правильно было бы поставить [UpdateAfter(typeof(TheClassThatUsesTheBarrier))]
на нем.
Если вы сделаете это и *кажется*, что это все равно работает, это может быть следующий кадр, который воспроизводится командой, потому что предыдущий кадр барьер запускает раньше, но не может найти никаких команд. В любом случае результат может быть правильным, но позже он может привести к тонким ошибкам, когда что-то таинственным образом запаздывает на 1 кадр или что-то не работает, поскольку это строго должно быть в том же кадре, что и что-то еще.
Барьерная «система» — это отдельная система, как и любая другая, которую вы должны написать с нуля, но ее цель — просто выполнять некоторые команды, связанные с менеджером объектов, когда другая работа не подходит для выполнения служебных обязанностей.
Я поместил барьер внутри класса использования только для того, чтобы я мог назвать каждый барьер «Барьером» без конфликта имен и сделать для него автоматический фрагмент, но это не означает, что система вообще «владеет» этим барьером. Думайте, что это отдельный системный класс.
И на самом деле нехорошо лениться при именовании барьера, так как оно будет отображаться в отладчике сущностей так же:
И вы видите трюк класса abstract
, о котором я упоминал ранее, в каком доме BarrierSystem
внутри? Теперь мы не можем разместить внутри них порядок обновления, потому что мы не можем поместить атрибуты в родительский класс из подкласса. Ой…
Итак, каково лучшее решение, если мы не можем заранее сделать барьер? Сделайте такой фрагмент (VSCode):
"Barrier System": { "prefix": "barr", "body": [ "public class Barrier$0 : BarrierSystem { }", "[Inject] Barrier barrier;", ], },
Теперь объявление барьера не будет таким болезненным! Ага!
Пока мы на этом, как насчет этого:
"Get Barrier into a job": { "prefix": "combar", "body": [ "command = barrier.CreateCommandBuffer(),", ], }, "Entity Command Buffer": { "prefix": "enticom", "body": [ "public EntityCommandBuffer command;", ], },
Когда многословие — враг, и вы не можете использовать наследование и т. д., последнее, на что вы можете положиться, — это, вероятно, фрагменты кода. Проблема решена…
Бонус… Я снова столкнулся с этой ошибкой и сделал снимок экрана в качестве доказательства того, что барьеры могут работать ДО предполагаемой системы, которая «владеет» ими. На самом деле, никто ими не владеет, а только пользуется ими. Это ваша вина, что барьер активируется и не находит никаких команд, потому что он пытается запустить как можно быстрее (в отношении депов)