Список изменений в StarCraft II 4.13.0 для PTR

ИЗМЕНЕНИЯ РЕДАКТОРА

Мы рады анонсировать крупное обновление для редактора карт StarCraft II!

Еще со времен Wings of Liberty в ваших отзывах часто звучала просьба повысить удобство редактора. В этом обновлении мы пойдем навстречу этой просьбе, при этом сохранив всю глубину возможностей инструментария. С этой целью мы позаимствовали часть элементов из редактора Warcraft III, оставив все существующие функции редактора StarCraft II. Мы также дополнительно расширили возможности редактора SCII.

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

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

Наборы данных (Data Collection)

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

  

• Например, вы можете попробовать скопировать набор Blizzard и дать новому набору данных название Activision Blizzard.
• При удалении набора данных будут удалены все записи данных в этом наборе.
• При изменении идентификатора набора данных будут изменены идентификаторы всех записей данных в этом наборе.
• В набор данных можно добавлять записи данных как вручную, так и автоматически.
• В названиях дочерних записей данных в наборах используется новый ключевой символ @. Система наборов данных может автоматически провести поиск по всему каталогу и найти любую запись данных, чей идентификатор начинается с идентификатора набора данных с идущим после него символом @. Затем эти записи будут автоматически добавлены в набор.
• Благодаря этим взаимосвязанным функциям при любом изменении в структуре эффектов какой-либо способности соответствующий набор данных и находящиеся в нем записи данных будут обновлены автоматически.
• Ниже приведен пример данных в заполненном автоматически наборе данных:

  

  • Данные, не обладающие типовыми названиями, не будут добавляться в набор автоматически, но вы все равно сможете добавить их вручную.
• Меню: Набор данных (Data Collection) -> Автозаполнение набора данных (Auto Fill Data Collection) — эта функция проведет автоматический поиск по всему каталогу и выберет записи данных, идентификатор которых начинается с идентификатора набора с добавленным символом @. Затем она автоматически добавит эти записи в соответствующий набор.
• Меню: Набор данных (Data Collection) -> Автоматически именовать набор данных (Auto Name Data Collection) — эта функция автоматически изменит наименования записей данных в наборе, чтобы они соответствовали названию этого набора.
• Наборы данных также позволяют нам добавить дополнительную информацию о взаимоотношениях записей данных. Например, благодаря наборам данных игра теперь может обрабатывать такую информацию, как основной агент боевой единицы.
• Множество других функций, добавленных в обновлении, тесно связаны с функцией наборов данных.
• Чтобы раскрыть весь потенциал наборов данных, потребуется соблюдать определенные правила и основные принципы программирования:
  • Все наборы данных должны быть как можно более автономными.
  • Например, «набор способности» должен всегда функционировать вне зависимости от того, присвоили ли вы его какой-либо боевой единице, и никакая способность не должна быть запрограммирована таким образом, чтобы она работала строго с определенными боевыми единицами или с боевыми единицами с определенным оружием. В качестве предостережения приведем пример: в старой базе данных SC2 существовала пассивная способность излучателей Пустоты, которая увеличивала наносимый ими урон после того, как они атаковали в течение длительного времени. Этот пассивный эффект на самом деле был лишь для вида, а его функционал был задан строго для оружия самих излучателей Пустоты. Сейчас настало время наборов данных, и мы категорически осуждаем злоупотребление данными, вследствие чего многие из описанных ниже новых возможностей были созданы специально в соответствии с этим принципом.

Редактор данных «в упрощенном режиме»

• «Упрощенный режим» редактора данных — это дополнительная особенность наборов данных. Когда этот режим включен, редактор данных будет показывать и копировать наборы данных, словно они являются лишь единичными элементами «данных способности», «данных боевой единицы», «данных предмета», «данных улучшения» и т. д. Вы сможете копировать, убирать, удалять или переименовывать эти данные, будто они являются лишь единичным элементом данных.
• Этот режим доступен лишь в виде «Отобразить в виде таблицы». Он объединяет в себе все самые важные поля данных, такие как данные о запасе здоровья боевых единиц или об уроне способностей.
• Поля, которые отображаются в «Упрощенном режиме», можно полностью настраивать для любого типа наборов данных.
• Большим недостатком редактора карт SC2, согласно отзывам пользователей, является то, что процесс копирования боевых единиц или способностей слишком сложен. В этом отношении редактор War3 значительно превосходит редактор SC2.
  • Нашим ответом на данный вопрос послужат наборы данных в тандеме с «Упрощенным режимом».
  • В будущем мы хотели бы создавать больше данных, основанных на наборах данных, чтобы упростить взаимодействие пользователей с ними.
• Мы призываем всех авторов модификаций создавать свои творения при помощи наборов данных, используя все их преимущества. Мы также призываем всех, кто создает модификации с общим доступом, настроить для них «Упрощенный режим», чтобы другие создатели модификаций могли с легкостью изменять и редактировать эти модификации.

Аккумуляторы (Accumulators)

• Аккумуляторы — это новая функция, которая позволяет создателям карт создавать формулы, основанные на различных параметрах ввода.
• В качестве параметров аккумуляторы могут брать пользовательские данные и модифицированные пользователем значения боевых единиц.
• Аккумуляторы поддерживают работу не только с формулами, но и с указанными пользователем таблицами. В комбинации с валидаторами аккумуляторы также могут предоставлять функционал для смены случаев.
• Например, при использовании аккумулятора для алгоритма, у которого могут быть различные уровни и который может использоваться несколькими игроками, аккумулятор будет рассчитывать результат для каждого игрока в отдельности.
• Благодаря своей универсальности аккумуляторы могут использоваться во множестве различных ситуаций. Например, для расчета урона, скорости исцеления, восстановления здоровья, уменьшения урона, стоимости способностей, дополнительной брони, количества пакетов агентов, количества постоянных объектов, количества алгоритмов, длительности алгоритмов, долей урона, скорости атаки, скорости передвижения, восстановления базовых показателей, шанс срабатывания алгоритма, изменения базовых показателей и т. д.
• Новый токен для обработки строковых значений: $AccumulatedValue:xxx$
  • Этот токен можно использовать для расчета показателя AccumulatedValue в пользовательском интерфейсе, например:
    • Обрушивает на целевую область «d ref="$AccumulatedValue:Effect,JainaBlizzardPersistent,PeriodCount$"/>» волн из ледяных осколков. Каждая волна наносит урон находящимся в области боевым единицам.

Реакция на уровне игрока

• «Реакция на игрока» (Player Response) — это новый каталог данных, позволяющий пользователям определять образцы реакций, когда какое-либо событие происходит с соответствующим игроком. Разработчики могут использовать триггеры, чтобы привязать образцы реакций к определенным игрокам, и боевые единицы этих игроков будут реагировать на зарегистрированные события по аналогии с алгоритмами реакции на урон.
• У пользователей есть возможность настроить приоритеты и методы передачи для реакций игрока.
• Реакции на уровне игрока избавляют вас от необходимости назначать определенные алгоритмы всем единицам при создании командиров, что значительно улучшает производительность игры. Кроме того, поскольку вам нужно назначать реакции только для исполняющих их командиров, игре больше не требуется каждый раз обрабатывать данные предотвращения смерти для всех командиров.
• Реакции на игрока больше не ограничены условием «Боевая единица получила урон» (Unit is Damaged), как алгоритмы реакции на урон. Например, можно создавать реакции на появление игрока, появление боевой единицы, гибель боевой единицы игрока и т. д.

Объединенный индикатор состояния

• С помощью действия триггера «Интерфейс - Перезапись опции игрока» (UI - Override Player Option) создатели карт теперь смогут изменить стиль индикаторов состояния по умолчанию и сделать их цельными и более линейными. Эта настройка может пригодиться для пользовательских модификаций, которым требуется более точная демонстрация долей основных показателей.

Обновленные данные пакета War3 Asset Mod

• В феврале 2015 г. мы выпустили пакет War3 Asset Mod. Хотя в этот пакет входили только ресурсы, многие создатели модификаций хотели научиться создавать в редакторе SC2 способности в стиле ролевых игр и War3. В этом обновлении введено множество изменений редактора, в связи с чем мы хотели бы представить создателям модификаций несколько примеров того, как можно воспользоваться новыми возможностями.
• В сотрудничестве с автором пользовательской модификации Renee's Warcraft III Mod мы воссоздали его модификацию при помощи всех новых функций редактора.
• Теперь в официальный комплект War3 Asset Mod включен целый набор рабочих данных, в которые входят расы, боевые единицы, строения и способности. Надеемся, что эти примеры помогут создателям модификаций войти в курс дела.

Передвижение строем (Formation Movement)

• Теперь в StarCraft II поддерживается передвижение с сохранением строя. Эта настройка может быть включена или отключена для каждого игрока с помощью триггеров.
• Боевые единицы могут передвигаться и атаковать в квадратной формации с заранее заданным разделяющим расстоянием.
• В настоящий момент передвижение в такой формации не заставит всех боевых единиц в ней передвигаться с одинаковой скоростью, в отличие от версии этой функции в War3.
• Создатели модификаций могут изменить эти данные, чтобы подстраивать алгоритмы под нужные ситуации.

Движение по воде (Water Pathing)

• Теперь StarCraft II поддерживает определение маршрутов при движении по воде!
• Новые типы проходимости: мелководье (Shallow Water) и глубокая вода (Deep Water).
• Новые методы перемещения по поверхностям: плавание (Float) и земноводный метод (Amphibious).
• Наземные боевые единицы (Ground) могут перемещаться по наземным (Ground) и мелководным (Shallow Water) клеткам.
• Плавающие боевые единицы (Float) могут перемещаться по мелководным (Shallow Water) и глубоководным (Deep Water) клеткам.
• Земноводные боевые единицы (Amphibious) могут перемещаться пo наземным (Ground), мелководным (Shallow Water) и глубоководным (Deep Water) клеткам.
• Летающие боевые единицы (Flying)могут отправиться в любую точку, где нет препятствий для передвижения воздушных войск.
• В настоящий момент новые типы проходимости можно разместить с помощью специальной кисти, которая находится в редакторе поверхностей.

Множественные уровни уступов/высот

• Количество уровней уступов/высот, которое поддерживается в StarCraft II, увеличено с 3 до 15.

Переработка системы улучшений

