Если у вас есть какие-то команды в командном буфере барьера, выданного из 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;",
  ],
 },

Когда многословие — враг, и вы не можете использовать наследование и т. д., последнее, на что вы можете положиться, — это, вероятно, фрагменты кода. Проблема решена…

Бонус… Я снова столкнулся с этой ошибкой и сделал снимок экрана в качестве доказательства того, что барьеры могут работать ДО предполагаемой системы, которая «владеет» ими. На самом деле, никто ими не владеет, а только пользуется ими. Это ваша вина, что барьер активируется и не находит никаких команд, потому что он пытается запустить как можно быстрее (в отношении депов)