можно ли одновременно использовать программную и не программную анимацию?

[mariaiva]

я изменяю некоторые свойства мувика программно, затем мне нужно изменит уже другие свойства этого же мувика не программно (например передвинуть его), а не получается..... почему?

[FreeLander]

программные изменения - изменения, посредством кода ActionScript, они происходят, когда твой уже откомпилированный мувик запущен.

А не программные изменения - изменения сделанные в гафическом редакторе Flash до компиляции мувика.

Т.о. фраза о непрограммных изменениях, после программных изменений звучит странно (извините за каламбур:))

[Ромастый]

Тут где-то поднимался вопрос о филосовском смысле кадров... :D
Я так понимаю, что при компиляции вся анимация, сделанная вручную плэером обрабатывается на уровне кода так же, как и написанная в скрипте. Ну а поскольку обработчику onEnterFrame может быть присвоена только одна функция, то одновременной программной и ручной анимации быть и не должно...
Это лишь соображения, но интересно, что думают продвинутые?

[Nox Noctis]

есть кейфреймы. что бы вы там ни вытворяли скриптом, в каждом кейфрейме клип встанет в то меято, куда вы его руками поставили... и второе, если идёт твин, а вы в это время что-то поменяете у клипа скриптом - твин может оборваться.

[Ромастый]

То есь наличие кейфрэйма автоматом обрывает любое событие, onEnterFrame, omMouseMove и т.п. и присвоенные им функции? И наоборот?

[Nox Noctis]

в принципе да. только основная причина тут в том, что в каждом кейфрейме клип инициализируется заново... если у него был онЕнтерФрейм - его уже не будет, надо присваивать еще раз.

здесь правда имеет место некоторый косяк :)
если у вас подряд кейфреймы с одним и тем же клипом в одном слое (в ОДНОМ слое), то онЕнтерФрейм может не удалиться. хотя это логически не правильно...

то есть когда следуют кейфреймы с одним и тем же клипом на одном и том же слой, то может возникнуть баг с непереинициализацией (хорошее слово, ага :) ), а это может сказаться очень по-разному..

[Ромастый]

Точно, было такое... Видимо все-таки баг, так как однажды сначало все типа работало, непере... непри... непрениципа... ну короче этого умного слова не было, а потом сделал незначительное изменение, с этим мувом и слоем не связанное, и все.

[Nox Noctis]

при наступании на эти грабли иногда бывает достаточно в клипе поставить trace(this) чтобы всё заработало... а казалось бы какая фигня :))

[Iv]

решение следующее:
допустим имеется motionTween некоего объекта.
в какой-то момент требуется поменять ему, например, высоту.

Делаем следующее:
делаем мувик внутри того, с которым производим motion tween
и пишем ему:
onClipEvent(load) {
this._parent._parent.in_motion_mc = this
}

далее в некий момент мы всегда можем получить на него ссылку и управлять им:

this.in_motion_mc._height*=2

примерно такое сочетание возможно.

однакожа:
при всякоразных переходах, помимо play() все это щастье слетает. исправимо. делаем таперича так:

onClipEvent(load) {
this._parent._parent.in_motion_mc = this
var i, obj = this._parent._parent.in_motion_object
for (var i in obj)
this[i]=obj[i]
}}

но и задаем значение и там и там:

this.in_motion_object._height = this.in_motion_mc._height*=2

разумеется, перед самым началом нужно инициализировать объект:
this.in_motion_object = {}

можно базируясь на этом принципе создать в in_motion_object свойства и юзать их, но это уже дело техники.

Есть еще одно принципиальлно отличающееся решение, которое мне больше нравится:
по пути пускаем не тот мувик, который хотим анимировать, а квадратик.
Мувик по ходу дела должен считывать параметры с квадратика и самостоятельно (программно) принимать решение, какие свойства ему цеплять от этого твина.
Рещение хорошо тем, что можно этим мувиком плавно переплывать от твина к твину, при этом никак жестко на них не завязываясь.
И именно поэтому это более правильное решение.

[Nox Noctis]

итого: нафиг надо :) зачем такие заморочки, когда можно сделать проще... :)