В ск2 способности это одно, а кнопки, к которым привязаны способности - другое. Скорее всего, чего-то одного нет на месте или сбились связи между ними.
Триггеры плюс работа с UI. Кажется в кампании зергов что-то такое использовалось, если не ошибаюсь - можно расковырять и посмотреть.
KorvinGump, все файлы выложены от имени близов - и тот пак ассетов, что включен в клиент PTR и тот пак данных, что лежит отдельным модом. Я не исключаю возможности, что так все и было, просто уточняю нюансы.
Maxsavin, к ним пока нет ссылок в разделе моделей, не говоря уже о юнитах, но в файлах они есть.
алгоритм:
поставить обычную версию клиента, запустить клиент, авторизироваться, закрыть клиент
поставить PTR версию клиента, переключиться на неё
запустить игру, если активны сервера авторизации PTR - авторизироваться, если нет - запустить оффлайн режим
закрыть игру, открыть редактор версии PTR (в последующие запуски можно начинать сразу с этого пункта)
создать карту, подключить в зависимости арт-мод с соответствующим названием
открыть редаткор катсцен, перейти на вкладку файлов (по умолчанию открыта вкладка моделей, она нам не подходит)
обрезать поиском по ключу "war3"
теперь можно сколько угодно рассматривать модели в редаткоре катсцен
чтобы использовать модели в игре нужны дополнительные шаги (если повезет, то часть этой работы сделают близы)
каждой модели нужно создать соответствующую обвязку в разделе моделей в редакторе данных
создать юнитов и способности, которые будут использовать эти модели
создать для юнитов, способностей и прочих объектов необходимых актеров/агентов которые и отвечают за показ графики, воспроизведение звуков и тому подобное
alexprey, не совсем так - элементы иерархии эффектов можно и напрямую дергать, а можно и в очереди ложить и что угодно с ними делать, речь именно о вынесении реализации взаимодействий в отдельную иерархию, а реализация взаимодействия между иерархиями это уже отдельный вопрос.
А вот специфические взаимодействия реализуются внутри игровых объектов, например у меня червь может пугать мелкую живность - это реализовано публичным методом Scare() у класса Creature. Червь берёт у игрового движка список объектов в некотором радиусе и каждого "пугает" запуском obj->Scare(this), дальше существо в реализации метода само решает, испугаться ему или нет. Или, например, EMP-пушка обездвиживает на некоторое время механизмы - проще у абстрактного класса MechanicalUnit реализовать метод Paralize(time) и дёргать его напрямую, чем проталкивать OnParalaze() от корневого Object'а - живым юнитам от этого мусора никакой пользы. Если конечно нет парализующих ядов - тогда парализация становится типовым взаимодействием. По здравому смыслу, короче.
А вот тут я сторонник более сложного в реализации, но более гибкого подхода. А именно - взаимодействия делать не напрямую, а через цепочку эффектов. Объясню на твоем-же примере с червями:
червь время от времени генерирует эффект "ScareThemAll", относящегося к семейству действующих по области эффектов
эффект "ScareThemAll" берет список объектов в радиусе и к каждому применяет эффект "ScareTarget"
эффект "ScareTarget" умеет только вызывать метод Scare для цели, что он и делает.
у эффекта есть поле "caster", в котором по всей цепочке объектов передается ссылка на первоначальный источник эффекта, в данном случае на червя, что позволяет в эффекте "ScareTarget" сделать obj->Scare(caster)
Причем "ScareThemAll" вполне может быть реализован не отдельным классом, а экземпляром класса AreaEffect с параметрами, в то время как для "ScareTarget" в текущей архитектуре нужен отдельный класс, наследуемый от "TargetEffect".
P.S. все имена и ситуации вымышлены, все совпадения с реальностью абсолютно случайны.
Kozinaka, если гнаться за производительностью и позволяет архитектура, то можно вобще параллельные списки/массивы использовать. Впрочем, архитектура позволяет далеко не всегда, особенно если логическому объекту может и не быть назначено графического объекта (объект полностью невидим или, например, его графика выгружена т.к. объект очень далеко от камеры, но просчитывать его еще нужно), а хуже всего когда у обьекта то есть вьюха, то нет её.
Kozinaka, более того, бывает достаточно создать не прямую ссылку от объекта логики к объекту отрисовки, а связать их, например, через какой-нибудь Map во внешнем менеджере. Это более ресурсоемкий вариант, зато позволяет полностью абстрагировать логику от представления.
У меня, например, объекты сами себя рисовать не умеют. За них это делает жирный клас отрисовщика, который их сортирует, группирует, солит по вкусу и только потом рисует.
Жирный плюс за разделение логики объекта и его отображения.
koloff, к сожалению, пока быстро посмотреть можно только в редакторе сцен - данных по юнитам в наличии нет и нужно их самому создавать, а это не быстрый процесс. Насколько я помню, близы собираются добавить и данные в минимальном объеме (без способностей), а не только ассеты, но пока на ПТР есть только голые модели, ни к чему не прикрученные.
пара минут в редакторе сцен
те-же тапки, только сбоку - игровая камера
P.S. этому обсуждению место в отдельном ресурсе, а не здесь.
ARCHIMONDE, не совсем так - часть декораций и некоторые юниты кроме демонов тоже былы переделаны в HD, плюс многие текстуры были то ли перерисованы, то ли они изначально были в качестве по лучше, а для вара сжимались. Сужу по тому, что сам увидел в версии для PTR, хотя, к сожалению, удалось всего пару часов на это выкроить. Еще один очень важный нюанс - конвертированы и местами перерисованы все или почти все визуальные эффекты от способностей (не могу сказать все ли т.к. банально не хватило времени перебрать).
С другой стороны многие модели так и тянет разобрать и малость подрихтовать, в основном это касается анимаций и точек крепления - то анимаций не хватает до стандартов ск2 и надо разделить одну анимацию на две, то отсутствуют стандартные для ск2 крепления. Впрочем, все это можно пережить.
sleep, по моим сведениям тулза ставится и на пиратку ск2, хотя лично я этого не пробовал делать.
Кстати, у тулзы есть и свои недостатки в сравнении с любительскими плагами - она не умеет разбирать m3 до состояния исходников и плохо переносит сосуществование со сторонними импортерами - нужно либо ставить две копии макса, либо включать-выключать плаги постоянно (вроде есть еще грязный хак к одному из плагов, позволяющий заставить их работать вместе, но я так и не начал с этим разбираться).
Melissa, скажи еще что там хватит вариаций чтобы сделать полноценное отображение инвентаря в режиме крафта при произвольном кол-ве возможных предметов в карте и произвольном их расположении в сетке.
Melissa, вот только менять эту модель в полете не особо получится, в то время как автор хочет вовсе не инвентарь экстерминировать, а сделать систему крафта, просто слова плохо подбирает.
Grok,
FSGUI - использование специальных декораций со сменными текстурами и зон реакции на мышку (не помню уже как они называются) в совокупности с фиксированной камерой для создания полноэкранного меню с произвольным содержимым (открытие такого меню перемещает камеру в специальную локацию, что не всегда удобно т.к. не видно персонажа и им толком нельзя управлять), в том числе так делали инвентари, системы крафта, деревья навыков и много чего другого.
DGUI - развитие идеи FSGUI, только вместо декораций используются юниты со специальной моделью в совокупности с камерой, положение которой полностью управляется из кода - так можно создать иллюзию окон и кнопок прямо на месте, не перемещая камеру в специальную локацию и тем более не мешая управлению персонажем. Учитывая особенности реализации, должно быть понятно, что это работает только с видимой областью, где могут отображаться юниты и совершенно не пригодно для манипуляций с панелью.
vincent_freeman, советую для начала разобраться с редактором старкрафта, а потом уже заявлять о невозможности добавить свои расы. Заодно объем работы оценить можно, который нужно для этого проделать.
vincent_freeman, уточняю, я не в команде, а просто немного осведомлен о политике партии. Сейчас - только то, что было в варе: шаг вправо, шаг влево - расстрел. А вот после релиза мода, кто знает, может и будет у них желание что-то свое сделать.
Inflexible, выглядит он и правда интересно, но не дает нужного мне результата - визуального выделения поверхностей. Это сейчас в фоне просто синий цвет, а в перспективе там скорее всего будет картинка в параллаксе и очень неприятно будет когда игроки будут путаться где земля, а где фоновая картинка.
Кроме того все эти эффекты вовсе не потеряны - их в любой момент можно будет задействовать где-нибудь еще, не говоря уже о том, что это очень ранняя промежуточная версия постобработки, а не окончательный вариант.
Ред. prog
» Эксперименты в Пустоте / Немного безумия
Ред. prog
» StarCraft 2 / Герой-овощ и таймер воскрешения
» StarCraft 2 / Герой-овощ и таймер воскрешения
» StarCraft 2 / Blizzard выпустят свой контент-пак на тему WC3
Ред. prog
» StarCraft 2 / Blizzard выпустят свой контент-пак на тему WC3
» Бродилка / [Лог #7] Класс рисовальщика.
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» WarCraft: Armies Of Azeroth / Нас заметили Blizzard Entertainment
Ред. prog
» WarCraft: Armies Of Azeroth / Нас заметили Blizzard Entertainment
» Блог sleep`a / Труповозка для StarCraft 2
Кстати, у тулзы есть и свои недостатки в сравнении с любительскими плагами - она не умеет разбирать m3 до состояния исходников и плохо переносит сосуществование со сторонними импортерами - нужно либо ставить две копии макса, либо включать-выключать плаги постоянно (вроде есть еще грязный хак к одному из плагов, позволяющий заставить их работать вместе, но я так и не начал с этим разбираться).
» Блог sleep`a / Труповозка для StarCraft 2
» WarCraft: Armies Of Azeroth / WarCraft: Armies Of Azeroth
» Блог sleep`a / Труповозка для StarCraft 2
» WarCraft 3 / Нестондартное использование текстур в варкрафте
» WarCraft 3 / Нестондартное использование текстур в варкрафте
Ред. prog
» WarCraft 3 / Нестондартное использование текстур в варкрафте
FSGUI - использование специальных декораций со сменными текстурами и зон реакции на мышку (не помню уже как они называются) в совокупности с фиксированной камерой для создания полноэкранного меню с произвольным содержимым (открытие такого меню перемещает камеру в специальную локацию, что не всегда удобно т.к. не видно персонажа и им толком нельзя управлять), в том числе так делали инвентари, системы крафта, деревья навыков и много чего другого.
DGUI - развитие идеи FSGUI, только вместо декораций используются юниты со специальной моделью в совокупности с камерой, положение которой полностью управляется из кода - так можно создать иллюзию окон и кнопок прямо на месте, не перемещая камеру в специальную локацию и тем более не мешая управлению персонажем. Учитывая особенности реализации, должно быть понятно, что это работает только с видимой областью, где могут отображаться юниты и совершенно не пригодно для манипуляций с панелью.
» WarCraft 3 / Нестондартное использование текстур в варкрафте
» WarCraft: Armies Of Azeroth / WarCraft: Armies Of Azeroth
Ред. prog
» WarCraft: Armies Of Azeroth / WarCraft: Armies Of Azeroth
» WarCraft: Armies Of Azeroth / WarCraft: Armies Of Azeroth
» Requested Eternity / Внезапная постобработка