• Это изменение — одна из составляющих системы наборов данных и новой системы командиров.
• Старая система улучшений не была автономной, что в значительной мере противоречило нашей новой концепции наборов данных. В старой системе улучшения определяли то, какие боевые единицы или способности они затрагивают и каким образом.
• В новой системе улучшения станут гораздо более автономными. Теперь не улучшения определяют, на какие боевые единицы они будут действовать, а боевые единицы объявляют, какие они используют улучшения. Например, улучшения теперь вводятся не в стиле «Увеличивает запас здоровья морпехов на 10», а «Увеличивает запас здоровья всех боевых единиц, на которые распространяется это улучшение, на 10».
• Новое поле CUpgrade: EffectArrayTemplate
  • Это поле аналогично уже существующему полю EffectArray, но со следующими исключениями:
    • Оно поддерживает использование двух дополнительных токенов:
      • ^ParamId^: идентификатор любого набора данных, который использует заданное улучшение.
      • ^ParamLevel^: текущий уровень улучшения.
    • Это поле поддерживает ссылки на данные и арифметические операции. При помощи скобок, а также символов «{» и «}» вы можете создавать формулы, как в редакторе текста.
    • Наборы данных сами по себе уже поддерживают однотипные наименования элементов данных, поэтому для создателей модификаций будет удобно использовать токен ^ParamId^ при работе с записями данных, связанными с использующими их боевыми единицами.
    • Например:
      • EffectArrayTemplate Reference="Effect,^ParamId^@Weapon,Amount" Value="{DataCollection,^ParamId^,UpgradeInfoWeapon.DamagePerLevel+3}"/
      • Это улучшение увеличит урон от оружия боевой единицы, к которой оно применяется, на показатель, равный значению поля UpgradeInfoWeapon.DamagePerLevel в наборе данных этой боевой единицы + 3.
      • В столбец значения вы можете задать фиксированное число, например, Value=”4”.
• Старые поля в настройках CUpgrade все еще существуют, и их функциональность осталась без изменений, поэтому все старые улучшения продолжат работать. Вы сможете и дальше создавать улучшения с помощью старого метода, однако это не рекомендуется.
• Поддержка улучшений для всех боевых единиц
  • Поскольку некоторые улучшения созданы для того, чтобы действовать на «все боевые единицы» (определенного типа), в настройках CUpgrade теперь есть флаг, который включает подсчет всех наборов данных.
  • Были также добавлены два поля фильтров, EnumExcludedUserFlags и EnumRequiredUserFlags, с помощью которых можно отфильтровывать улучшения из всех наборов данных в зависимости от их флагов.
• Новые операции улучшений: AddBaseMultiply и SubtractBaseMultiply
  • Эти операции позволяют изменять целевое поле в зависимости от его значения по умолчанию, а не текущего значения, что зачастую бывает более полезно, чем операция умножения. Например, если вы создали улучшение «Увеличить запас здоровья боевых единиц на 10%» со 100 уровнями, то, скорее всего, вы хотели, чтобы оно увеличивало запас здоровья на фиксированное число за каждый уровень улучшения, а не перемножалось каждый раз с предыдущим уровнем улучшения. Кроме того, операции Add/SubtractBaseMultiply поддерживают понижение уровня технологий, потому что они могут в любое время быть отменены, в отличие от операции умножения.
• Теперь можно создавать улучшения, которые будут добавлять или отключать боевые единицы для игроков.
• Новое поле CWeapon: «Коэффициент степени» (Rate Multiplier)
  • Значение по умолчанию равняется 1.
  • Этот коэффициент будет учитываться игрой во время определения интервала между атаками для оружия или эффекта CP.
  • Это изменение позволит вам улучшать скорость атаки оружия на выраженный в процентах коэффициент вместо того, чтобы напрямую изменять интервал между атаками.

Система сфер (а также выстрела залпом и критического удара)

• Сферы — это модификаторы атаки, которые являются важным элементом игр в жанре MOBA.
• Система реакции на урон в StarCraft II поддерживает создание сфер, но реакции на урон и модификаторы атаки на самом деле существенно различаются.
• Большинство из старых использующих сферы способностей в SC2 не соответствуют общепринятому определению функциональности сфер, поскольку они встроены в само оружие, вследствие чего их нельзя просто добавлять или убирать при работе с произвольным оружием. Поэтому если вам нужно было создать предмет-сферу, то встраивать эффекты этого предмета во все виды оружия героев в игре было бы слишком трудоемкой задачей.
• Обновленная система сфер представляет собой расширенную версию общей концепции сфер из игр в жанре MOBA, а также включает в себя официальную поддержку механики выстрела залпом (Multishot) и критических ударов (Critical Strike).
• Настоящая система сфер должна иметь следующие функции:
  • Возможность при работе с системами оружия применять свои эффекты к каждой атаке в отдельности.
  • Возможность изменять снаряды.
  • Возможность добавлять особые эффекты при воздействии оружия на цель, например, урон от огня, от холода, применение алгоритма и т. д. Должна обладать возможностью накладывать особые эффекты как до воздействия, так и после.
    • Например, для способности «Темная стрела» требуется, чтобы сфера наложила на цель отрицательный эффект, который срабатывает (создает скелета), когда цель погибает. Если система сфер способна применять особые эффекты только после воздействия, то боевая единица может быть убита этой способностью, вследствие чего скелет не появится.
    • Другой пример: способность с эффектом сферы «Картечь». Эта способность наносит урон по области, зависящий от основного урона от атаки боевой единицы, вследствие чего дополнительный урон по области должен применяться после воздействия на цель, так как для его расчета необходимо сначала рассчитать основной урон с учетом разброса.
  • Модификатор атаки от сферы должен учитываться уже в момент начала анимации атаки, даже до того, как будет произведен сам эффект атаки. Благодаря этой функции боевые единицы могут использовать особую анимацию атаки, например, для критических ударов.
  • У сфер должна быть возможность стабильно наносить дополнительный урон при атаках.
  • У сфер должна быть возможность проверять свои эффекты, например, чтобы способности «Сильный удар» и «Критический удар» не срабатывали против дружественных целей.
• Новый флаг эффекта: MainImpact
  • Этим флагом отмечается базовый эффект в структуре эффектов при воздействии оружия на цель, что позволяет модификаторам атаки правильно рассчитывать время срабатывания своих эффектов.
• Новый тип алгоритма: CBehaviorAttackModifier
  • При применении этого алгоритма модификаторы сработают, когда оружие начинает действовать. Он будет зарегистрирован во всей структуре эффектов атаки.
  • Поле «Вероятность» (Chance) определяет вероятность срабатывания модификатора атаки. Эта вероятность рассчитывается для каждой атаки в отдельности.
  • Каждой боевой единице может быть назначено несколько модификаторов. Поле «Уникальный идентификатор» (Unique Id) позволяет пользователю определить, могут ли все эффекты сфер срабатывать одновременно. В War3 мог срабатывать только один эффект сферы, даже если герой использовал несколько сфер одновременно. Тем не менее, создателям модификаций наверняка пригодится возможность позволить всем сферам срабатывать одновременно.
  • Поле «Максимальное суммирование» (Stack Max) определяет количество раз, которое могут суммироваться прибавки к урону.
  • Поля «Дополнительный урон» (Damage Bonus) определяют, есть ли постоянные или зависящие от переменных прибавки. Эти поля также поддерживают использование аккумуляторов.
  • Поля «Валидатор» (Validator) определяют, могут ли модификаторы срабатывать при атаке определенных целей. Например, если вы атакуете свои собственные боевые единицы, то вряд ли вам хотелось бы увидеть срабатывание критического удара.
  • Поле PreImpactEffect определяет срабатывание эффекта до воздействия атаки на цель.
  • Поле DamageInheritEffect определяет срабатывание эффекта после воздействия на цель и наследует урон при поражении для использования в структуре данного эффекта. С помощью этих эффектов пользователи смогут создать эффект «Цепной молнии» или запрограммировать нанесение урона по области, опирающиеся на урон при воздействии на цель.
  • Существует возможность определить, не промахнулась ли атака. Обратите внимание на раздел системы промахов/отражений/блоков.
  • Флажок «Только визуальный эффект для иллюзий» (Hallucination Visual Only) позволяет создателям модификаций определить, вызовет ли модификатор атаки срабатывание эффекта сферы, если заклинатель является иллюзией. Для заклинателей-иллюзий вы, вероятнее всего, не хотели бы давать способность наносить урон по области или создавать скелетов из мертвых. Но некоторым создателям модификаций может пригодиться такая опция.
    • При использовании этого флага модификатор атаки будет по-прежнему накладываться на всю структуру атаки, поэтому боевая единица – заклинатель сможет использовать ложную анимацию критического удара и выпустить снаряд в измененном виде. Но эта атака не наложит истинный эффект сферы при воздействии.
  • Поля MultishotEffect и MultishotSearchPattern позволяют пользователям настроить эффект выстрела залпом для всех найденных по образцу целей, если поле «Вероятность» (Chance) возвращает истинное значение и требования всех валидаторов соблюдены. В случае, если поле MultishotEffect не имеет заданного значения, то эффектом выстрела залпом станет эффект использованного для атаки оружия по умолчанию.
  • Также есть возможность определить, могут ли эффекты при воздействии срабатывать на цели выстрела залпом.
  • Есть возможность включить оружие по его индексу: таким образом герой ближнего боя, использующий предмет-сферу, может атаковать воздушные цели своим скрытым оружием.
  • При применении модификатора к какой-либо атаке, значение модификатора подставляется в поле условия агента (WeaponModifier) для события WeaponStart. Таким образом система агентов может использовать различную анимацию атаки в зависимости от действующих в данный момент модификаторов атаки.
  • Есть возможность установить флажок IsCritical. Когда этот флажок установлен, атака может быть отмечена как «критическая», что в свою очередь вызовет срабатывание сообщения агента критической атаки, а в поля сообщений SetText и SetTextlocalized будут добавлены значения урона, благодаря чему создатели модификаций смогут использовать всплывающий текст для отображения критических ударов.
• Новый тип способности: CAbilAttackModifier
  • Тип CBehaviorAttackModifier может обрабатывать большинство случаев со способностями с эффектами сфер, но для некоторых способностей — например, для «Огненных стрел» жриц луны — заклинанию с эффектом сферы необходимо использовать командную оболочку для включения и отключения функции автоприменения.
  • CBehaviorAttackModifier — командная оболочка для CBehaviorAttackModifier, и с помощью этого типа можно добавить сфере командную оболочку для автоприменения / ручного применения.
  • Есть возможность добавить модификатору параметр стоимости, чтобы каждый раз при применении способности с эффектом сферы происходили затраты ресурсов или основных показателей.
  • Обладает свойством градации по уровням, так что его уровень можно повышать, когда герой разучивает новые способности.
• Новый тип агента: CActorActionOverride
  • С его помощью можно изменять модели снарядов, модели воздействия и модели урона для CActorAction.
  • Обладает полями «Модель урона» (Damage Model), «Модель воздействия» (Impact Model) и «Модель снаряда» (Missile Model), с помощью которых можно перезаписывать ссылки на модели.
  • При инициализации CActorAction будет произведен запуск события ActionInitModifier.
  • Агент типа CActorActionOverride может захватить это событие и создать самого себя в наборе CActorAction, а затем при помощи ActionOverrideApplyTo применить самого себя к агентам типа CActorAction.
  • CActorAction получит данные от CActorActionOverride и с их помощью произведет перезапись моделей атаки.

Динамическая поддержка способностей

• Теперь создатели модификаций могут с помощью триггеров добавлять и убирать способности для боевых единиц.

Замена способностей

• Новая функция: UnitAbilityChangeLink()
  • С помощью этой функции пользователи могут передать существующую способность какой-либо боевой единицы другой боевой единице с сохранением всех ее показателей зарядов, времени восстановления и уровня.
  • Эта функция отличается от функции замены каталога тем, что она действует в единичных случаях для каждой способности в отдельности.
  • Мы также добавили новое поле «Замена способности» (Ability Replace) в типы алгоритмов потребителей энергии (Power User Type Behavior) — оно представляет эту функцию в виде данных.
  • Можно заменять только те способности, которые обладают аналогичным старой способности классом CAbil. Например, способность, применяемая на цель, может быть заменена только на другую способность, применяемую на цель.
  • Функция замены способностей в виде данных также может воздействовать на способности героев, которые можно выучить.

