##### Пришел к тому, что: - системы, которых пытаются оставить, не будут в свою очередь пытаться останавливать другие системы (в рамках сущности). - Каждая система только лишь сама себя останавливает (каждая система следит, не является ли входное поле defaulted). Если системе1 нужно остановить группуА-систем, чтобы воспользоваться частью группыА-систем, то он самостоятельно очищает <u>входные поля</u> первой части группыА-систем, а второй части присваивает новые значения. Тем самым часть группыА-систем остановятся, потому что словят defaulted. А часть продолжит работать с новыми данными, которые вскормила система1. Никакая система не должна чистить поля Order-компонента, принадлежащий другой системе, «по цепочке». То есть чистить других, потому что тебя почистили. Потому что возможна ситуация, что система1 почистит систему2, которая использует систему3, чтобы сразу же воспользоваться системой3. А так как система2 чистит orderы систем, которыми пользовался, и также есть отставании в событии на 1 кадр, то получится чистка данных, которые принадлежат системы1, руками системой2. Допускается чистка полей Системой, только в рамках своего Order-компонента. Или других компонентов, которые работают только с данной системой. ##### Зачем ждать проверять IsDefaulted, если можно просто не выполнять систему, если IsValueDefault? Потому что будет сохраняться состояние Order-компонента (контекст), чтобы этого избежать, нужно ждать событие, а после чистить поля в order. ##### Почему нельзя просто ориентироваться на EndPosition? Если default, значит order выполнен. (Имеется ввиду, зачем внедрять OrderStatus с состояниями None, Executing, Completed.) Сбросить поле могут со стороны. Например, игрок может отменить приказ и тем самым будет сброс поля. ### Дальше идет черновик (рассуждения) Я рассматривал кейс, чтобы моментально оповещать о событиях, а не в начале фрейма, однако я не нашел качественного решения. Все решения имеют ненадежность, нет гарантий, что событие проживет ровно один кадр без погрешностей. ##### Почему нельзя сбрасывать работу системы для определенной сущности, просто сделав default для входного поля (например, endPosition)? Потому что во-первых тогда не будет сбрасываться состояние order-компонента: Речь про OrderStatus и контект-поля. Это чревато тем, что когда для сущности снова что-то нужно будет сделать, то система продолжит с того места, где остановилась, потому что контекст работы не был сброшен. Также, системы могут использовать другие системы, которые вообще не в курсе про endPosition. Они не следят за изменениями endPosition. Например VehicleRotationSystem имеет уже другие данные на вход. ##### Можно создать для каждой системы метод ResetStateForEntity(Entity entity) ##### Метод будет вызывать системами, которые используют другие системы. Решение не подходит, потому что системы могут использоваться в разной комбинации. Набор компонентов для транспорта FindPathOrderC VehicleMotionOrderC Набор компонентов для пехоты FindPathOrderC HumanoidMotionOrderC В обоих случаях EndPosition передается в FindPathOrderC, а FindPathSystem генерирует Path. Path используется для движения системами VehicleMotionSystem и HumanoidMotionSystem. Также это нарушает принцип ECS, в котором говорится, что системы не должны вызывать логику друг у друга. ##### Можно сделать так, чтобы системы следили за изменением входного поля. Если входное default, то выходное тоже ставится как default. Проблема в том, что если цепочка из систем состоит из 4 систем, то крайняя система сделать свое выходное поле как default только через 4 кадра. И если разработчик захочет сбросить эти 4 системы, чтобы воспользоваться крайней системой, то ему придется ждать 4 кадра, перед тем как начать пользоваться. Иначе будет ситуация, что разраб начнет использовать крайнюю систему, но через 4 кадра она перестанет работать. <u>FindPathSystem</u> EndPosition -> Path VehicleMotionSystem Path -> EndRotation Если сбросить EndPosition и в этом же кадре присвоить EndRotation, то через несколько кадров EndRotation сбросится. Еще одна проблема VehicleRotation вообще не знает о существовании других систем и компонентов. Он просто принимает поле и имеет свой order. Еще одна проблема Если входное поле, которое будут сбрасывать, является EntityId и через него обращаются для к order-компоненту, то это создает ситуацию, в которой невозможно остановить следующую систему.  Для решения данной проблемы можно в MyEntityId хранить предыдущее значение EntityId. Еще одна проблема Когда будет много систем и будет писаться AI-бот, то он не сможет управлять моментально другими системами, если какие-то из них нужно будет отключить, а потом какие-то из них включить. Придется придумывать постели в виде ожидания остановки. ### ==== Каждая система может быть зависима от другой системы. Либо первая система ждет изменение данных, которую изменяет вторая система, либо наоборот.

 То есть может быть схема: Первая система меняет поле1. Вторая система подхватывает изменение поля1 и меняет поле2 Третья система берет поле2 и изменяет поле3 Четвертая система берет поле3 и изменяет поле4 VictimId -> EndPosition -> Path -> EndRotation Все идеи внизу глупые и неподходящие. Идея! 1. Можно было бы сделать метод Finish в системе, который возвращает entity, который сворачивает лавку. Это позволит поставить рамки, чтобы легче было ориентироваться в коде. 1. Написать систему, которая будет в зависимости от ситуации, отменять атаку и ехать по заданному маршруту. 1. Отделить «технический» endPosition и endPosition, который назначает игрок.