ну вот что-то в проверке нажатий, наверное и не так. Ибо оно от части работает как нужно, но только если использовать определенные клавиши. То есть, зажать W, а потом S - он поедет вниз.
А если зажать D, а потом W, то он будет так же ехать в направлении D

блин, ребят, вы играли в старые игры?
помните как там было реализовано управление клавишами, а не в сторону направления мыши.
Вы зажимаете клавишу W персонаж бежит вперед, не отжимая её нажимаете D, персонаж поворачивает, вы её отпускаете - он бежит дальше по прямой.
Мне это нужно.
Реализовать логику действие если одна из клавиш зажата ибо по отдельности всё работает,как надо.

Логика конечно странная, если цель избавиться от езды по диогонали, не проще вешать флаг нажатия первой кнопки и недопускать нажатия других пока текущую не отжмешь

Друзья, а кто может подсказать по event/action?

Вопрос следующий. У меня есть 3 собственных класса:
Vertex
Polygon
Object

Полигон состоит из 3х экземпляров вершины. Объект состоит из нескольких полигонов.

Я делаю action OnChanged для вершин и полигонов, соответственно. Полигон подписан на событие изменения его вершин, а объект на событие изменения его полигонов.

Далее я могу работать с объектом и в какой-то момент решу разделить один полигон на 3 более мелких. Следовательно я из списка полигонов объекта удалю один полигон и добавлю три новых.

Вопрос:

В обычной ситуации сборщик мусора убьет все экземпляры не используемых классов. А что будет в данном случае? Ведь полигон (который мы решили разбить и удалить из списка объекта) с одной стороны никто не использует, с другой он подписан на событие по изменению вершин, которые продолжают использоваться другими полигонами. Будет ли этот полигон вечно в памяти крутиться или удалится?

Как такой кейс обрабатывать?

Логика конечно странная, если цель избавиться от езды по диогонали, не проще вешать флаг нажатия первой кнопки и недопускать нажатия других пока текущую не отжмешь

Да, будет крутиться в памяти, если не будет отписан.
Тут, в принципе, что-то не так. Лучше держать отдельный менеджер, который занимается подписками.
Возможно, на первый взгляд, это нелогично: ну, типа, как же так: "вот он объект, почему у него просто не может быть события, относящегося к нему же?!"
А отдельный менеджер всё же лучше потому, что отделяет ответственность за подписку от самого объекта, или даже нескольких типов объектов. Ну и памятью так легче управлять. Зачищаешь коллекцию подписок по определённому ключу – и готово, память свободна от действительно ненужных объектов.