Передача ссылок на структуры в графическом интерфейсе триггеров

• Функции и действия триггеров теперь могут определять в качестве параметров данные типов записей.
• Переменные записей теперь могут с помощью ссылок передаваться функциям и действиям в качестве параметра.
• Записи в формате параметров можно считывать и изменять. Изменения также будут влиять на переменную записи и вне диапазона функции.

Новая API-функция для триггеров: «Копия таблицы данных» (Data Table Instance)

• Она работает аналогично таблицам данных, но у вас может быть несколько таких копий, данные которых вы сможете рассчитывать и копировать в другие таблицы.
• Раньше таблицы данных были единичными и глобальными. Теперь с помощью копий разработчикам будет проще организовывать данные времени выполнения.

Перезапись подсказок для предметов/способностей для каждой боевой единицы/предмета в отдельности

• Новые функции: UnitSetInfoButtonTooltip, UnitClearInfoButtonTooltip
• С помощью этих форматов можно производить перезапись подсказок для кнопок приказа.
• «Установленные» действия триггеров должны получить три параметра, к которым относятся: изменяемая боевая единица или предмет, ключ изменения и итоговый текст подсказки.
• Ключ модификации поддерживает три разных формата, что позволяет изменять подсказки для приказов тремя разными способами:
  • Перезапись подсказок для приказов с помощью функции AbilCmd.
    • Ключом модификации в таком случае послужат параметры AbilCmd, например, «Stimpack,0».
  • Перезапись подсказок для приказов по кнопке ссылки.
  • В таком случае ключом будет идентификатор кнопки, например, «Морпех» (Marine).
  • Перезапись подсказок для предметов в свойствах самой боевой единицы.
    • В таком случае вы можете использовать символ «@» в качестве ключа.
• Это работает, даже если панель приказов была перезаписана и показывает панели приказов других боевых единиц.

Поддержка направленных способностей

• Теперь StarCraft II поддерживает направленные способности!
• Новое поле флага эффекта запуска снаряда: SearchFlags
  • Новый флажок поиска эффекта запуска снаряда: DynamicSearchArea
    • Этот флажок позволяет проводить поиск направленной способности. Если он снят, то результатом будет обычный снаряд.
  • Новый флажок поиска эффекта запуска снаряда: ArriveOnSearchHit
    • Определяет, есть ли у снаряда направленной способности свойства «обозначает воздействие снаряда на цель» или «пробивает цели насквозь». Подробности — ниже.
• Новые поля в настройках эффекта запуска снаряда:
  • SearchHitArriveEffect
    • Действует только когда установлен флажок ArriveOnSearchHit. Этот эффект срабатывает, когда снаряд взрывается при поражении цели.
    • Внимание: этот эффект сработает в последней точке поиска перед исчезновением снаряда, а не в его целевой точке. По принципу действия этот эффект аналогичен завершающему эффекту.
  • SearchEffect
    • Снаряд будет просчитывать этот эффект в каждом игровом цикле, перезаписывая параметр высоты в области поиска в зависимости от текущей скорости снаряда. В сущности, это позволит избавиться от промежутков между каждой операцией поиска.
    • Внимание: при использовании кода TVE будет отображаться некорректное значение высоты вместо высоты согласно перезаписанному эффекту поиска.
  • SearchMaxCount
    • Отображает максимальное количество результатов поиска, полученных за все время полета снаряда, а не максимальное количество результатов каждой операции поиска в отдельности. Снаряд прекратит выполнять операции поиска после достижения количества целей, равняющегося переменной SearchMaxCount.
    • При достижении данного количества целей (определяемого SearchMaxCount) и снятом флаге ArriveOnSearchHit снаряд продолжит путь к целевой точке, но больше не будет выполнять операции поиска как направленная способность.
    • При достижении данного количества целей и установленном флаге ArriveOnSearchHit снаряд взорвется и выполнит операцию SearchHitArriveEffect в последней точке, где проводился поиск. Обратите внимание, что этот эффект не является целью снаряда, поскольку снаряд не достигнет целевой точки.
    • Если значение SearchMaxCount равняется 0 и флажок ArriveOnSearchHit установлен, то снаряд будет действовать без ограничений на максимальное количество результатов поиска. Если хотя бы один из его эффектов поиска найдет какую-либо цель, снаряд взорвется и выполнит операцию SearchHitArriveEffect в последней точке, где проводился поиск.

Улучшенная система героев

• Новый класс CUnit: CUnitHero
• У этого класса пять дополнительных полей (по сравнению с классом CUnit):
  • MainAttribute:
    • Единичная ссылка на алгоритм, которая автоматически применяется/отменяется при создании/трансформации боевой единицы.
    • Отличий от обычного поля алгоритма нет. Но при использовании этого поля как единичного его можно с легкостью прочитать с помощью функции каталога, чтобы определить основную характеристику героя.
  • MainAttributeDamageBonus
    • Это поле определяет прибавку к атаке, которую герой получает за каждую единицу значения MainAttribute.
  • AttributePointsInfoArray:
    • Определяет начальное количество очков характеристик героя и их количество, которое он получает при повышении уровня, с учетом текущего уровня героя. Это поле определяет только очки характеристик; самостоятельно оно не назначит герою алгоритм, связанный с характеристиками.
  • LearnInfoArray:
    • Это поле использует структуру, аналогичную CAbilLearn_LearnInfo. Если какой-либо из индексов задает ссылку на способность, то это поле перезапишет соответствующую информацию о способности заданного героя, доступной для изучения. Благодаря этому вам больше не придется создавать отдельные списки доступных для изучения способностей для разных героев.
    • Кнопка приказа «Информация» (Learn Info) может быть автоматически создана при установленном флаге «Создать кнопку по умолчанию» (Create Default Button).
  • TierRequirements
    • Это поле перезаписывает требование дерева технологий поля CAbilTrain, когда способность используется для обучения выбранного героя и в игре уже существует более одной технологии с наименованием данной боевой единицы (Tech Alias) у данного игрока.
• Новый флажок CAbilityRevive: «Перезапись значка оповещения» (Override Alert Icon)
  • Когда игрок воскрешает героя с помощью способности CAbilRevive и с установленным флагом «Перезапись значка оповещения», то способность выберет в качестве значка оповещения значок способности CAbilRevive, а не значок героя.
• Добавлены новые функции:
  • TechTreeSetProduceCap
  • TechTreeGetProduceCap
    • Триггеры могут вызывать эти функции, чтобы установить ограничение дерева технологий в зависимости от боевых единиц, улучшений, способностей, алгоритмов или эффектов.
    • Также их можно использовать для настройки ограничения на обучение героев.
• Основные очки характеристик (Base Attribute Points) и дополнительные очки характеристик (Bonus Attribute Points)
  • Алгоритмы характеристик у CHeroUnit теперь используют два разных значения для очков: основные и дополнительные.
  • Начальное количество очков характеристик героя и количество, которое он получает при повышении уровня (эти параметры задаются с помощью функции AttributePointsInfoArray), считаются основными показателями, в то время как остальные изменения очков характеристик (например, прибавки от алгоритмов) считаются дополнительными.
  • На панели информации о боевой единице основные очки характеристик будут отображаться белым числом, а дополнительные — зеленым (+X).
  • Бонусы, которые добавляются с помощью основных очков характеристик, больше не помечаются зелеными числами (+X). Вместо этого они добавляются к основным показателям полей урона/брони/скорости атаки.
  • Очки характеристик, добавленные с помощью положительных эффектов и предметов, будут по-прежнему отображаться числами зеленого цвета (+X).
  • Новые флаги CEffectApplyBehavior:
    • SetAttributePoints: когда этот флажок отмечен галочкой, выбранный эффект определит показатель очков характеристик для связанных с характеристиками алгоритмов.
    • SetAttributeBasePoints: когда этот флажок отмечен галочкой, он будет изменять основные очки характеристик, а не дополнительные.
• Добавлено новое поле CabilTrain: IgnoreUnitCostRequirements
  • Это поле позволяет способностям, связанным с обучением, игнорировать стоимость единиц при условии выполнения требований дерева технологий.
  • С его помощью можно вводить особые разновидности игровой механики, например, «первый герой бесплатный».
• Улучшения подменю изучения способностей
  • Новый флажок изучения способностей: ClearSubmenuOnPointsSpent
    • Когда этот флажок установлен, то использующая данную способность боевая единица автоматически закроет подменю панели приказов после того, как все ее очки навыков будут потрачены.
  • Новый флажок изучения способностей: HideSubmenuOnLearnedAll
    • Когда этот флажок установлен, кнопка выбора подменю изучения способностей перестает отображаться после того, как использующая способность боевая единица выучила все доступные ей способности.
  • Исправлена неполадка, в результате которой после траты всех очков способностей в подсказке кнопки изучения способности отображался красный текст «Требуемый уровень:» (Required Level:), даже если уровень боевой единицы соответствует требуемому значению.
  • Исправлена неполадка, в результате которой игроки иногда могли с помощью клавиши Shift игнорировать требования к уровню при изучении новых способностей.
• Добавлено новое требование для состояния количества боевых единиц: QueuedOrBetterOrRevivable
  • Если используется данное требование, при подсчете единиц технологии будут учитываться также доступные для воскрешения и находящиеся в процессе воскрешения герои.
  • Это полезно, если вы хотите добавить ограничения на обучение героев. Например, если вы добавили ограничение «Нельзя обучить более 3 героев», то для его соблюдения, скорее всего, следует учитывать не только живых героев.
• Формулы уровня героя и опыта
  • Новое поле в настройках CBehaviorVeterancy: «Уровни»
    • Устанавливает максимальный уровень для героя.
    • Это поле можно улучшать, благодаря чему создатели модификаций смогут изменять максимальные уровни способностей во время работы.
    • По умолчанию значение этого поля равняется 0. При таком значении система уровней по умолчанию будет действовать как раньше.
  • Новые поля в настройках CBehaviorVeterancy:
    • MinVeterancyXPBonusPerLevel
    • MinVeterancyXPPreviousValueFactor
    • MinVeterancyXPLevelFactor
    • Если размер массива VeterancyLevelArray меньше, чем значение поля «Уровни» (Levels), то игра автоматически создаст показатель «Минимального количества очков опыта» (min XP) дополнительных уровней, опираясь на данные факторы.
    • При этом используется следующая формула, где X означает уровень, а F(X) — минимальное количество очков опыта данного уровня:
      • F(X) = F(X-1) * MinVeterancyXPPreviousValueFactor + MinVeterancyXPLevelFactor * X + MinVeterancyXPBonusPerLevel
    • Эта формула используется, только если уровень X выше, чем размер массива VeterancyLevelArray. В противном случае будет просто использоваться показатель минимального количества очков опыта из таблицы VeterancyLevelArray.
