Проверь в редакторе данных, там вроде был флаг для этого, чтобы трек считался одноразовым или автоповторяемым. Могу ошибаться - давно последний раз там был.
В худшем случае всегда можно сделать wait на длительность трека.
Я бы рекомендовал сперва реализовать костяк игры с обязательными механиками, а потом уже экспериментировать со всяким. Это не значит, что не нужно планировать экспериментальные механики заранее, просто следует выделить минимальный набор обязательных систем, без которых игра не получится, а все остальные системы описать и спланировать отдельно, исходя из того, что любая из этих систем может оказаться нежизнеспособной на этапе реализации.
Первый случай - неправильные нормали поверхности. В 3д редакторе все нормально, скорее всего, потому что включен двухсторонний режим отображения, а игровой движок для оптимизации работает по умолчанию в одностороннем режиме отображения - рисует только те грани, нормали которых направлены в камеру. Лечится исправлением нормалей поверхности. Или можно перевести движок на двухстороннее отображение, но это удваивает нагрузку.
Второе - автоматически сгенерированные коллизии плохо работают на сложных объектах. Лечится ручным созданием коллизий в 3д-редакторе или разбиением геометрии на более простые фрагменты или использованием коллизий по геометрии (дорого по ресурсам и работает только для статичных объектов).
P.S. а вобще, рекомендую подтянуть английский и заглянуть в документацию - там все это есть и даже больше.
Эльрат, когда мне в руки попадут первые серии - скажу конкретно, по факту, а раньше не вижу смысла сотрясать воздух прогнозами, подкрепленными исключительно не систематизированной информацией из сети да личным мнением.
Nerevar, ну я то исходил из принципа минимальных изменений в существующие механики. Мне намного интересней, заткнута ли тут классическая дырка, позволяющая активировать такие эффекты с произвольной частотой, независимо от скорости атаки.
Nerevar, не смеши, варик и математика, да еще и основы теории вероятности - вещи не совместимые, за оооочень редким исключением.
Тут лучше подойдет куда более простая в понимании и реализации костыльная накопительная система - каждый неудачный удар добавляет к скрытому счетчику случайное число, обнуляя счетчик при достижении определенной суммы или срабатывании эффекта обычным способом - не нужно строить таблицы и считать размер константы и граничных значений, заморачиваясь точным подбором процента срабатывания, да и не нужна тут такая точность - достаточно гарантировать, что эффект сработает через разумное кол-во действий, которое нельзя при этом предсказать заранее.
Эльрат, заливал бы ты их на гуглодоки и давал ссылки - цены бы тебе не было - далеко не у всех стоит офисный софт на компьютере, не говоря уже о телефонах.
Нужно внимательнее читать правила. Все проекты, которые видны другим пользователям, проходят премодерацию - модератор должен утвердить вносимые изменения. Обычно это простая формальность и нужно просто дождаться модератора.
Ну, допустим, есть кейсы, при которых триггеры всё-таки нужны, те же следы от юнитов, евпочя =)
Есть, конечно. Кроме тех "следов", например, я часто делал триггерную вставку для рандомного разброса т.к. родной рандом из редактора данных никуда не годится - отслеживал срабатывание эффекта-пустышки триггерами, считал рандом и возвращал поток управления в данные, запустив следующий эффект триггерно с рандомным смещением (какой эффект запускать хранил в таблице данных, как и границы для рандома - чтобы один простой триггер мог обрабатывать все способности с рандомным разбросом). Но точка старта то всеравно в редакторе данных, даже если в триггеры вынесена вся логика, а в данных остается только пустышка, необходимая для отслеживания начала срабатывания способности.
yellyex, новые способности делаются через редактор данных, для этого не нужны триггеры. Раздел User Data 99% относится к одному из двух вариантов, которые я перечислил выше. К какому из двух - уже не помню, они довольно похоже называются, уточню как будет время.
Если я правильно помню что как называется, то UserData это способ привязать к юниту пользовательские данные. Использовать можно для чего угодно, что требует хранения дополнительной информации для конкретного юнита. Например, я когда-то использовал это для хранения таких данных, как пройденное юнитом расстояние, нанесенный им за все время жизни урон, количество входов-выходов в определенную зону и даже номер зоны, в которую юнит должен пытаться пройти.
Еще в редакторе данных есть таблицы пользовательских данных, их можно использовать для хранения каких-либо данных, но уже глобально, а не связанных с конкретным юнитом на карте. Например, я использовал их для хранения данных для всяких хитрых систем, совмещающих обычные и триггерные эффекты.
P.S. это все справедливо, если вы не ошиблись разделом и действительно спрашиваете про Starcraft 2.
А еще можно по рыться по записям стримов от разрабов UE - у них часто проскакивают моменты, связанные с тем, как они делали Paragon (и много чего еще). P.S. нельзя просто взять и запилить мобу - нужен сервер, на котором это будет работать, кастомный нетворкинг или хотябы своя прослойка над стандартным, алгоритмы матчмейкинга и куча других не самых простых вещей, не связанных напрямую с геймплейной частью. Я бы рекомендовал начинать с чего-то по проще, может даже синглплеерного - так шансы довести проект до логического завершения выше будут.
Или можно сразу начинать на Unreal Engine и постепенно переходить с блюпринтов на смесь блюпринтов и C++. Только вот пилить 2д игры в топовых 3д движках это дикий изврат, как по мне. P.S. без чего точно будет сложно с любым движком, так это без английского языка - качество существующих переводов, как правило, оставляет желать лучшего.
99% что где-то накосячил или что-то не так понял. Пробный запуск из редактора сильно отличается от запуска через батлнет, когда доходит до многопользовательской игры, так что использовать его есть смысл только для тестирования механик, никак не зависящих от мультиплеера, а все мультиплеерное тестировать только в батлнете. Вернее, тестировать то можно, а вот доверять результатам не стоит ;) карту посмотреть пока не смогу
Jusper, раньше арт тулзы давали конвертировать только в одну сторону и там было всего несколько моделей в открытом формате в качестве примера.
Что касается распаковки моделей из m3 - для этого я в последний раз использовал блендер и соответствующий плагин. Подробнее не скажу - давно было. Остальные конвертеры не поддерживали на тот момент новую версию формата.
Стоять! Перенеси все, что связано с кинематиками из инициализации карты в таймер на 0 секунд от старта игры. Событие инициализации срабатывает чуть раньше, чем реально начинается игра, так что его не стоит пытаться использовать для работы с кинематиками.
Нужно больше минералов подробностей - где, когда, какой код, работало ли раньше и так далее. По самой ошибке можно сказать только, что что-то внутри пытается дернуть функцию, доступную только близам в их собственных картах (и то, я могу ошибаться т.к. уже все забыл).
yellyex, ну, я не говорил, что это нельзя сделать без триггеров, просто на больших счетчиках потом начинаются проблемы, если делать их через данные. Особенно, если это должно работать на большом кол-ве юнитов.
Для начала, рекомендую убедиться, что возможно отследить срабатывание уклонения и что само уклонение работает как задумано. А уже после этого пытаться добавлять счетчики.
P.S. а счетчик я бы рекомендовал делать все-же триггерами и хранить в кастомных данных юнита т.к. хранить большие счетчики в доступном редактору данных виде получается очень ресурсоемко и не очень удобно.
я бы реализовал эту систему примерно так: - в таблице пользовательских данных лежит кол-во опыта которое нужно набрать и ссылки на соответствующие алгоритмы - при старте карты триггер переносит данные из таблицы в массив, чтобы ускорить доступ к ним в будущем - срабатывание уклонения вызывает соответствующий триггер (через эффект-пустышку или напрямую, если это вобще возможно - никогда не пытался отследить уклонение) - триггер, независимо от уровня уклонения, увеличивает опыт на 1 и сохраняет его в юзердату юнита - в юзердате же хранится и текущий уровень уклонения (можно и без этого, но тогда надо будет каждый раз перебирать весь массив пока не найдется соответствующая текущему уровню строка) - дальше идет проверка - если опыта больше, чем надо для перехода на следующий уровень, то удаляем один алгоритм и добавляем другой, естественно с обновлением значений в юзердате (нужные значения для опыта и алгоритмов достаем из массива, используя текущий уровень уклонения, полученный из юзердаты)
» StarCraft 2 / Как закончить проигрывание саундтрека?
В худшем случае всегда можно сделать wait на длительность трека.
» StarCraft 2 / Версия игры; Galaxy Editor; Стоимость.
Ред. prog
» Unreal Engine / Повреждения при столкновении с обьектами
» Unreal Engine / Проблемы с контентом.
» Аниме / Обсуждение аниме и манги
» Аниме / Обсуждение аниме и манги
» Зомби в Деревне (Remake) / Зомби в Деревне (Remake)
Ред. prog
» Зомби в Деревне (Remake) / Зомби в Деревне (Remake)
» В гостях у Эльрата / Re:Zero
Ред. prog
» Администрация XGM / Че за баги с проектом?
» StarCraft 2 / User Data
» StarCraft 2 / User Data
» StarCraft 2 / User Data
» Unreal Engine / MOBA в Unreal Engine 4?
P.S. нельзя просто взять и запилить мобу - нужен сервер, на котором это будет работать, кастомный нетворкинг или хотябы своя прослойка над стандартным, алгоритмы матчмейкинга и куча других не самых простых вещей, не связанных напрямую с геймплейной частью. Я бы рекомендовал начинать с чего-то по проще, может даже синглплеерного - так шансы довести проект до логического завершения выше будут.
» Блог им. Diabfall / Разработка планетарной инди-игры с нуля
Ред. prog
» Блог им. Diabfall / Разработка планетарной инди-игры с нуля
P.S. без чего точно будет сложно с любым движком, так это без английского языка - качество существующих переводов, как правило, оставляет желать лучшего.
» StarCraft 2 / Баг или мой недочет?
карту посмотреть пока не смогу
Ред. prog
» Unity / Перетащить модели, анимации и текстуры из SC2 в Unity
» StarCraft 2 / Ошибка при использовании Cinematic Mode
» StarCraft 2 / Ошибка при использовании Cinematic Mode
» StarCraft 2 / Ошибка при использовании Cinematic Mode
минераловподробностей - где, когда, какой код, работало ли раньше и так далее. По самой ошибке можно сказать только, что что-то внутри пытается дернуть функцию, доступную только близам в их собственных картах (и то, я могу ошибаться т.к. уже все забыл).» StarCraft 2 / Сделать счётчик
Ред. prog
» StarCraft 2 / Сделать счётчик
- в таблице пользовательских данных лежит кол-во опыта которое нужно набрать и ссылки на соответствующие алгоритмы
- при старте карты триггер переносит данные из таблицы в массив, чтобы ускорить доступ к ним в будущем
- срабатывание уклонения вызывает соответствующий триггер (через эффект-пустышку или напрямую, если это вобще возможно - никогда не пытался отследить уклонение)
- триггер, независимо от уровня уклонения, увеличивает опыт на 1 и сохраняет его в юзердату юнита
- в юзердате же хранится и текущий уровень уклонения (можно и без этого, но тогда надо будет каждый раз перебирать весь массив пока не найдется соответствующая текущему уровню строка)
- дальше идет проверка - если опыта больше, чем надо для перехода на следующий уровень, то удаляем один алгоритм и добавляем другой, естественно с обновлением значений в юзердате (нужные значения для опыта и алгоритмов достаем из массива, используя текущий уровень уклонения, полученный из юзердаты)
» StarCraft 2 / Нужна помощь!!! Вопрос насчет анимации.