Непростое копирование мувиклипа.

[kotbuterbrod]

Задача многократно скопировать мувиклип, особенность: Внутри него другие мувиклипы каждый из которых остановлен на определенном кадре.

Добавлено через 46 минут
Мой вопрос слишком простой или слишком сложный ? Почему никто не может помочь.

[mikhailk]

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

Но, вообще-то, то делается не совсем так.

[kotbuterbrod]

Вот в этом то и проблема, пройтись по ним не так просто их много и данные для них, грузятся из базы данных в общем, будет не очень технично. Я думал может есть какая то возможность создать копию экземпляра - я честно говоря думал, что это и есть сильная сторона ООП.

[mikhailk]

Метода clone() для мувиклипов нет.
Можете его написать сами.
Но в итоге все равно все сведется к порождению экземпляра определенного класса и установке для него соответствующих параметров.

Впрочем, возможно, имеет смысл погуглить.
Может, уже существует какое-нибудь готовое решение.

[kotbuterbrod]

Вроде бы такая такая насущная проблема, и такое не очевидное решение..... Да я уже и гуглил и яндексил и даже альтавистил.... :)

Может быть имеется способ снять как-то как растр изображение.... смотрел bitmapData не понял про мой это случай или нет.

Задача то простейшая в двух местах отобразить один мувик.....

[mikhailk]

все с точностью до наоборот :)
при правильном подходе Вы никогда не столкнетесь с такой задачей

ЗЫ. Это, кстати, общее правило в AS3 - если что-то не имеет простой и ясной реализации, значит надо решать иначе.

Добавлено через 2 минуты
Может быть имеется способ снять как-то как растр изображение....

без проблем
http://help.adobe.com/ru_RU/AS3LCR/Flash_10.0/flash/display/BitmapData.html#draw%28%29

что все-таки на самом деле-то надо?

[kotbuterbrod]

Хотелось бы понять как мог бы выглядеть правильный подход, в данных условиях, если вам не сложно.

Добавлено через 4 минуты
На самом деле надо описанный мувиклип отобразить в разных частях экрана.

[mikhailk]

на мой взгляд, правильный подход выглядит примерно так:

1. Есть некий класс ComplexMovieClip, который описывает целиком этот сложный мувиклип, собирает его и знает его конфигурацию и текущее состояние.

2. В этом классе есть метод getParameters(), который считывает параметры существующего экземпляра мувиклипа, и setParameters(), который их "накатывает" на новый экземпляр мувиклипа. Сами параметры передаются, например, XMLList'ом или просто в виде объекта.

3. Процесс клонирования реализуется так:


// currentMC - существующий мувиклип
var newMC:ComplexMovieClip = new ComplexMovieClip();
newMC.setParameters(currentMC.getParameters());
addChild(newMC);

[kotbuterbrod]

По размеру кода это будет сопоставимо. С тем, что бы вручную все назначать .... если не больше..... вот тебе и ООП.... а правильность или неправильность это вопрос второй если у меня "неправильный код" состоит из трех строчек а "правильный" из семи и в выполнении между ними нет разницы, то зачем платить больше ? :) Спасибо за советы, просто я думал, что в ООП это решается разом. Я тогда уж лучше bitmapData использую

[mikhailk]

Сделайте в AS2
там MovieClip.duplicateMovieClip есть

[kotbuterbrod]

НЕТ. duplicate дает возврат на 1 кадр.

[-De-]

Как вариант - сделать BitmapData, посадить её в кучу разных Bitmap (и так бы сделал инстанцирование(копирование)) и по ENTER_FRAME BitmapData перерисовывал вот при помощи BitmapData draw.
Просто во флэше есть вот такой DisplayList. Не оч. вот местами ООП-шный и дружащий с показыванием одного и того же в разных местах. Если будете всё рисовать без addChild, каждому обьекту там по методу render, который рисует в рут, то проблем отрисовать обьект в разных местах не будет. Можно даже сделать свой DisplayList, в котором разрешить инстанцирование, где addChild не будет убирать из предыдущего контейнера (подумайте, что с parent делать при этом) =)

[mikhailk]

Офф: только сейчас внимательно прочитал название топика :D

[kotbuterbrod]

Извиняюсь просто писал с нетбука.... неудобно.

[Psycho Tiger]

а правильность или неправильность это вопрос второй если у меня "неправильный код" состоит из трех строчек а "правильный" из семи и в выполнении между ними нет разницы, то зачем платить больше ? Спасибо за советы, просто я думал, что в ООП это решается разом. Я тогда уж лучше bitmapData использую

В ООП это решается разом. Только Вы наверно не совсем понимаете что такое ООП. Кстати говоря, использование BitmapData без ООП впринципе невозможно.

[kotbuterbrod]

Неправильно выразился прошу прощения.

Добавлено через 6 минут
Да просто когда смотришь на парадигму ООП, ну так все прекрасно создаешь классы, экземпляры и кажется ну как же все классно, но вот элементарнейшая задача и я не могу сделать клон экземпляра что бы просто отобразить в нескольких местах....

[Psycho Tiger]

Классы должны имплементить IClonable. Хотя, думаю оно Вам мало надо.