• Доля получаемого опыта в зависимости от типа цели
  • Новое поле в настройках CBehaviorVeterancy: XPReceiveFraction
    • Это поле — структурный массив, благодаря которому можно назначить фильтр цели и настроить для каждого массива значение доли получаемого опыта.
    • Когда герой получает опыт, игра будет проверять побежденную боевую единицу с помощью фильтров цели и при соответствии какому-либо из них установит значение получаемого опыта равным назначенной доле.
    • Используя это поле вместе с аккумуляторами, пользователи смогут с легкостью создавать формулы получаемого опыта, такие как «За победу над призванными боевыми единицами можно получить только половину очков опыта» или «Герои получают меньше опыта за победу над нейтральными существами в зависимости от текущего уровня героя».
• Добавлен новый валидатор: CValidatorUnitCompareAbilSkillPoint
  • Он проверяет потраченные очки умений, неизрасходованные очки умений, дополнительные очки умений или суммарные очки умений боевой единицы.

Улучшения предметов и системы инвентаря

• В ролевых играх ключевую роль играют системы предметов, и мы рады представить вам расширение поддержки таких систем редактором.
• Поддержка предметов для постройки
  • Теперь можно использовать предметы в инвентаре боевой единицы для постройки зданий.
  • В настройках этой способности предметов можно установить необходимость поддерживания процесса постройки героем. Также игроки могут «вызывать» строения аналогично постройкам протоссов.
  • Такой тип предметов может пригодиться для создания дополнительных баз. Герой может купить «Карманную ратушу» и разместить ее на месте новой базы; после чего здание построится автоматически.
• Отображение инвентаря для других игроков
  • Новое свойство CInventoryPanel: ShowForAllPlayers
    • Когда это свойство включено, игроки смогут выбирать боевые единицы других игроков и видеть, что находится в их инвентаре. Но использовать эти предметы они не смогут.
• Применение способностей к предметам в инвентаре
  • В настройках CCommandButton теперь можно получить доступ к свойству ButtonOtherUnit. Теперь пользователи смогут при помощи свойства назначения придать предмету (самому предмету, а не тому, кто его держит) целевую рамку или какую-либо другую рамку.
  • Благодаря этой функции пользователи смогут применять способности к предмету, находящемуся в инвентаре, чтобы передать или улучшить его.
  • Также эта функция позволяет пользователям дважды щелкнуть на «Свиток возвращения» (Town Portal), чтобы автоматически телепортироваться к главному зданию базы самого высокого уровня.
• Глобальный доступ к панели инвентаря
  • Теперь пользователи могут перезаписать свойство «Единица инвентаря» в настройках CInventoryPanel, чтобы показывать инвентарь боевой единицы, которая в настоящий момент не выбрана.
  • Пользователи также смогут использовать триггеры для создания новых диалоговых окон управления инвентарем. Эта возможность поддерживает такие операторы, как диалоговые окна управления панелью приказов, добавленные в дополнении Legacy of the Void.
  • Пользователи могут назначить единицу с помощью опции Use SetDialogItemUnit. Если это поле не имеет значения, то по умолчанию будет назначена выбранная единица-лидер.
• Показывать инвентарь покупателя
  • Ранее в StarCraft II практически не поддерживались нейтральные продавцы предметов в стиле War3. До этого обновления при выборе магазина пользователи не могли видеть инвентарь боевой единицы – покупателя.
  • Теперь нейтральные магазины будут показывать инвентарь покупателя, если у самого магазина нет инвентаря и панель инвентаря не перезаписана с целью демонстрации инвентаря конкретной боевой единицы.
• Данные обмена в настройках CUnit
  • Боевым единицам и предметам добавлены особые данные, чтобы при продаже предметов и боевых единиц их данные наличия устанавливались на значения по умолчанию (такие данные, как начальное время восстановления в магазинах, максимальный запас предметов и т. д.)
  • Способность CAbilTrain может быть отмечена специальным флагом, в результате чего она будет игнорировать настройки по умолчанию и использовать пользовательские параметры, указанные в настройках самой способности.
    • Если флажок снят и у способности есть свои собственные данные, будут добавлены оба показателя данных обмена вместе.
• «Настоящие» усиливающие предметы
  • Новый тип предмета: CItemAbilPowerUp
  • Усиливающие предметы теперь можно добавить в виде настоящих предметов, и больше нет необходимости копировать боевые единицы.
  • Свойство CItemAbilPowerUp унаследовано от CItemAbil. Единственные различия заключаются в том, что усиливающий предмет будет применен автоматически при поднятии и что его можно поднять, даже если инвентарь боевой единицы полон.
  • Предметы CItemAbilPowerUp могут использовать только боевые единицы, у которых есть инвентарь. Для боевой единицы также должен быть установлен флажок CanUseItem.
  • Новые усиливающие предметы считаются настоящими предметами, поэтому на них распространяются события инвентаря и их можно использовать в системе добычи.
  • Свойство CItemAbilPowerUp проверяет, может ли заклинатель использовать усиливающую способность CItemAbilPowerUp. Если он не может использовать эту способность, появится сообщение об ошибке, и заклинатель не начнет двигаться к предмету.
  • Флажок KillAfterUse позволяет уничтожить предмет после того, как заклинатель использовал его усиление.
  • Обычная боевая единица, у которой есть инвентарь, но снят флажок CanUseItem, сможет поднять усиливающий предмет и отнести его герою.
• Новый флажок в настройках EAbilInventoryFlag: ItemDropOnDeath
  • Этот флажок заставляет боевую единицу после гибели выбросить все свои предметы на землю, даже если эту боевую единицу можно воскресить. Этот флажок может пригодиться для создания обычных боевых единиц со способностью рюкзака из WarCraft III.
• Новый флажок в настройках EAbilInventoryFlag: CanUseItem
  • Этот флажок определяет, могут ли боевые единицы использовать предметы. Он помогает создавать боевых единиц – курьеров с инвентарем, который позволяет им носить предметы, но не использовать их.
• Новый флажок в настройках EAbilInventoryFlag: CanApplyEquipBehavior
  • Этот флажок определяет, могут ли единицы получить прибавки к параметрам от предметов, например, «+5 к силе». Он также пригодится при создании боевых единиц – курьеров.
• Новый флажок в настройках CItemAbil: «Переходный» (Transient)
  • Если этот флажок установлен, то способность предмета будет применена со свойством «Переходный» (Transient), даже если оригинальная способность этого предмета не обладает таким свойством.
• Исправлена неполадка, в результате которой боевые единицы с инвентарем пытались подобрать предметы, даже если те уничтожались при приближении.
• Исправлена неполадка, в результате которой функция CAbilSpawn не работала.
• Исправлена неполадка, в результате которой при обмене предметов из инвентаря на максимальной дистанции предмет исчезал, но его владелец не получал ресурсов.
• Новые подназвания событий агента категории Abil: PawnSource, PawnTarget.
  • Срабатывают при обмене предмета.
• Новое поле в настройках CAbilInventory: «Требования» (Requirements)
  • Когда в этом поле указано значение, способность обладания инвентарем будет отключена до тех пор, пока не будут выполнены требования дерева технологий.
  • Интерфейс инвентаря также будет скрыт до выполнения требований.
• Новый флажок в настройках CValidatorUnitInventory: RequireEnabled
  • Когда этот флажок установлен, валидатор будет возвращать значение e_CmdOK, только если целевая способность обладания инвентарем включена и ее требования дерева технологий выполнены.
• Для реакций на события примененных игроком эффектов добавлена новая API-функция для триггеров, позволяющая пользователям получить информацию о предмете, который произвел данный эффект, определить, существует ли этот предмет, и выявить тип этого предмета.
• Способности предметов теперь могут использовать свои собственные ссылки на восстановление, что перезаписывает ссылку на восстановление, унаследованную от способности.

Поддержка нейтральных/дружественных магазинов

• Нейтральные/дружественные магазины это нейтральные/дружественные строения, с которыми игроки могут взаимодействовать при помощи способностей вроде CAbilInteract.
• В поле «Технология игрока» (Tech Player) для всех способностей теперь есть дополнительная опция «Заклинатель» (Caster).
  • При заданной опции «Заклинатель» (Caster) в поле «Технология игрока» (Tech Player) в настройках CAbilTrain способность будет проверять, соответствует ли отдавший приказ игрок требованиям дерева технологий.
  • Это может пригодиться для создания способности, которая позволяет продавать боевую единицу или предмет в зависимости от состояния дерева технологий покупателя.
• Новое поле в настройках CabilTrain: AgentUnitValidator
  • Когда в этом поле указано значение, для применения данной способности при обучении боевых единиц всегда будет требоваться боевая единица – агент, при этом также будет проводиться проверка на соответствие указанным в этом поле валидаторам.
  • С помощью этого поля в SC2 можно с легкостью создавать способности «магазина предметов».
    • При использовании магазинов предметов стоит сделать так, чтобы для возможности приобретать предметы боевой единице – покупателю требовался инвентарь.
    • Ранее в SC2 не было такого уровня поддержки, поэтому предмет все равно создавался, даже если у покупателя не было инвентаря.
    • С помощью поля AgentUnitValidator пользователи могут использовать такие валидаторы, как «Боевая единица обладает инвентарем» и «Инвентарь не полон» (Unit has a valid inventory / Inventory is not full), вследствие чего, если боевая единица — агент не обладает инвентарем, то при применении способности возникнет сообщение об ошибке, а способность не будет применена.
• Новый флаг в настройках CAbilTrain: ChargeCasterPlayer
  • Обычно для способностей нейтральных магазинов требуется, чтобы покупатель и продавец обладали общими затратами ресурсов, включенными при помощи флага «Общие затраты союзников» (Ally Spending). В противном случае покупатель получит сообщение об ошибке «Нельзя передать ресурсы этому игроку» (Can’t Spend On that Player).
  • По умолчанию нейтральные игроки обладают общими затратами со всеми игроками. Но если пользователю нужно создать союзный магазин, где союзные игроки смогут приобретать боевые единицы или предметы, то, скорее всего, не следует устанавливать этим игрокам общие затраты. Ведь в таком случае игроки смогут тратить деньги своих союзников.
  • Новый флаг ChargeCasterPlayer создан для решения этой проблемы. Когда он установлен, стоимость проданного предмета будет оплачиваться за счет игрока, который отдал приказ о покупке, даже если покупатель и продавец не обладают общими затратами.
  • Если в игре есть другие игроки, которые обладают общими затратами с игроком-покупателем, и у игрока-покупателя не хватает ресурсов, чтобы оплатить покупку, эта способность по-прежнему позволит оплатить ее за счет этих игроков.
• Новый флаг в настройках CAbilInteract: AlwaysShowCommandCard
  • Когда этот флаг установлен, все игроки, способные взаимодействовать с магазином, будут видеть его панель приказов (эти игроки определяются полем фильтра цели CAbilInteract), даже если рядом с магазином не находятся подходящие боевые единицы – агенты данных игроков.
  • Поэтому даже если рядом с магазином нет агентов игрока, он все равно сможет посмотреть, какие товары продаются в магазине.
  • Но этот игрок все равно не сможет использовать панель приказов, если он не контролирует магазин — например, если рядом с магазином не находится его боевых единиц – агентов.
