Пилоты уже высказывались на этот счёт. Проблемы со связью никак не мешают уходу на второй круг. Вопрос о целесообразности второго круга считаю приоритетным.
Да, очевидно НАДО ждать выводов МАК. Однако теперь, когда есть видео посадки, есть один вопрос, на который МАК надо ответить. Была ли такая необходимость приземлить самолёт именно в этот заход. Предполагаю ответ МАК будет нет (дисклеймер: это моё ИМХО). Ждём официальных заключений.
Ну а дальше… тут ссылка на инструкции была дана, что делать в случае отрыва при посадке (козлении). И она вполне чётко требует выполнения go around (ухода на второй круг).
Земля пухом…
Ну как бы неверно говорить, что докупка датчика исправила бы ситуацию. Так ведь ошибка ещё и в программной оценке показаний корректности датчика, которая судя по всему работала некорректно (баг или фича: так ли важно?). И насколько я знаю, они добавили 3 датчик, который включается, когда появляются подозрения на показания корректности одного из активных датчиков. И при данной проблеме подключает третий, отключая MCAS. Им конечно виднее, но имхо куда надёжнее, когда работают 3, и сравнивают показания, и отключают тот, который выдаёт погоду. И ещё много можно выдумать алгоритмов, которые также будут правиться на уровне софта.
volatile куда корректнее трактовать как отмену оптимизации, но точно не атомарность. Ну и грубый пример: если для volatile int i сложение ( i+=321; ) ещё может как-то где-то дать (но не гарантировать) атомарность, то умножение ( i *= 321;) уж точно не будет атомарным.
Что касается отмены оптимизации, то очень даже работает в случае, когда компилятор выполняет вычисления в коде, которые без volatile смело отбрасывает.
Так как часто под реактивным подходом имеют ввиду что-то своё, хотелось бы уточнить что именно вы имеете ввиду, и какое решение предлагаете? Я так понимаю просто событие слать вместо добавления компоненты. Если да, то в общем то оно и устраивает.
Два компа на столе: iMac 27" retina 5k, и Dell 24" IPS. Никаких фу-фу-фу на переходах. Это ваши субъективные ощущения. Каждый для себя сам решит, что для него фу-фу-фу.
Мне всё-таки не очень нравится решение с добавлением компоненты для reload и прочего. Почему бы это не делать через события? Просто это провоцирует более активную работу с динамическими компонентами, что имхо медленнее. Может есть опыт и так, и так? Чтобы прокомментировать в сравнении.
Хоть статья и понравилась. То что нужно геймдеву не увидел ни у критикуемого, ни у критикующего. Во-первых наличие методов в компоненте это какой-то отдельный пример ECS паттерна. Корректный вариант всё-таки считаю Entity — id, Component — данные(и только данные), System — алгоритм. В этом плане метод Update в компоненте это уже изначально неверный посыл (как и в куче других примеров по ECS), который перетёк в другой неверный посыл. ECS для игр в корректном варианте реализует тот самый переход AoS -> SoA, который так любят современные процы, который cache-friendly и легко масштабируется по ядрам.
Автор так ругает неверное использование принципов ООП (согласен, ещё отмечу: канонично ООП пиарили в книгах в виде 3 основных принципов: инкапсуляция, наследование, полиморфизм). При этом в качестве базы для разбора, считаю, выбран пример с неверным в корне использованием паттерна ECS, который красивый, но ужасный с точки зрения геймдева. Например: методы в компонентах (ещё и виртуальные!), dynamic_cast где он не нужен и т.д.
То что геймдеву реализация не даёт и близко. Равно и новый вариант, который переделал кривой и неработающий SoA подход на красивый, но также не дающий требуемого, AoS формат. А в правильном ECS это одна из ключевых фишек. Которая обычно не работает без ручного аллокатора.
P.S. Мне так и не ясно, почему был выбран такой подход, ведь в репе Араса куда более корректный пример ECS, чем в том, который модифицирует автор статьи.
Ну а дальше… тут ссылка на инструкции была дана, что делать в случае отрыва при посадке (козлении). И она вполне чётко требует выполнения go around (ухода на второй круг).
Земля пухом…
Что касается отмены оптимизации, то очень даже работает в случае, когда компилятор выполняет вычисления в коде, которые без volatile смело отбрасывает.
Ну и ещё OpenWorld с ECS тоже интересная тема.
Автор так ругает неверное использование принципов ООП (согласен, ещё отмечу: канонично ООП пиарили в книгах в виде 3 основных принципов: инкапсуляция, наследование, полиморфизм). При этом в качестве базы для разбора, считаю, выбран пример с неверным в корне использованием паттерна ECS, который красивый, но ужасный с точки зрения геймдева. Например: методы в компонентах (ещё и виртуальные!), dynamic_cast где он не нужен и т.д.
То что геймдеву реализация не даёт и близко. Равно и новый вариант, который переделал кривой и неработающий SoA подход на красивый, но также не дающий требуемого, AoS формат. А в правильном ECS это одна из ключевых фишек. Которая обычно не работает без ручного аллокатора.
P.S. Мне так и не ясно, почему был выбран такой подход, ведь в репе Араса куда более корректный пример ECS, чем в том, который модифицирует автор статьи.