Классы должны иметь метод clone. При клонировании класс клонирует себя полностью, а у дочерних элементов тоже вызывает clone, которые в свою очередь тоже вызывают clone. Достучаться до визуальных объектов можно с помощью getChildAt.
В итоге всё клонирование я бы сделал примерно так (код пишу здесь, что-то тестить лень)
*Стёр всё нафиг, подумал*.
Скорее всего Вы в иде эти мувиклипы рисовали. Поэтому достаточно склонировать родителя так:
var displayObject:DisplayObject = new (Object(this).constructor)();
А затем рекурсивно пройти по всем его детям и поставить им кад, примерно какой должен быть у другого.
Код писал тут - кривой, наверно нерабочий, но мысль показал.
var mc:MovieClip=displayObject as MovieClip;
mc.gotoAndStop(super.currentframe);
setFrames(this, mc);
...
private function setFrames(mc1:DisplayObjectContainer, mc2:DisplayObjectContainer){
if (mc1 is MovieClip) (mc2 as MovieClip).gotoAndStop((mc1 as MovieClip).currentframe);
var i:int=mc1.numChildren;
while (i--){
var child:DisplayObject = mc1.getChildAt(i);
var mc:MovieClip=child as MovieClip;
if (mc){
(mc2.getChildAt(i) as MovieClip).gotoAndStop(mc.currentframe).
}

var doc:Sprite=child as DisplayObjectContainer;
if (doc) setFrames(this, doc);
}
}

[Bgg]

Да, во всем виноват ООП, подлец такой, а.

[mikhailk]

огда смотришь на парадигму ООП, ну так все прекрасно создаешь классы, экземпляры и кажется ну как же все классно, но вот элементарнейшая задача и я не могу сделать клон экземпляра что бы просто отобразить в нескольких местах....


Все в порядке, на самом деле.
AS3 препятствует реализации неправильной архитектуры.
Имеет смысл "расслабиться и попытаться получить удовольствие".

[-De-]

mikhailk, код в кадрах и анонимные функции тогда - правильная архитектура?
А та, где применяется инстанцирование мувиков и глубокое клонирование их - неправильная?
AS3 не тот язык, который особо препятствует выстрелу себе в ногу. И у него есть недостатки.
Хотя тут проблема не языка и концепции ООП, а реализации некоторых встроенных штук. Ну нет некоторых фич так нет. Можно самому написать. Можно обидеться и уйти на с++, жабу и юнити. Увидеть, насколько мы тут зажрались с этим нашим флэшом. Нет, видите ли, функций копирования мувика =)

[mikhailk]

код в кадрах и анонимные функции тогда - правильная архитектура?
А та, где применяется инстанцирование мувиков и глубокое клонирование их - неправильная?


Код в кадрах - категорически неправильная.
Клонирование объектов - просто неправильная.

Я себе, честно говоря, вообще не представляю, зачем может понадобиться именно клонирование объектов.

[-De-]

Как это зачем - одинаковые штуки делать! Вредных фич не бывает. Тем более во флэше хватает штук, ориентированных не на программистов, а на дизайнеров, которые не брезгают что-то подкодить. Вся нехилая система с кодом в кадрах, например.
Игра - пропаганда против алкоголя, периодически что-то в глазах двоится =)
Враг вызывает из сопряженных комплексных антимиров своего доброго тройника.
Домик-труба-дым-шатать, 3 штуки разных, делаем деревню, некоторые умрут в катаклизме.
Топикстартера можно вот ещё спросить =)

[kotbuterbrod]

Отвечу. Не дожидаясь вопроса. Создается игра внешний вид персонажа настраивается путем присоединения мувиков и перехода в них на определенный кадр. Это стандартный ход для ММО казуальных игр. Так вот потребовалось выводить внешний вид персонажа в разных местах. Я уже конечно решил проблему совершенно другим способом он не будет полезен всем остальным поэтому промолчал. Но все таки где-то в глубине души, надеялся, что кто нибудь может знает простое - гениальное решение. А по поводу "правильного" подхода уже устал на разных форумах видеть когда кто-то, что-то спрашивают, а человеку высокопарный сэр говорит да это просто "неправильный" подход. Я не понимаю, что значит правильный - еще раз повторюсь я буду использовать неправильный код пока он в 10 раз короче, чем правильный.

[mikhailk]

Как это зачем - одинаковые штуки делать!

Вам когда во вторник нужно зубы почистить, Вы клонируете пасту на щетке из понедельника или выдавливаете новую из тюбика?


Создается игра внешний вид персонажа настраивается путем присоединения мувиков и перехода в них на определенный кадр. Это стандартный ход для ММО казуальных игр. Так вот потребовалось выводить внешний вид персонажа в разных местах.


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

Я же говорю, Вы не ту задачу решаете, поэтому она и решается сложно.

[-De-]

Вам когда во вторник нужно зубы почистить, Вы клонируете пасту на щетке из понедельника или выдавливаете новую из тюбика?

А если бы клонировать пасту из понедельника было бы так же просто, как новую выдавить - вы бы не клонировали, т.к. это неправильно?
В реале КРАЙНЕ не хватает этой фичи. Я бы клонировал пиццу, а то они через раз хорошие, а чтоб поесть супер вкусную надо найти место и чтоб ещё повезло. А так бы у меня был набор из идеальных пицц!
По сути вы предлагаете топикстартеру реализовать копирование самостоятельно: "через класс перса, который его собирает в нужной конфигурации". Писать самому ручками. Потому что если бы такое можно было сделать автоматом, то оно было бы зло и не труЪ?

[mikhailk]

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

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

На самом деле, этот класс перса в части его создания - 20-30 строк кода. Не о чем говорить.

[Psycho Tiger]

Я думаю диалог можно было вообще закончить после слов "делаю неправильно, потому что короче!". Скоро этот человек станет воинствующим синглтонщиком, его не остановить. Это же очевидно.

[dimarik]

Ответ дан. Беседка в другом разделе.