• Исправлена неполадка, в результате которой способности взаимодействия постоянно совершали попытки приобрести боевую единицу без проверок поля ValidatorArray.

Алгоритмы системы отслеживания боевых единиц

• Новый тип алгоритма: BehaviorUnitTracker
  • Этот алгоритм работает как список боевых единиц. Он может хранить все боевые единицы, которые в нем содержатся, а также обладает валидатором и полями максимальных числовых значений. Если какой-либо элемент списка не соответствует значению валидатора, он удаляется из этого списка.
  • Также доступны флаги, с помощью которых можно конвертировать данный алгоритм в общий список или зависящий от игроков список, для работы которого не требуется копия алгоритма.
• Новый аккумулятор: CAccumulatorTrackedUnitCount
  • С его помощью можно настроить использование аккумуляторов в зависимости от количества боевых единиц в заданном списке.
• Новые эффекты: CEffectAddTrackedUnit, CEffectClearTrackedUnits, CEffectRemoveTrackedUnit
  • С их помощью можно добавлять или удалять боевые единицы из списка.
• Новый эффект: CEffectEnumTrackedUnits
  • Позволяет использовать цикл, чтобы перебирать все боевые единицы в отслеживаемом списке и применять к ним эффекты в зависимости от фильтров.
• Новые валидаторы: CValidatorCompareTrackedUnitsCount, CValidatorIsUnitTracked
  • Позволяют подсчитывать, сколько боевых единиц отслеживается данным алгоритмом, и проверять, принадлежит ли боевая единица к заданному списку отслеживания.
• Система отслеживания может оказаться очень полезной, если вам нужно задавать соответствие данных боевых единиц по модели «один ко многим».
  • Например, так можно отслеживать призванные боевые единицы по той, которая их призвала.

Другие изменения системы алгоритмов

• Наименование суммирований алгоритмов
  • Эта функция позволяет суммировать алгоритмы в зависимости от «идентификатора суммирования» (stack id), а не идентификатора алгоритма.
  • Например, в WC3 варианты «Ауры гениальности» есть как у верховного мага, так и у различных нейтральных существ. Они накладывают два разных положительных эффекта, и если у вас есть оба этих типа боевых единиц, то, скорее всего, вам не нужно, чтобы находящиеся рядом боевые единицы получали эффекты от обоих типов «Ауры гениальности». В таком случае версия принадлежащей герою ауры должна сохранять приоритет.
  • Два новых поля в настройках CBehaviorBuff: StackAlias (строковое значение) и StackAliasPriority (целое значение).
    • Если два положительных эффекта, имеющие одинаковые значения StackAlias, применяются к одной и той же боевой единице, они получат одинаковые параметры максимального числового значения (Max Count), равные более низкому. Если общее количество превысит параметр максимального числового значения, то игра начнет удалять суммировавшиеся положительные эффекты, начиная с того из них, у которого самый низкий показатель StackAliasPriority и самое короткое время действия. Это будет повторяться до тех пор, пока общее число операций суммирования не сравняется с параметром общего максимума.
  • Новое событие агента: BehaviorStackAlias
    • С его помощью можно захватить события алгоритмов («Включить», «Отключить», «Реакция на урон» и т. д.) в зависимости от значения поля StackAlias алгоритмов, а не их идентификаторов.
    • Оно также поддерживает наличие общих агентов у разных алгоритмов с одинаковыми полями StackAlias, так как вам, вероятно, будет нужно, чтобы у всех версий «Ауры гениальности» были одинаковые графические элементы.
  • Новое поле в настройках CEffectRemoveBehavior: StackAlias
    • С его помощью можно удалять положительные эффекты в зависимости от значения поля StackAlias.
  • Новый валидатор: CValidatorUnitBehaviorStackAlias
    • С его помощью можно считать сумму алгоритмов по значению поля StackAlias. Он подсчитает все примененные к боевой единице алгоритмы с заданным значением поля StackAlias. Также есть опция подсчета только включенных алгоритмов.
• Поддержка перемещаемого текста реакции на урон агентов
  • Если CActorMsgBehavior запускает событие с подназванием DamageHandled, при использовании сообщений SetTextLocalized и SetText после события автоматически будет задан текст с измененным значением урона.
  • Это значение перезапишет токен %AMOUNT% в целевом тексте.
  • Эта функция может пригодиться для создания текста с объемом урона для реакций на урон.
• Улучшенная поддержка событий агентов, включающих и отключающих алгоритмы
  • События, включающие и отключающие алгоритмы, теперь будут задавать параметры эффектов для последнего наложенного суммирования или последнего удаленного суммирования.
  • Это может пригодиться для более точной настройки агентов алгоритмов. Ранее пользователи не имели возможности указать ссылку на заклинателя, применившего алгоритм, в настройках событий, включающих и отключающих алгоритмы.
• Новое состояние алгоритма: «Не может умереть» (Cannot Die)
  • Указывает, что боевая единица не может умереть, пока не будет удален алгоритм.
  • Хотя при помощи реакций на урон можно достичь похожего эффекта, ответы при гибели могут предотвратить лишь гибель от получения урона. Этот алгоритм предотвращает смерть по любой причине — например, если запас здоровья боевой единицы установлен на значение 0.
  • Это состояние представляет собой простую альтернативу системам предотвращения смерти, основанным на триггерах.
• Новое состояние алгоритма: «Запрет зачета убийств» (Suppress Kill Credit)
  • Предотвращает учет убийств для боевой единицы или зачисление ресурсов за убийство для игрока.
  • Это может пригодиться для созданий боевых единиц – иллюзий.
• Новое поле в настройках CBehaviorBuff: DeathType
  • С его помощью можно перезаписать поле DeathType боевой единицы и игнорировать тип смерти, зависящий от эффекта смертельного урона.
  • Тип смерти «Удаление» (Remove) нельзя перезаписать с помощью этого поля.
  • Значение по умолчанию — «Неизвестно» (Unknown), что означает «не перезаписывать».
• Новый тип смерти: «Реинкарнация» (Reincarnation)
  • Не позволяет боевой единице бросать на землю добычу и предметы после гибели.
• Валидатор CValidatorUnitCompareBehaviorCount и эффекты CEffectRemoveBehavior и CEffectTransferBehavior теперь обладают следующими общими полями дополнительных настроек:
  • BehaviorCategories, BehaviorClass, BehaviorAlignment, ExcludeOriginPlayer, ExcludeCasterUnit, RequireOriginPlayer, RequireCasterUnit
• Ранее эти валидаторы/эффекты обладали только полем CEffectBehavior, а дополнительные поля присутствовали только в настройках CEffectBehavior.
• С их помощью можно лучше контролировать процессы подсчета, удаления и передачи алгоритмов.
• Например, пользователи теперь могут удалять суммирования алгоритмов, которые были добавлены целевой боевой единицей – заклинателем, игроком и т. д.
• Они также могут пригодиться при добавлении «умного рассеивания», например, для удаления только положительных эффектов, наложенных вражескими боевыми единицами.
• Новое поле в настройках CValidatorUnitCompareBehaviorCount, CEffectRemoveBehavior и CEffectTransferBehavior: «Соответствует всем» (Matches All)
  • Определяет, необходимо ли эффекту/валидатору для работы соответствовать всем полям конфигурации или хотя бы одному из них.

Улучшенная поддержка трупов

• Новый флаг в настройках CEffectModifyUnit_ModifyFlags: «Удаление» (Remove)
  • С помощью этого флага можно напрямую удалить боевую единицу из игры и уничтожить весь набор агента боевой единицы.
  • Мы добавили этот флаг, потому что раньше не было возможности удалить труп при помощи эффекта удаления из категории CEffectDamage.
• Новый фильтр боевых единиц: «Разлагается» (Decaying)
  • Разлагающаяся боевая единица — это та, что в данный момент уже мертва и пролежала на земле в течение определенного времени. Погибшая боевая единица, которая все еще падает на землю и пока не превратилась в труп, не считается разлагающейся. С технической точки зрения боевая единица становится разлагающейся, когда время смерти уже началось, а промежуток на воскрешение подошел к концу.
  • Этот фильтр нужен для того, чтобы способности, нацеленные на трупы, не действовали на боевые единицы, которые недавно умерли и находятся в процессе образования трупа.
  • Если время смерти боевой единицы равняется -1, то фаза разложения будет пропущена. Например, герои в Warcraft III никогда не разлагаются.
• Новый фильтр боевых единиц: «Можно поднять» (Raiseable)
  • Теперь в настройках CEffectModifyUnit есть возможность дать трупу свойство «Нельзя поднять» (Unraiseable).
  • С помощью этого свойства можно отметить труп, который уже был использован.
    • Например, пока вурдалак пожирает труп, этот труп все еще существует, но создатели модификаций могут решить, что такие трупы больше нельзя воскресить или поднять из мертвых. В таком случае создатели модификаций могут настроить способности таким образом, чтобы они действовали только на трупы со свойством «Можно поднять» и чтобы пожираемые трупы получали свойство «Нельзя поднять».
• Новый флаг: «Разрешить трупы» (Allow Corpse)
  • Если этот флаг установлен для транспортной способности, то с ее помощью можно будет подбирать и переносить трупы.

Система типов атаки, типов урона и типов брони

• Новое поле в настройках CWeapon: «Тип атаки» (Attack Type)
  • Создатели модификаций могут изменить множители урона для каждого типа атаки против каждого типа брони в настройках данных игры.
  • Тип атаки влияет на все эффекты урона во всей структуре оружия, и создатели модификаций смогут настраивать множители урона на уровне оружия, вместо того чтобы изменять факторы урона для каждой записи эффекта во всей структуре эффектов по отдельности.
• Новое поле CUnit: «Тип брони» (Armor Type)
  • Тип брони определяет множители урона оружия при использовании против боевых единиц.
• Новый валидатор: CValidatorUnitArmor
  • Позволяет пользователям проверять тип брони боевых единиц.
• Новое поле CEffectDamage: «Тип урона» (Damage Type)
  • Создатели модификаций могут изменять фильтры целей для типов урона в данных игры.
  • Использование фильтров целей для типов урона позволяет пользователям настраивать параметры всех эффектов урона и урона по области в игре. Оно также может определять, способны ли определенные эффекты урона наносить урон определенным целям.
  • К примеру, отфильтровав все цели с пометкой «Союзник» (Ally) в каждом типе урона, пользователи могут сделать так, что урон по области всех видов оружия в игре больше не будет применяться к союзникам. Это может пригодиться при разработке модификации для совместного режима, ведь ее нужно создавать на основе нескольких других модификаций, а оружие с уроном по области и способности в этих модификациях могут использовать разные эффекты при поражении союзников.

Эффекты шанса промаха, блокирования и отражения

