Вызов гуя, есть проблемы.
Короче есть у меня скрипт, который следит за тем чтобы гуй был вкл или выкл.
По клику мыши на монстра, меняется переменная в глобальном скрипте, и другой скрипт включает отображение гуя на канвасе. При повторном щелчке мыши где угодно у меня вызывается переменная, которая выключает отображения гуя через тот же скрипт. Скрипт отслеживающий щелчки по монстру, скрипт с глобальными переменными статическими, и вызывающий гуй скрипт - разные. Всё работает до тех пор, пока я не собираюсь при вызванном гуе с монстра щёлкнуть мышкой в другого монстра, и тут в 30% случаев сначала вызывается гуй, потом сразу скрывается из-за скрипта в предыдущем монстре (скрипта, который после отображения скрывает гуй по щелчку). Выглядит как баг, и не приятно. Посоветуйте как лучше организовать процесс, может у кого есть идеи? Отображение и скрытие должны происходить на одну и ту же клавишу, и то действие должно быть применимо к любому количеству пропикиваемых лучом монстров. Я чё-то по ходу на работе заработался, что сейчас вечерами не могу решить такую простую элементарную задачу. А теперь снова всё то же самое: К щелчку по монстру привязано отображение гуя, когда гуй отображён, при любом следующем щелчке срабатывает скрипт скрывающий гуй. Проблема случается в тот момент, когда уже при отображённом гуе вызванном на одном монстре, мне вдруг нужно щёлкнуть в другого монстра и вызвать тот же гуй. В 30% случаев, сначала срабатывает вызов гуя на новом монстре, и после на предыдущем монстре тот же самый клик мне всё руинит закрывая гуй. Я знаю, что можно сделать, чтобы только по клику на монстра или на кнопку гуй закрывался, и после типа мы только получали возможность тыкать в другого монстра, но мне это не подходит, т.к. это медленный вариант раздражающий игрока, всё должно делаться быстро, и по клику на одну и ту же клавишу. Вопрос в том, как дать понять скрипту, что раз мы уже на другом монстре гуй вызвали, то на прерыдущем его по щелчку скрывать не надо. Вроде всё элементарно, тупо, просто. Но это юнити, и он мне что-то мозг сломал, со своей разбивкой на миллион префабов, и скриптов обрабатываемых в рандомном порядке. Если бы хотя бы какая-то структура обработки скриптов была на вызванных префабах, а он рандомом хреначит без последовательности чёткой. |
Ответ: Вызов гуя, есть проблемы.
Я бы не открывал гуй с скрипта на монстре, а открывал гуй тем скриптом, которым ты его скрываешь. Пусть этот скрипт палит где ты кликнул, если - монстр - открой гуй монстра, если другое место - скрыть гуй. Ну и соответственно клик на другом монстре обновит открытый гуй.
PS: еще есть конечно фича явного указания порядка обработки скриптов Script Execution Order, но это только в экстремальных случаях) |
Ответ: Вызов гуя, есть проблемы.
Цитата:
отрабатывают пики лучём и щелчки клавишами, результат отработки идёт в переменные глобального скрипта, а вот за ними следит скрипт который скрыванием и отображением гуя занимается, этот скрипт к префабу юнита не привязан, он привязан к независимому объекту на сцене. Представьте стратегию, где куча одинаковых юнитов-префабов, вот они спавнятся, у них у всех один и тот же скрипт, который следит за клацаниями мышки, и за лучом. Проблема грубо говоря в том, что я мышкой юнитов выделяю, одновременно может быть выделен только один, и вот когда у меня уже есть выделенный юнит, и я хочу выделить другого не сбросив выделения с первого, то по логике скрипта когда я навёл на нового юнита луч и клацнул мышью, в него полетел луч, что привело к выделению юнита в последствии, но к этой же самой клавише мышки в скрипте привязано снятие выделения с юнита, по тому, что мне так надо. Так вот значит у меня уже один выделенный, я хочу вместо него выделить другого не сбрасывая предварительно выделения у первого, оно должно само сброситься при выделении нового, стреляю в нового лучом, он выделяется, появляется гуй, но перед этим у старого юнита должно произойти снятие выделения, и гуй должен исчезнуть, чтобы у нового он появился, и это работает в 70% случаев, но в 30% порядок меняется, случайно, просто юнити решает, а давай ка я сначала займусь обработкой скрипта вон того юнита, а не этого, и хопа у меня баг, я на новом юните вместо отображения гуя получаю его скрытие, по тому что старый юнит кинул переменную закрытия в следящий за этим делом скрипт. Блин, я надеюсь доходчиво процесс описываю, мне то понятно что я пишу, но понятно ли вам неизвестно )) Короче, я никогда не сталкивался с такими проблемами в блитце, а ведь у меня есть на нём прототип RTS, но тут же с этими префабами, и непонятно как обрабатываемыми скриптами я проблему победить пока не могу. Я просто не могу задать порядок выполнения процессов в одинаковых скриптах одинаковых префабах в нужной последовательности при определённых обстоятельствах. Рано или поздно я это сделаю, правда даже не представляю что за монстра мне придётся породить, это будет что-то наверное работающее через задницу. В блитце канваса нет, с любой функции можно прям на экран рисовать что хочешь, с любого копированного типа, а в юньке я привязан к панели на канвасе, который висит в инспекторе, и ссылку на него в скрипт префаба не перетянуть из-за механики интерфейса юнити. Вот мне и приходится как-то раком через жопу через глобальные переменные и отдельный скрипт вылавливать статус состояния гуя, для его отрисовки, по тому что юнитивский гуй общий для всех юнитов, ибо для экономии ресурсов я не могу на каждого юнита создавать отдельный канвас, я говнодел но не на столько. Добавлю: скрытие гуя реализовано так, что оно может произойти только на втором прогоне скрипта после выделения юнита, и прописано оно раньше, чем область кода отвечающая за отображение гуя. По идее, раз скрипт у всех юнитов одинаковый, и они одинаково отслеживают нажатия клавиши, то при одновременном срабатывании скрипта везде, сначала по порядку должно произойти скрытие гуя на старом юните, а после открытие на новом. Но как я теперь понимаю, юнити обрабатывает одинаковый скрипт на каждом префабе по очереди, а не одновременно, и очерёдность обработки он выбирает сам по рандому, по воле аллаха. Если бы мне удалось задать очерёдность обработки скриптов, понижать и повышать статус важности выполнения, тогда бы юнити делал то, что мне нужно. Подчёркиваю, очерёдность обработки одного и того же скрипта на одинаковых префабах. Можно поставить таймер на отображение гуя в пол секунды, но игрока будет раздражать, это не решение. |
Ответ: Вызов гуя, есть проблемы.
Проблему решил за счёт нагрузки движка лишней прокруткой скрипта.
В общем сделал так, что при первом нажатии скрипт запоминает это действие, прокручивается без вызова гуя, и после он 1 раз уже сам себя прогоняет без кликания мышки и вызывает гуй. При этом функция скрытия гуя выполняется сразу в первую прокрутку скрипта. (а ведь скрытие у нас по условию [не каждый цикл скрипта]) Так-как юнити выбирает у префабов скрипты рандомно, но с условием, что он не прокрутит скрипт ещё раз, пока не прокрутит все остальные по разу, а вызов гуя у нас происходит только на вторую самозапускаемую прокрутку, то сто процентов скрипт сначала везде по убирает гуй, потом самозапустится и гуй вызовет. Всё работает. Сразу по ходу это породило баг, сделавший невозможным скрытие гуя по клику на уже выделенного монстра, но я эту проблему решил добавлением ещё одной переменной, и отслеживанием оной. |
Ответ: Вызов гуя, есть проблемы.
Механика такова:
Код:
private int ProgonScripta = 0; |
Ответ: Вызов гуя, есть проблемы.
Как это часто бывает, решение одной проблемы может породить другую,
теперь я не могу перемещать юнитов, и знаю почему, лол, ну это я уже решу )) |
Ответ: Вызов гуя, есть проблемы.
Так не интересно, уже решил :(
|
Ответ: Вызов гуя, есть проблемы.
Билд этого всего тут: ТЫК
Мышкой бежим к монстру, выбираем режим "сражаться". В сцене боя пока все юниты подконтрольны игроку, можно наспавнить ещё сколько хочешь. Ну и вот там по тыкайте по выделяйте, по сбрасывайте выделение, всё должно работать. |
Ответ: Вызов гуя, есть проблемы.
Сорян, что с запозданием, я вижу примерно такой алгоритм работы (пишу прям в браузере, могут быть ошибки):
PHP код:
PHP код:
PHP код:
|
Ответ: Вызов гуя, есть проблемы.
Привет Пакс, спасибо за труд, но это ты зря, я же за теорией только пришёл с конкретной проблемой )
(может в будущем мне понадобится подсмотреть твоё решение, если споткнусь об очередную граблю) У меня сейчас всё работает как надо, а пример того, как оно работает я выше описал. (без конкретных участков как мы луч пускаем, и тд). Оно всё так или иначе близко к тому, что ты накодил здесь, я просто не стал сюда код выкладывать, т.к. он делает ещё много всего помимо включения интерфейса. Там ещё всякие условия есть, не нашла ли мышь на интерфейс, не сделали ли мы там чё-то ещё. Однако я считаю твоя работа может быть кому-то полезной, и это хорошо, контент на форуме. Стиль у нас конечно кодинга на разном уровне, у меня всё ещё говнокодинг лютый, а у тебя по симпатичнее ) Если будет интересно, как это работает у меня, код скину, правда комментариев мало, и есть не удалённый мусор. ---- Ты кстати свой код не испытывал ещё в реалиях? Может тот же баг со скрытием интерфейса вылезет ) Условие : один юнит уже выделен, нам надо выделить другого в 1 клик. У меня в действительности до моего решения баг вылезал не сразу, а где-то на шестом\седьмом юните. Так что это ещё наспавнить надо кучу, и прокликивать, чтобы выловить. |
Ответ: Вызов гуя, есть проблемы.
Цитата:
Тестировать не тестировал, прям в браузере писал. Но багов не должно быть, тут все однозначно. |
Ответ: Вызов гуя, есть проблемы.
Щас покажу панковский метод:
Скрипт отвечающий и за выделение монстра, и за построение\удаление сетки полигонов меша внутри ассета, с учётом массива проходимости ячеек: [предупреждаю - есть мусор, оставленный от предыдущих версий, и тестов - на езду не влияет ))] Код:
using System.Collections; Код:
using System.Collections; Код:
using System.Collections; однако этот код исправно функционирует, и довольно быстро ) |
Ответ: Вызов гуя, есть проблемы.
Много сложного кода :) . Но судя по последнему небольшому скрипту (SkillPanelSkrivator), он мониторит переменные и делает что-то на их основе.
Проблема может быть в том, что ты в блоках if не завершаешь логику (не делаешь return). Т.е. у тебя каждый Update всегда проверяются все три блока if. Ну и в дополнение - избавляйся от магических чисел, используй энамы или константы. |
Ответ: Вызов гуя, есть проблемы.
Цитата:
|
Ответ: Вызов гуя, есть проблемы.
Цитата:
Когда апдейт докручивает до определённого if, он внутри скобок проверяет условие, в каком состоянии находится интересующая нас переменная, и при удовлетворительном результате запускает весь код в фигурных скобках. Цитата:
Фраза защищающая от рукожопых исследователей ) |
Ответ: Вызов гуя, есть проблемы.
В общем несколько советов (в порядке важности):
1. Не делать такие большие методы (как например Update класса SetkaHodaMonstra), а разделять на более мелкие методы. Это повысит читабельности коду и даст кускам кода имена (наименования методов). Для повышение читабельности так же можно использовать автоформат кода в Visual Studio (сочетание клавиш Ctrl+E, D или через меню Правка-Дополнительно-Форматировать документ). 2. Выносить специфические вещи в отдельные классы, не обязательно MonoBehaviour, а просто классы, выполняющие какую-то цель. Например генерацию меша сетки. Ну а если код отвечает за работу какого-то игрового объекта, то делать отдельный скрипт (MonoBehaviour) для этого объекта. Пусть свои функции он выполняет сам, а извне им только управлять (вызывать его методы, менять значения его открытых полей). 3. Избавляться от магических чисел. В коде много чисел, которые непонятно для чего служат. Лучше создавать константы с осмысленными именами для этих чисел и в коде применять эти константы. Если число определяет состояние, то использовать enum для задания состояний. Например FightScene.SkillPanelSower присваиваются какие-то значения и потом проверяются. Это просто числа, хз что они значат. Можно было бы сделать так: PHP код:
PHP код:
5. Не искал в коде дублирование данных, но если оно есть, то этого стоит избегать. Если в сцене есть какие-то скрипты на объектах, то их всегда можно найти и получить с них данные с помощью методов FindObjectOfType<T> или FindObjectsOfType<T>. Имея ссылку на объект в виде GameObject или другого компонента этого объекта можно всегда получить другие компоненты с этого объекта с помощью методов GetComponent<T> или GetComponentInChildren<T>. Если объект имеет несколько одинаковых компонентов, то есть аналогичные методы, возвращающие массивы компонентов GetComponents<T> или GetComponentsInChildren<T>. 6. Не создавать универсальные переменные. По типу таких: PHP код:
7. Первый раз вижу в коде использование ZERO как нуля) Но если даже так, то это константа, тогда она должна быть объявлена так: PHP код:
PHP код:
PHP код:
PHP код:
Все, завязываю с советами ) |
Ответ: Вызов гуя, есть проблемы.
1. Этот метод генерирует сетку из полигонов,
так-как генерация происходит одновременно с выделением монстра, эти обе функции вдолблены в один скрипт. Выглядит громоздко, по тому что идёт много расчётов, так-как сгенерировать полигоны в нужных местах с учётом непроходимых зон не так то просто. Скрипт громоздкий ещё и по тому, что я перевожу в нём координатную систему в номерную, то есть буквально точки координат в номера ячеек на сетке. Я придумал формулу, по которой точку в двумерном графике XY можно перевести в номер ячейки. ((X * Yмакс) - Yмакс) + Y Расчёт по точкам графика от нуля (X=0, Y=0) до любых положительных чисел. Мне это нужно, так как при пике лучом я получаю координаты объекта, которые округляю, а строю сетку в циклах по номерам ячеек. Про скрипты на монстре, далеко не всё в одном файле, даже близко нет. Например стрельба скиллом это другой скрипт, генерация сетки радиуса удара другой, подворачивающий монстра на камеру другой, скрипты интерфейса тоже отдельные. Я чисто всё в один скрипт не луплю. 2. С классами я лично осваивая юнити так и не понял нафига их плодить, если всё прекрасно в монобехавере живёт. Этот момент поясни. 3. Ну это со стороны непонятно, а автор этого кода знает что они значат ) Для работы в команде программистов я думаю это важно, но когда код для себя, так сказать не опен, то собственно нет. Насчёт свитчей мне уже указывали ранее на булке, и я эту технологию внедрил в том моменте, про который говорили, но тем не менее наблюдая не увидел никаких преимуществ, ни в скорости работы, ни в принципе. По этому в основном набирая быстро код мне проще накидать ifов, чем этот список строить. 4. Снова списки и массивы. Я конечно по всякому пробовал, но опять таки ни прироста скорости обработки, ни какой-то другой пользы не нашёл. Массивы использую там где огромное количество чисел надо хранить, или ещё чего, но там где их до шести например, куда нагляднее и удобнее впихнуть шесть переменных столбиком лично мне. 5. Универсальные переменные те подразумевают то, что ни при каких условиях одна и та же переменная не будет использоваться в разных местах одновременно. Смысл был сократить количество переменных в коде, если делать отдельные по месту то их получится в разы больше. Это тупо счётчики. 6. Что изменится? Это постоянное число. Случайное присвоение исключено, я же знаю что это ноль, который должен быть нолём ) 7. На счёт "for" все три варианта почти одно и то же, это уже вкусовщина. Но первый вариант исключение, так-как тут мы можем использовать любую другую переменную, и проверять её состояние (число), "а вдруг не ноль?" ) --- Твои советы интересны, продолжай ) |
Ответ: Вызов гуя, есть проблемы.
Цитата:
Цитата:
Цитата:
Цитата:
|
Ответ: Вызов гуя, есть проблемы.
Цитата:
Вместо сравнения с нулём нулю присвоил ноль ) |
Ответ: Вызов гуя, есть проблемы.
Цитата:
Если кратко, то вот что я бы лично для себя выделил:
Конечно же, доводить до полного абсолюта эту идею тоже не надо. Если где-то нет других вариантов, то пишем число. Например, если надо что-то обнулить, то, понятное дело, нельзя обнулить что-то с числом 2.71. Обнуляют всегда с нулём. Поэтому и пишем просто 0, других вариантов нет, надобности заводить переменную "zero" тоже нет. Циклы for бывают чаще всего с 0, но бывают и с 1, но там тоже обычно нет вариантов. Поэтому переменные "zero" и "one" тоже не нужны. Бывает ещё чего-то нужно вдвое больше, например, если ты располагаешь какой-то объект по центру чего-то, и поэтому его надо сдвинуть ровно на половину его ширины. Поэтому мы умножаем её на 0.5 (ну или делим на 2, кому как больше нравится). Любое другое значение будет означать, что объект поставится криво. Поэтому пишем само число. В качестве исключения ещё можно назвать какой-нибудь временный код, по типу for(int i=0; i<10; i++) createEnemy(); где ты, допустим, чисто для теста хочешь создать чего-нибудь 10 штук, потестить и удалить. Т.е. этот код не предполагается, что будет "жить" сколько-нибудь долго, и когда ты доделаешь функцию до конца, ты это удалишь. В-общем, если обобщить, то идея такая: если есть (даже теоретическая) возможность подгонки числа, то хорошим тоном будет завести под него переменную или константу. Особенно если стороннему человеку не очень понятно с первого взгляда, а что это число означает. Тогда в названии переменной будет подсказка, что это число делает, что сэкономит читающему время. Помни, что читающим твой код и не понимающим, что он делает, будешь ты сам спустя долгое время. И только если вариантов никаких других нет вообще, тогда можно написать само число (обычно это -1, 0, 1, 2, 0.5). Всё, что-то я растёкся мыслию по древу и разумничался, за сим откланиваюсь. |
Ответ: Вызов гуя, есть проблемы.
Цитата:
Я открываю свои коды тринадцатилетней давности, и сразу понимаю что к чему в них. По текущему проекту передышки по 2 месяца, возвращаюсь ничего не помня, открываю и вижу как это работает, а важные переменные подписаны. Для меня всё сразу очевидно, что куда как, т.к. создано мной, и работает по моей логике, собственно мой код это то, как я мыслю. На то как читают мой код другие мне абсолютно по барабану, т.к. соло проект, и мне не нужно работать над тем, чтобы кто-то понял внутряк. Проект не будет опен. Собственно, работаю как мне удобно. Я придерживаюсь двух задач, это быстрота работы кода, и скорость его реализации. Красота, читаемость для других, какие-то там нормы морали программерские меня не интересуют, правда. Я знаю что есть некие каноны кодинга, и даже могу по канону, но вот насрать вообще, до тех пор пока мне удобно, и пока я понимаю что у меня там в строках происходит )) Это ребята всё равно, что спорить о том, как правильно задницу вытирать, сверху вниз, или снизу вверх, зевой плюс, или лопухом ) Давайте уже не будем флудить по теме, я задачу решил по своему, на будущее висит решение пакса, к которому я в каком-либо моменте возможно обращусь ещё. Ну а про нормы морали программиста, и феншуй, предлагаю создать отдельную тему, где каждый может заняться просветительством )) Все советы были полезны, спасибо. P.s. Я сейчас пишу анимацию хелсбара на "магических числах", надо наверно будет прикола ради код выложить, и посмотреть как в меня полетят ссаные тряпки ))) |
Ответ: Вызов гуя, есть проблемы.
Цитата:
|
Ответ: Вызов гуя, есть проблемы.
Цитата:
За тем, что в коде помимо перемещения квадов я управляю их прозрачностью и цветом ) Аниматор то используют чтобы в нужное время нужную анимацию запускать настраивая это чем то типа нодов. А у меня нет никакой анимации, я просто квады двигаю куда мне надо ) |
Ответ: Вызов гуя, есть проблемы.
Цитата:
Небольшой пример: PHP код:
Даже рискну пример написать) PHP код:
|
Ответ: Вызов гуя, есть проблемы.
Вложений: 1
Ну и в дополнение к предыдущему посту собрал хэлсбар на аниматоре с изменением цвета бара + миганием (два слоя анимации).
Сама работа хэлсбара на аниматоре с тремя анимациями в аттаче (видео). Управляется аниматор одним параметром - нормализованным здоровьем (heathNormalized). Хэлсбар управляется вот этим скриптом. PHP код:
|
Ответ: Вызов гуя, есть проблемы.
Не, мой хелсбар не похож ни на что, что ты видел.
Он у меня я бы сказал - дичь. Как говорят художники "я так вижу". Когда закончу, увидите, времени мало щас, по чуть-чуть успеваю кодить. Если есть спортивный интерес, и свободное время, потом можешь повторить через анимации, с удовольствием погляжу этот вариант. Видео посмотрел, нужно будет как-нибудь покурить эту тему, явно найду применение. Видно что да, можно делать то же самое, что я пишу, скорее всего даже так проще (если уже работал с этим). |
Ответ: Вызов гуя, есть проблемы.
Цитата:
|
Ответ: Вызов гуя, есть проблемы.
|
Ответ: Вызов гуя, есть проблемы.
Вложений: 1
Цитата:
В результате получилось 4 анимации (анимация движения линии вверх-вниз, анимация прозрачности, анимация для перемещения квадратиков и собственно анимация состояния хэлсбара). Анимация прозрачности используется как на линиях, так и на квадратиках. Пришлось для каждой линии сделать копию контроллера анимации и настроить немного по разному скорости воспроизведения анимаций, чтобы получилось так же как у тебя. Тоже самое сделал для квадратиков. Анимация состояния хэлсбара управляет цветом линий и квадратиков (без прозрачности), а так же их масштабом. Плюс она двигает спрайты "скобок". |
Ответ: Вызов гуя, есть проблемы.
Но зачем и чтобы что, если кодом проще?
|
Ответ: Вызов гуя, есть проблемы.
Цитата:
столько же времени, и думаю будет один в один. Челлендж выполнен быстрее, чем я расчитывал! Лично мне ты всё доказал с анимациями. Только я думал анимаций меньше будет использоваться ) Немного шлифануть, чуть докодить, и это сэкономило бы мне много строк кода. А теперь внимание, барабанная дробь, и на экране появляются магические числа без комментариев: Много самокопипасты внутри кода, т.к. линиями управляет одинаковый код, но с другими значениями. Оптимизировать размер можно, не стал заморачиваться, смысла не имеет. На счёт скорости работы кодом, не уверен, что она выше, т.к. я например постоянно мерю расстояния. Первый вариант у меня был на таймерах, но я пришёл к выводу, что таймеры здесь неуместны. Ну и вместо констант магические числа, для меня они те же константы ) Цитата:
Отличный вариант для дизайнера ) Ну, когда игры чисто на нодах пишут во всяких UE ) В общем данный способ имеет место быть, и нужно это как-то на ус мотать, реально вижу экономит время. |
Ответ: Вызов гуя, есть проблемы.
Добавил. Я сейчас подумал, и уже не уверен, что на анимациях разрабокта быстрее.
Я всё-таки больше возился с расчётом цвета, никто не написал в этих ваших хэлпах, что цвет задаётся от 0 до 1, а не от 0 до 255 как в интерфейсе юньки, и другие подводные камни, об которые я споткнулся. Управление движением же было накодено моментально. Тут надо как-то в общем скорость работы сравнивать, чтобы понять, зачем и чтобы что ) |
Ответ: Вызов гуя, есть проблемы.
Цитата:
Цитата:
|
Ответ: Вызов гуя, есть проблемы.
Цитата:
массив не является для меня чем-то новым и непонятным ) Просто я использую массивы только для хранения огромных объёмов информации. В текущем проекте например в массивах хранятся карты проходимости по клеткам уровня, хранятся координаты ячеек при конструировании мешей. Когда дойду до загрузки-сохранения игрового процесса, тоже всё будет в массивах. |
Ответ: Вызов гуя, есть проблемы.
Вложений: 2
Цитата:
PHP код:
|
Ответ: Вызов гуя, есть проблемы.
Цитата:
Это уже оффтоп, но я всегда допускаю оффтопство в своих темах. Даже хелсбар оффтоп на самом деле )) Что там после покойного стимкрафта? Есть попытки ворваться в стим с новым проектом? |
Ответ: Вызов гуя, есть проблемы.
Цитата:
|
Ответ: Вызов гуя, есть проблемы.
Цитата:
Если нужно придумывать, обращайся, геймдиз вартича к твоим услугам )) У меня куча вообще нереализованных игр, или заброшенных вначале. Даже уже могу предложить кое что, где не придётся моделить и анимировать человеков, эта идея улетела в ящик уже 13 лет как. |
Ответ: Вызов гуя, есть проблемы.
Цитата:
|
Часовой пояс GMT +4, время: 06:31. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot