Сбить машиной конус

[PlutDem]

Нашел причину бага. Из за того, что движение происходит дискретно ТС движется не по окружности, а по многоугольнику. Из за этого его вектор скорости всегда направлен не туда куда нужно. Это особенно хорошо видно при большой угловой скорости, когда у многоугольника мало сторон. При меньшей угловой скорости многоугольник больше похож на круг, но неточность все равно есть. На картинке красная траектория отражает реальное (дискретное, програмное, покадровое) движение ТС, а зеленая как оно движется в реальном мире. Как видно, если считать центр по красному вектору, то он будет смещен. Как решить проблему не знаю, так как не учил в шестом классе геометрию

Сообщение от LifeIsRhythm

Это особенность флешевых вычислений. Если Вы будете крутить вокруг произвольной точки объект,
то рано или поздно произойдет то, что на видео. И чем больше скорость вращения, тем быстрее будет ЭТО.
Решение - постоянно пересчитывать.

Просто вращение нужно хранить в отдельном свойстве типа Number и присваивать его каждый кадр матрице GO, так как матрица GO округляет значения.

[PlutDem]

Проблему с неточностью решил смещением ТС на половину его отрицательной скорости. Таким образом, при расчете центра окружности ТС находится на середине стороны многоугольника. Абсолютная точность все равно не достигается, но при угловых скоростях в 30 градусов и ниже погрешностью можно пренебречь. Большое спасибо товарищу Nooob, по его методу можно найти радиус необходимой окружности пути, а если известна угловая скорость, то можно вычислить и линейную скорость необходимую для описания такой окружности. Если линейная скорость выше максимальной скорости ТС, то можно без опаски поворачивать на максимальной скорости, так как ТС в любом случае успеет повернутся на цель и не выйдет на орбиту, а если она меньше, то просто ограничиваем скорость ТС до ее значения.
К сожалению, когда я ввел в физическую модель инерцию и ускорение, стало понятно, алгоритм придется дорабатывать и он может разрастись до неприемлемого уровня. А если еще мы захотим учитывать, скажем, силу с который дует ветер или будем применять к ТС вектор силы притяжения гигантского магнита мимо которого оно проезжает... Все эти силы придется подставлять в формулу в результате чего она не только будет гибкой как доска он и возможно недостаточно производительной.
В поисках более простого решения обратил внимание на Steering Behaviours, но к сожалению во всех примерах в качестве тела используется обычная точка. Ее ориентация в пространстве совпадает с направлением скорости. Это означает, что скажем, если придать танку, стоящему на месте скорость, то он моментально развернется в этом направлении, хотя мы знаем, что он не может поворачивать быстрее своей максимальной угловой скрости.

[Nooob]

на счет Steering Behaviours
вот тут есть занятное чтиво.

Я думаю можно комбинировать то что ты сделал и Steering Behaviours, если сделать что сам ТС - это точка которая двигается по стирингу, а твоя точка по окружности - это точка к которой он пытается двигаться. По поводу угловой скорости танка, то вполне можно ограничивать скорость поворота. если поворот за раз больше чем максимальное значение то обрезай его до этого значения и скорость тоже скейли на это отношение. тогда он будет медленно поворачивать сохраняя свою модель поведения.
....
Для данной реализации подойдёт Leader Following. Leader - это точка которая к конусу двигается, получится такая своеобразная аппроксимация, но с учетом всех сил и потенциалов. Но не советую использовать тот код который там (только разве что в качестве ознакомления), так как очень много создается временных объектов Vector3D (зачем Vector3D?! можно же Point использовать, z всё равно нигде не юзается), для языков где есть структуры это было бы хорошо, но не для флеша, лучше только переменными x и y, которые на стеке хранятся, пользоваться, а методы add, subtract, interpolate, normalize самому реализовать.