• Алгоритм реакции на урон теперь может отвечать не только за случаи реакции на урон.
• Шанс промаха
  • Новый флаг CWeapon: NeverMiss
    • По умолчанию оружие будет следовать старым алгоритмам.
  • Модификаторы атаки также могут добавлять свойство NeverMiss к структуре эффектов оружия.
  • В тех случаях, когда в структуре эффектов оружия указано, что оно может промахиваться, при применении оружия шанс промаха проверяется как на стороне атакующего, так и на стороне защитника. После этого для эффекта будет отмечено, произошел ли промах. При этом учитываются валидаторы и установленные вероятности в структуре реакции.
  • Наземные боевые единицы, атакующие цели на возвышенности, также могут иметь дополнительный шанс промаха, который можно изменять в данных игры.
  • Если структура эффектов оружия была помечена как «Промах» (Missed), то оружие не применит к цели урон или какие-либо эффекты сферы при поражении.
  • Когда оружие промахивается, оно отправит событие агента оружия с подназванием «Промах» (Missed). Таким образом создатели модификаций смогут сами решать, хотят ли они, чтобы событие создавало текст «Промах!» над боевой единицей или чтобы отображался эффект уклонения.
• Вероятность блокирования
  • Новое поле CEffect: CanBeBlocked
    • Определяет, может ли эффект быть блокирован. Изначально функция отключена.
  • Когда эффект выполняется, игра запросит структуру отклика целевой единицы и проверит вероятность блокирования и любые валидаторы.
  • При блокировании эффект отменяется и не выполняется. Этот эффект затем отправит событие агента эффекта с подназванием «Блок» (Blocked), чтобы пользователи могли задать соответствующих агентов.
  • Эта функция пригодится для создания алгоритмов блокировки способностей.
• Шанс отражения
  • Новый флаг CEffect: ValidateImpactDeflection
    • Определяет, может ли эффект быть отражен. Изначально функция отключена.
  • Отражение похоже на блокирование, но при отражении отмененный эффект дублируется и применяется против атакующего.
  • Отраженный эффект меняет местами параметры заклинателя и цели и считается атакой изначальной цели, направленной на изначального атакующего. Параметр прибавки к урону в структуре эффектов отражения будет использовать бонусы к урону изначального заклинателя.
  • Другое отличие отражения от блокирования состоит в том, что структуры эффектов оценивают возможность отражения лишь один раз. Если эффект прошел проверку на отражение один раз, то остальная структура эффектов не будет проверять отражение снова, даже если в ней будет присутствовать эффект с включенным флагом ValidateImpactDeflection.

Изменение системы трансформации боевых единиц

• Morph/Unmorph Toggle
  • Новый флаг CAbilMorph: «Переключение» (Toggle)
  • Новое поле CAbilMorph: InforArrayUnmorph
    • Когда свойство Toggle включено, способности трансформации могут быть использованы снова, чтобы переключаться между двумя разными типами боевой единицы.
  • Новый индекс приказа CAbilMorph: Unmorph.
    • Для переключаемой способности трансформации после завершения трансформации боевой единицы применение способности запустит команду Unmorph, которая заставит боевую единицу начать процесс трансформации, описанный в поле InforArrayUnmorph.
    • В большинстве случаев поле InforArrayUnmorph должно быть заполнено так, чтобы последний тип боевой единицы был типом нормального состояния. Таким образом измененная боевая единица может трансформироваться обратно с помощью команды Unmorph.
  • Новое поле CabilMorph: ValidatorArrayUnmorph
    • Определяет, может ли прошедшая трансформацию боевая единица использовать команду Unmorph.
  • Новый флаг CabilMorph: AutoUnmorph
    • Определяет, будет ли трансформировавшаяся боевая единица автоматически пытаться отменить трансформацию при наличии возможности.
  • Новые поля CabilMorph: BehaviorOn/BehaviorOff
    • Если они заданы, то способность будет применять свойство BehaviorOn во время нахождения боевой единицы в трансформированном состоянии; а свойство BehaviourOff будет применяться тогда, когда боевая единица находится в нормальном состоянии. Эти два поля будут действовать лишь в том случае, если способность трансформации отмечена как переключаемая (Toggle).
  • Даже если боевая единица была изначально создана в трансформированном виде, способности трансформации все равно будут считать, что боевая единица прошла процесс трансформации. Они применят к ней необходимые алгоритмы и позволят ей использовать команду Unmorph.
• Подсчет технологий трансформации
  • Новый флаг CAbilMorph: ProvideSourceUnitTech
    • Во включенном состоянии CAbilMorph будет сохранять тип боевой единицы после трансформации. Последняя боевая единица автоматически унаследует связь исходной единицы в качестве наименования технологии.
    • Это свойство передается по всей цепи трансформаций.
    • Пример: Ратуша -> Крепость -> Замок
    • Замок будет также считаться и крепостью, и ратушей. Даже напрямую построенный замок будет следовать этому правилу, хотя он не был трансформирован из предыдущих строений.
    • Почему же мы просто не добавим наименования ратуши и крепости к наименованию замка (добавив их в поле наименования технологий замка)? Мы используем этот обходной путь, так как ProvideSourceUnitTech действует только тогда, когда боевая единица находится в завершенном состоянии. Только тогда она будет считаться исходной единицей при подсчете количества технологий. Если бы мы использовали поле TechAlias, то наименование существовало бы в любом состоянии, даже при трансформации боевой единицы (состояние InProgress). В этом случае, если вы трансформируете крепость в замок, то столкнетесь с неудобным переходным состоянием, когда у вас одновременно есть крепость в состоянии Completed и замок в состоянии InProgress. В таком случае система подсчета технологий распознает лишь крепость в состоянии InProgress, а это неверно.
• Поддержка «Трансформации после передвижения» (Move to and then Morph)
  • Новые флаги CAbilMorph: RequireAcquiredTarget, RequireAcquiredTargetUnmorph
  • Новые поля CAbilMorph: Range, TargetSorts
    • Когда данные полей заданы, боевая единица проведет поиск в радиусе автоматического применения способности, попробует найти соответствующую валидатору цель, а затем переместится к ней. Боевая единица начнет трансформацию после перемещения к целевой единице. Поле Range определяет максимальную дальность, на которой заклинатель может начать трансформацию.

Влияющие на производительность боевые единицы

• Новый флаг боевых единиц: NeverThink
  • Обычно каждая боевая единица в игре проверяет проходимость территории, наличие противников, получение способностей и много других логических элементов каждый игровой цикл (0,0625 сек. в игре). Данный флажок отменяет такие проверки, что должно улучшить производительность на пользовательских картах. Боевые единицы со статусом NeverThink могут следовать лишь алгоритму переноса ресурсов.

Другие общие изменения боевых единиц

• Максимальная скорость боевых единиц
  • Новое поле CUnit: SpeedMaximum
    • Определяет максимальную возможную скорость боевой единицы (даже с учетом бонусов).
  • Новое поле алгоритма: MoveSpeedBaseMaximumBonus
    • Используется для изменения максимальной скорости боевой единицы.
• Новый тип существ CUnit: Warcraft
  • В поле Mob боевой единицы теперь можно выбрать тип «Warcraft».
  • Это позволяет триггерам отличать боевые единицы из Warcraft от боевых единиц из Starcraft.
• Новые поля CUnit: LifeRegenRateNight, EnergyRegenRateNight, ShieldRegenRateNight
  • Могут позволить боевым единицам ночных эльфов восстанавливать здоровье ночью, не меняя алгоритмы отдельных боевых единиц.
• Новое поле CUnit: BuildTime
  • Дополнительное место для хранения данных о времени производства боевой единицы, которое можно использовать для настройки времени производства в CAbilBuild, CAbilTrain и CAbilMorph.
  • Новый флаг CAbilBuild и CAbilTrain: IgnoreUnitBuildTime
    • При отсутствии подтверждения время производства боевой единицы будет добавлено к времени производства способности.
  • Новый флаг массива CAbilMorph для каждого этапа каждого раздела: UseBuildTimeArray
    • За каждую фазу с данным установленным флагом время производства боевой единицы будет добавлено к длительности соответствующего этапа.
• Новый валидатор: CValidatorUnitCompareAbilStage
  • Позволяет пользователям проверять стадии способности CAbilEffect.
  • Если в поле способности указано «Нет», то проверяет стадию той способности, которая применяется в данный момент. Это означает, что пользователи теперь могут проверять, происходит ли поддержание боевой единицей применяемой способности.
• Новые фильтры цели:
  • «Усиление» (Powerup): срабатывают, если верно значение поля CUnit_PowerupEffect.
  • PowerupOrItem: усиление или предмет.
  • HeroUnit: боевые единицы с флагом «герой» (отличается от атрибута «героический»).
• Новое поле CUnit: уровень боевой единицы (Unit Level)
  • При выставленном значении >0 показывает соответствующий уровень под названием подсвеченной боевой единицы в ее описании.
  • Это поле может быть использовано для сортировки или валидации целей. Также может быть использовано в системе аккумуляторов.
• Родительский алгоритм пристройки
  • Новое поле CUnit: ParentBehaviorLink
    • При прикреплении пристройки к основному строению к нему будет применен алгоритм из поля ParentBehaviorLink. При этом исполнителем алгоритма будет считаться пристройка.
    • Это поле позволит состоянию пристройки влиять на состояние основного строения.
    • Способности трансформации смогут запустить проверку этого алгоритма и вызвать окно ошибки в том случае, если основное строение получит команду взлететь, пока в пристройке разрабатываются улучшения.
• CUnit_LifeDamageGain теперь можно обновлять.
• Значительно усовершенствован валидатор CValidatorUnitState. Теперь он может распознавать около ста состояний единиц, начиная с показателя 1.
  • Например: бездействие, прыжок, подсвечивание, потеря брони, возможность оживления, близость к смерти, выбор армии и т. д.

Другие изменения системы способностей

• Автоматическое назначение кнопок для способностей
  • Добавлено свойство для кнопок, позволяющее создателям модификаций назначить раскладку кнопок и идентификатор подменю по умолчанию для панели приказов. Это упростит добавление новых способностей для боевых единиц.
  • Для любой способности пользователи смогут задать свойство, при котором любая команда способности автоматически запустит назначение кнопок способностей. Таким образом способность можно будет использовать сразу после того, как она будет присвоена боевой единице. Пользователям больше не придется вручную назначать расположение и значки кнопок в панели приказов боевых единиц.
• Триггер API для добавления и удаления способностей единиц во время работы
  • Новые действия триггера API: Unit Add Ability, Unit Remove Ability
• Упрощенная настройка уровней
  • У большинства типов способностей появилось поле «Уровни» (Levels), в котором можно задать максимальный уровень способности. С этим полем и системой аккумуляторов пользователям больше не придется вводить 1000 наборов способностей для способностей с градацией в 1000 уровней.
  • Поле уровней можно изменять, а это значит, что пользователи смогут изменять максимальный уровень способности во время работы.
  • Если в поле уровней стоит значение 0 (по умолчанию), система уровней способности будет работать в старом режиме.
• Новое поле CCharge: задержка по времени (TimeDelay).
  • Можно применить к зарядам способностей, предметов и алгоритмов.
  • Функционирует аналогично полю TimeStart, но влияет только на первый заряд способности, предмета или алгоритма.
  • Если значение задержки равно 0, система зарядов будет работать без изменений.
  • Если значение задержки будет больше 0, значение TimeStart будет игнорироваться.
  • Когда способность начнет набирать заряды, время восстановления первого из них будет использовать значение поля TimeDelay, а все последующие заряды — значение поля TimeUse.
  • Новый флаг: IgnoreTimeDelay.
    • Это свойство позволит способностям игнорировать задержку по времени (TimeDelay), назначенную для боевой единицы, и вместо этого использовать параметры способности.
• Замещение по каталогу теперь также работает для способностей предметов.
  • Замещение зависит не от владельцев предметов, а от их пользователей.
  • Такая система позволит разным игрокам использовать один предмет с разными результатами.
    • Например, создатели модификаций смогут привязать к использованию одного предмета создание разных боевых единиц в зависимости от выбранной игроком расы.
• SEffectParamsShared теперь включает составляющую m_level, где сохраняется уровень способности, с которой начинается структура эффектов.
  • Структуры эффектов смогут использовать эту составляющую, чтобы получить информацию об уровнях. Таким образом, даже если уровень способности изменится с момента ввода структуры эффектов, информация о ее начальном уровне сохранится.
  • Эти данные также могут использоваться в аккумуляторах в качестве данных способности.
• CEffectCreateUnit_SpawnUnit теперь можно настроить таким образом, чтобы он создавал разные единицы в зависимости от уровня структуры эффекта.
• CAbilBheavior теперь может назначать разные валидаторы включения и отключения автоматического применения вместо одного валидатора.
• Новые категории способностей и алгоритмов
  • Добавлены различные категории способностей и положительных эффектов.
  • Алгоритмы положительных эффектов теперь смогут включать/отключать категории способностей.
• Новое поле для всех способностей: алгоритм состояния (State Behavior)
  • Это поле создает алгоритм при создании способности. Алгоритм будет удален при удалении способности и включен/отключен при включении/отключении способности.

Другие изменения системы урона

• Новое поле CEffectDamage: DamageInheritEffect
  • Назначенный в этом поле эффект будет применен после срабатывания основного урона.
  • Эффект наследует количество урона от основного.
• Новый флаг CEffectDamage: NoZeroDamageInherit
  • Предотвращает срабатывание поля DamageInheritEffect, если нанесенный урон равен 0.
• Новое поле CEffectDamage: доля (Fraction)
  • Дополнительный коэффициент, который будет умножен на остальные существующие коэффициенты.
  • Данное поле поддерживает аккумуляторы, что позволит пользователям создавать формулы, основанные на данном коэффициенте.

Предварительный эффект оружия

• Новое поле оружия: предварительный эффект (PreEffect).
  • Данный эффект схож с алгоритмом PreEffectBehavior и позволяет осуществлять проверку целевых единиц, чтобы определить, должен ли быть запущен предварительный эффект.

Поддержка однородного прерывания

• Новый флаг CAbilEffect: однородное прерывание (HomogenousInterrupt)
  • Если данный флаг установлен, будет запущен следующий алгоритм: если игрок выберет боевую единицу, поддерживающую действие заклинания, и прикажет ей двигаться, она прекратит поддержание и начнет движение. Если игрок выберет несколько боевых единиц и хотя бы одна из них не занята поддержанием заклинания, незамедлительно начнут движение только те единицы, которые не осуществляют поддержание заклинания. В таком случае приказ двигаться попадет в очередь приказов всех боевых единиц, поддерживающих действие заклинаний.
  • Если данный флаг не установлен, боевые единицы будут действовать согласно прошлому алгоритму SC2.

Изменение системы создания сооружений

• Теперь рабочие уступают место во время строительства.
  • При установленных флагах однородного прерывания (HomogenousInterrupt) и прерывания (Interrupt) способности CAbilBuild, которая не заставляет их исчезать внутри здания во время строительства, рабочие не будут препятствовать размещению новых строений. Вместо этого они отойдут в сторону, а затем попытаются найти подходящую позицию для продолжения строительства.
• Автоматическое временное масштабирование анимации создания строения
  • CAbilBuildable теперь будет направлять события запуска, отмены, завершения, паузы и продолжения (Start, Cancel, Complete, Pause, Resume) системе агентов.
  • События типа «Запуск» будут также содержать информацию о времени строительства. Агенты автоматически назначат длительность анимации строительства, соответствующую этому времени. Благодаря этому анимация создания строения закончится ровно тогда, когда оно будет построено.

Поддержка указателя на поверхности при атаках по области

• Данная функция привнесла два изменения в коде игры:
  • CActorMsgAbil теперь содержит cmd-информацию, чтобы пользователи могли использовать CActorTermAbilCmd в качестве ответа для CActorMsgAbil. Благодаря этим изменениям система агентов сможет определить с помощью индекса cmd (cmdIndex), какой атакой вызывается режим указателя: обычной или атакой по области.
  • CAbilAttack теперь передает отражаемый эффект в систему агентов как эффект указателя. Благодаря этому система агентов сможет запускать фильтр целей и масштабировать указатель для атак по области.
    • Если боевая единица оснащена несколькими типами оружия, для отображения указателя будет использован первый соответствующий требованиям отражаемый эффект оружия (DisplayEffect).

Изменения системы содержания

• Новое поле расы: стоимость содержания (UpkeepTax)
  • Оно позволит пользователям изменять скорость прироста ресурсов в зависимости от количества припасов.

Строительство на склонах

• Ранее игроки в SC2 не могли возводить строения на склонах в связи с особенностями кода игры.
• Новое поле данных типов поверхности: «Склоны - нельзя строить» (Ramp No Build)
  • Позволяет пользователям настраивать пригодность склонов для застройки.
  • Если это поле не активно, игроки смогут строить на склонах.

Улучшения системы способностей по сбору ресурсов

• Новое поле CAbilHarvest: ResourceAmountCapacity
  • Значение по умолчанию равно 0.
  • Каждый раз, когда рабочий завершит сбор ресурсов, он будет сравнивать количество ресурсов, которые он переносит в данный момент, со значением ResourceAmountCapacity. Если количество ресурсов окажется меньше этого значения, рабочий продолжит собирать ресурсы, пока не достигнет нужного количества или не получит новый приказ.
  • Даже если рабочий не соберет требуемое количество ресурсов, игрок сможет приказать ему прекратить сбор и вернуть уже собранные ресурсы.
  • Если рабочий получит новый приказ во время сбора, он попытается получить ресурсы хотя бы один раз, прежде чем начать выполнение нового приказа.
  • Если рабочий попытается продолжить сбор ресурсов, но к тому времени целевой источник ресурсов иссякнет, рабочий попытается найти другой ближайший источник ресурсов.
• Новый флаг CabilHavrest: «Нельзя извлечь» (No Extract)
  • Если этот флаг установлен, способность по сбору ресурсов позволит получать ресурсы, не истощая запасы единицы ресурсов.

Улучшения системы времени суток

• Новый триггер события, фиксирующий смену дня и ночи: Game Day/Night State Change
• Новая функция триггера, позволяющая получит/задать фиксированное значение времени суток: Set Time Of Day (Seconds), Current Time Of Day (Seconds)
• Новая функция триггера, позволяющая зафиксировать текущее состояние цикла день/ночь: Current Day/Night State
• Новый валидатор, проверяющий значение времени суток: Game Compare Time Of Day

Поддержка размещения ресурсов для системы агентов

• Новое сообщение агента: UnitResourceDrop
  • Это событие агента передается, когда единица размещает ресурс в главной постройке (или другой единице, допускающей хранение ресурсов).
  • В данном случае поле названия источника относится к агенту единицы, разместившей ресурс.
  • Поле подназвания относится к типу размещенного ресурса. Подназвание поможет пользователям редактора различать разные типы размещенных ресурсов.
  • Если применить сообщения «указать текст (локализованный)» (SetTextLocalized) и «указать текст» (SetText) после этого события, целевой текст будет автоматически изменен в соответствии с количеством размещенных ресурсов.
  • Количество размещенных ресурсов заменит токен %AMOUNT% в целевом тексте.

Создание нескольких агентов одного типа

• Новый тип агента: CActorBatch
  • Данное нововведение призвано решить проблему, при которой пользователи не могли повторно создавать агентов одного типа.
  • У данного типа агента есть поле счетчика, с помощью которого можно создать сразу несколько производных агентов того же типа.
  • По умолчанию созданные таким образом агенты используют параметры CActorBatch.

Принудительное зацикливание системы агентов

• Новая система агентов поддерживает принудительное зацикливание воспроизводимой анимации.
• Новый флаг EAnimsFlags: ForceLooping
  • Если одновременно установлен этот флаг, а также флаг постоянного воспроизведения (PlayForever), система будет проигрывать случайно выбранные вариации нужной анимации каждый раз, когда анимация завершается, даже если для данной анимации не было назначено зацикливание.
  • Приоритет флагов: AssetDrivenLooping > ForceLooping > NonLooping
• Новый флаг EAnimBracketStartFlag: ContentForceLooping
  • Когда этот флаг установлен, а флаг ContentPlayOnce не выбран, система будет воспроизводить случайно выбранные вариации нужной анимации каждый раз, когда основная анимация завершается, пока не получит сообщение AnimBracketStop, даже если для основной анимации не было назначено зацикливание.

Усовершенствованные тактические возможности ИИ

• Новое поле CUnit: AIExecuteAbilTactical
  • Данное поле может быть использовано для запуска тактической функции привязки ИИ по следующему образцу: единица, galaxyFuncName, scanned group, inAbility, inItem.
• Исправлено несоответствие между тактическими данными и тактической функцией, при котором тактическая функция не срабатывала для вражеских и нейтральных ИИ.

Поддержка терразина и особых ресурсов для ИИ

• Введены усовершенствования, позволяющие ИИ распознавать терразин и особые ресурсы как типы ресурсов. ИИ также сможет собирать эти ресурсы.

Возможность воскрешения для ИИ

• Теперь ИИ сможет интерпретировать команду обучить героя как команду оживить героя, если не сможет обнаружить способ обучить героя нужного типа.
• Как и в случае со способностями, наносящими ядерные удары, в скрипте ИИ должны быть обозначены оживляющие строения с помощью AIReqAddSpecialMaker().
• Если ИИ попытается обучить героя и не найдет способность сделать это, он произведет поиск в списке доступных способов оживления и попытается оживить героя соответствующего типа.

Возможность восполнения для ИИ

• Теперь ИИ учитывает замещение по каталогу при строительстве и обучении/производстве.
• Например, если ИИ заменит морпеха на зилота, ИИ распознает способность «Обучить морпеха» как «Обучить зилота» и сможет выдать правильный приказ на обучение единицы.
• Эти изменения также затронут команды объединения, строительства, разработки улучшений, обучения и вызова войск.
• Новый флаг боевой единицы: AIPreplacedForceBully
  • При изначальном размещении на карте данная единица будет рассматриваться как заменяемая единица, даже если в данный момент ее невозможно заменить. Это позволит компьютеру использовать способности, полученные с помощью действия триггера «заменить способность» (Replace Ability), чтобы заменять единицы.

Улучшенная конвертация классических карт

• Улучшена конвертация классических карт. В картах Warcraft III теперь преобразовывается не только сетка поверхности, но и текстура поверхности, а также изначально размещенные боевые единицы, декорации, разрушаемые объекты, камеры и области.

Система добычей, основанная на данных

• Новые функции Galaxy: UnitLootDropUnit, UnitLootDropPoint
  • Создатели модификаций могут настраивать добычу в соответствующем разделе редактора данных, а затем использовать эти функции для создания добычи. Это может быть предмет, боевая единица, эффект или даже случайный предмет определенного уровня/класса и т. д.
• Новые функции: UnitLootLastCreated, UnitLootLastCreatedGroup
  • Эти функции позволяют создателям модификаций забирать добычу, только что созданную с помощью UnitLootDropUnit или UnitLootDropPoint.
• Новый флаг предмета: IncludeInLootItemPool
  • Когда этот флаг активен, предмет будет включен в список случайной добычи CLootItem. Таким образом создатели модификаций смогут помечать предметы как недоступные в случайной добыче.
• Массив CLootItem.ClassArray теперь можно изменять, чтобы случайным образом выбирать класс создаваемых предметов с помощью триггеров.

Модификатор запросов по кнопке Ctrl

• Этот модификатор по умолчанию отключен. Его можно включать и отключать с помощью действия триггера UISetCommandAllowed.
• С включенным модификатором: если зажать Ctrl при выполнении запроса, он будет передан боевым единицам, подсвеченным в данный момент, а не всем выбранным единицам. Например, выбраны морпех и зилот, а подсвечен только морпех. Если отдать приказ двигаться по нажатию правой кнопки мыши и при этом зажать Ctrl, его выполнит только морпех.

Другие изменения свойств интерфейса

• Новое свойство CUnitFrame: UseSelectionLeader
  • В интерфейсе появилась возможность захватывать выбранную боевую единицу лидера (первую единицу задействованной подгруппы).
  • Когда свойство активно, CUnitFrame автоматически установит LocalObservedSelectionLeaderUnit() в качестве нужной боевой единицы. Оно также обновит свойство UnitTag, чтобы можно было привязывать свойства к другим рамкам.
  • Когда свойство активно, CUnitFrame будет игнорировать все остальные привязки свойства UnitTag к другим рамкам, поскольку оно должно соответствовать только текущему лидеру.
  • Когда свойство не активно, CUnitFrame будет работать, как обычно.
• Исправлена неполадка, в результате которой для CUnitButton не обновлялось свойство UnitTag.

Другие изменения триггеров API

• Стадия способности
  • CAbilRally теперь может запустить событие триггера: «Запустить, когда помещена точка сбора» (Place when the rally is placed).
• Гандикап для игроков
  • Гандикап для игроков теперь может превысить прошлый лимит в 100%.
• Управление обоймой боевых единиц
  • Новый API Galaxy: UnitMagazineAssign
    • Добавляет существующую боевую единицу в обойму.
  • Новый API Galaxy: UnitMagazineRemove
    • Убирает существующую боевую единицу из обоймы.
• Новый API состояния игрока: AlwaysShowUnitTooltip
  • Когда состояние активно, для боевых единиц этого игрока всегда будут отображаться подсказки при выделении, даже если такая возможность не задана.
• Новый API состояния игрока: GivesBounty
  • По умолчанию активно для всех игроков. Единицы игрока будут отдавать ресурсы за убийство противникам, которые их уничтожили.
• Новый API агента: ActorScopeMoveTo
  • Перемещает набор агента к ориентиру выбранного агента.
• Новый триггер события: Player Spent Vital Event
  • Запоминает, когда игрок расходует базовые показатели.
  • Может отличить, какие базовые показатели и в каком количестве были израсходованы во время отклика на событие.

Другие изменения в редакторе данных

• Редактор данных теперь может найти нужную строку XML, когда пользователь выбирает данные по умолчанию.
• Требования-ссылки (константа CTechRequirementsGraph*) учитывают замещение токена XML.
  • Благодаря этому большинство способностей теперь могут использовать токены, чтобы указать для требования-ссылки и самой способности одинаковый идентификатор.
• CBehaviorLinkArraynow теперь учитывает замещение токена XML.
• Свойства анимации (CAnimProps) в сообщениях агента теперь учитывают замещение токена XML.
• Попытка удалить несуществующее свойство агента TintColor больше не выдает сообщение об ошибке.
• У CActorQuad теперь есть флаги, допускающие автоматическое растягивание в зависимости от точки запуска и столкновения.
• Новый тип сортировки целей: CTargetSortValidator
  • Сортирует цели в зависимости от того, соответствуют ли они выбранным валидаторам.
• Новый флаг команды запроса: Attack Once
  • С помощью флага команды запроса теперь можно отправить запрос на одиночную атаку.
  • Флаг задается с помощью действия триггера Order Set Flags.
• Поля CEffectOffset теперь можно обновлять с помощью операций сложения, вычитания, умножения и деления, работающих как трехмерный вектор. Раньше в них можно было выставить только одно значение.
• Новый динамический набор: CKineticDistance
  • Перебрасывает целевую единицу со стартового положения на заданное расстояние. Направление задается изначальным параметром динамического набора.
• Новое поле CWeapon: DisplayName
  • Изменяет название оружия во всплывающей подсказке.
• Новый флаг CEffectModifyUnit: StartingVitals
  • Устанавливает запас здоровья, энергии и щита боевой единицы как начальные базовые показатели.
• Новый флаг CEffectModifyUnit: SetVitals
  • Напрямую устанавливает базовые показатели боевой единицы.
• Эффекты исцеления для CActorActon
  • CEffectHeal теперь позволяет использовать сообщения ActionParticipantsMessage и ActionCommenceMessage для CActorAction. Благодаря этому эффекты исцеления могут быть настроены для действий агента.
  • Исправлена неполадка, в результате которой CEffectHeal не удавалось вовремя вызвать подназвание действия остановки эффекта.
• Новый флаг CValidatorUnitOrderCValidatorUnitOrder: CheckStateOnly
  • Когда этот валидатор активен, он будет отслеживать только то, выключена ли команда способности для этой боевой единицы, даже если ее невозможно выполнить по тем или иным причинам (вроде нехватки маны).
• Новый флаг CEffectModifyUnit: ResourceDrop
  • Когда флаг активен, целевая единица сразу же уронит ресурсы, которые переносит в данный момент, не доходя до главного строения. Игрок-владелец получит эти ресурсы.
• Новый флаг CEffectEnumArea: UnCreep
  • Когда флаг активен, нейтральные существа больше не попадают в радиус поиска.
• API случайного генератора для боевых единиц:
  • Новый API триггера, позволяющий задавать случайный генератор для боевой единицы, получать и сбрасывать его значения.
  • Генератор случайным образом задает боевой единице название, значения и т. д.
  • Это полезно, если нужно создать точную копию боевой единицы.
• Исправлена неполадка, в результате которой CEffectSwitch иногда выдавало некорректное сообщение об ошибке.
• Новый флаг для производства боевых единиц: Copy Life Percentage
  • Определяет, будет ли у обучаемой боевой единицы такое же количество здоровья, как у обучающей единицы.
• Новый флаг для производства боевых единиц: Bypass Food Restriction
  • Игнорирует ограничение на количество припасов.
• Новый флаг управления способностями: Smart Cast
  • Определяет, можно ли по нажатию правой кнопки мыши применить способность отдельно от остальных единиц в группе.
• Новый флаг эффектов способностей: External Acquire Passenger
  • Позволяет способностям выбирать объектами боевые единицы в транспорте.
• Исправлена неполадка, в результате которой валидатор дальности оружия (Unit Weapon Range) не действовал на подчиненные боевые единицы.
• Новый флаг для эффекта создания целителя: Continue When Full
  • Определяет, продолжится ли эффект (Create Healer), если запас восполняемого показателя полон.
  • По умолчанию отключен.
• Исправлена неполадка, в результате которой эффекты Create Unit создавали единицы в точке сбора, а не заставляли перемещаться к ней, если было заполнено поле Rally Unit.
• Новое поле набора эффектов: RecycleCount
  • Позволяет многократно выполнять дочерние эффекты до сброса счетчика.
• Новый флаг эффектов способностей: Cancel Reset Auto Cast
  • Определяет, будет ли отменено автоприменение способности, когда игрок вручную отменяет поддержание способности.
• Новое поле валидатора получения опыта: Result Max Level
  • Проверяет, достигла ли боевая единица максимального уровня.
• Исправлена неполадка, в результате которой сообщения об оживлении указывали не те единицы или использовали не те звуковые эффекты.
• Новый флаг набора эффектов: Set Source
  • Устанавливает исходную точку/единицу дочерних эффектов как целевую единицу/точку для текущей выбранной единицы/точки.
• В редакторе данных добавлен поиск по списку команд способности.

Исправления рас в пользовательских играх

• Выпадающий список рас в лобби теперь правильно отображает заданные расы. Раньше он показывал только терранов, зергов и протоссов.
• Примечание: это изменение не затронуло модули расширения. Добавить свои расы в выпадающий список через модуль расширения пока невозможно.
• Исправлена неполадка, в результате которой карты, на которых используются пользовательские расы, могли перестать работать из-за функции выбора облика для консоли.

Поддержка пользовательских названий команд

• Редактор SC2 теперь поддерживает пользовательские названия команд.
• Можно установить разные пользовательские названия команд в разных режимах игры.
• Установить название команды можно в меню «Карта/модификация» -> «Варианты игры».

Новые возможности текстового тега d time/

• Добавлено пять новых временных типов в текстовый тег времени, чтобы показывать разное игровое время.
• Если выставить названия типов вместо числовых значений, текстовый тег будет показывать соответствующее игровое время.
• Примеры:
  • Ввод
    • Фиксированное время: "d time="9125"/>
    • Длительность игры: "d time="GameTime"/>
    • Время задания: "d time="MissionTime"/>
    • Время ИИ: "d time="AITime"/>
    • Дата/время: "d time="DateTime"/>
    • Время суток: "d time="TimeOfDay"/>
  • Отображение
    • Фиксированное время: 9125 сек.
    • Длительность игры: 11:50
    • Время задания: 11:50
    • Время ИИ: 11:50
    • Дата/время: 2020:06:12:12:12:23
    • Время суток: 22:06:34

Другие изменения свойств интерфейса:

• Новые свойства CHeroFrame: HeroTag, Skill Point
  • Выводит тег героя и неизрасходованные очки навыков.
  • Создатели модификаций могут использовать эти свойства, чтобы настраивать собственный интерфейс героев.

Другие изменения

• Максимальная плотность растительности (max foliageCount) в редакторе поверхности увеличена до 10 на клетку.
• Исправлена неполадка, в результате которой появлялось сообщение об ошибке при попытке оживить единицу, убитую до завершения трансформации.
• Новое поле в данных игрового интерфейса: Suppress Skins In Replay
  • Позволяет WCS GameHeart убирать облики в повторах.

ВНЕСЕННЫЕ ИСПРАВЛЕНИЯ

• Исправлена неполадка, в результате которой первая волна атаки могла застрять в ходе задания «Предчувствие Тьмы» в кампании Legacy of the Void.
• Исправлена неполадка, в результате которой нельзя было остановить автоприменение батареи щитов к строениям, не относящимся к оборонительным.
• Портрет командного центра терранов в облике консоли «Терраны (Remastered)» теперь расположен по центру.
• Исправлена неполадка, в результате которой некоторые водные декорации иногда на долю секунды зависали над водой.