ВВЕДЕНИЕ
Длинный пост, так как я намерен сделать его как можно более дружественным для изучения картостроения, но я пытаюсь облегчить чтение и перетасовку, разделив его на темы. Эта нарезка объяснит, как использовать новые триггеры редактирования объектов World Editor для создания нескольких и субъективных слоев данных объекта string.
Для использования, как одного мозга, я не могу даже думать о том, чтобы быть достаточно исчерпывающим, поэтому я приведу только пример скрытых вражеских инвентарей (функция, оставленная по желанию Blizzard, так как значение констант игрового процесса скрывает ее для всех, а не только для противников).
Не стесняйтесь публиковать идеи для большего количества аппликаций и попросите меня перечислять их здесь. Однако я не буду делать больше демонстрационных карт.
ПОДГОТОВКА
Я уверен, что большинство (если не каждый) из вас знают о последних дополнениях патчей к World Editor. Лично тот факт, что Blizzard снова собирает Warcraft III для обновления, наполняет меня радостью и надеждой. Конечно, вы не ожидаете, что мегакомпания инвестирует время и деньги в старую игру без планов на будущее, и этого достаточно, чтобы наполнить мои ночи мечтами о ремастер-версии, точно так же, как это случилось со Starcraft.
Среди восхитительных изменений JASS и vJASS было одно дополнение, которое, как я думаю, осталось частично незамеченным, один набор функций, которые даже привлекли внимание GUI, запускающего как действия. Это, конечно, возможность простого изменения данных объекта с помощью триггеров в ходе игры. Это можно сделать, например, изменив имя героя на "Hero-Set Hero Proper Name", или вывод урона юнита на "Unit-Set Base Damage".
Тем не менее, я здесь, чтобы объяснить, что использование редактора объектов через триггеры при воспроизведении карты - это только часть того, что могут предложить эти функции.
Кроме того, обратите внимание, что это новая находка с использованием новых функций и, как таковая, она может быть подвержена багам и ошибкам. Хотя я могу утверждать с безопасностью, что я проверил его всеми способами, о которых я мог думать, не сталкиваясь с проблемами, одного тестера никогда не бывает достаточно.
ФУНКЦИЯ GetLocalPlayer ()
Для тех из вас, кто знаком с JASS, вы, возможно, уже поняли, куда я иду с этим, просто взглянув на название темы. Если вы это сделали, Будьте моим гостем, чтобы пропустить его и перейти прямо к следующему шагу, где я более подробно расскажу о том, как работает эта многонациональная вещь.
И для тех, кто остался, я прошу терпения для этого краткого, редукционистского и прагматического объяснения: GetLocalPlayer () - короткая связующаяся JASS, которая может использоваться для запуска отдельных наборов действий для разных игроков в одной и той же игре.
Если, например, в качестве условия триггера указан GetLocalPlayer() == Player(0), то он будет выполняться только для игрока 1 (в Jass Player(0) означает первого игрока). Обратите внимание, что я не говорю, что он будет запускать триггер, принимая во внимание только игрока 1, но что все его действия будут выполняться только в экземпляре игры Red/Player 1. Так, короче, для других игроков, не обнаружил "- player 1" он как-будто бы курок не бегал вообще.
Это, конечно, так же опасно, как и выглядит, так как запуск вещей по-разному для игроков может вызвать серьезные проблемы, связанные с отключениями и desyncs. Если вы командуете скриптом для создания юнитов только после проверки, Красный ли локальный игрок, например, это, несомненно, приведет к десинхронизации с результирующим геймплеем - изменение распаковки данных (один локальный Экземпляр игры будет иметь больше единиц, чем другие).
Я предпочту не углубляться в детали, о том как безопасно использовать GetLocalPlayer() для всех намерений и целей, отчасти потому, что я уже нашел темы, посвященные этой теме, и это не цель данного поста (его цели вместо того, чтобы объявить мои выводы и демонстрируя, как они могут быть применены), а отчасти потому, что я сам еще не делал исследований по этому вопросу.
MULTINAMING
Несмотря на все проблемы с синхронизацией GetLocalPlayer (), которые могут возникнуть при работе с большинством дескрипторов и других опасных вещей, он относительно безопасен в использовании и может превратиться в замечательный инструмент при использовании для некоторых неагентов, таких как имена и описания некоторых объектов, таких как способности и предметы.
Это то, что я удобно называю здесь MultiNaming - метод использования собственного GetLocalPlayer() для объектов, несущих несколько имен в разных локальных экземплярах одной и той же игровой сессии. Как бы просто это ни звучало, его можно использовать для множества функций, от простого наличия ресурсов на нескольких языках одновременно до того, чтобы игроки не могли читать предметы, которыми обладает враг в своем инвентаре.
Для того, чтобы достичь этого, вы просто должны вызвать getlocalplayer() native в качестве условия и запустить сценарий именования, соответствующий игроку, чей локальный экземпляр вы хотите изменить. В GUI это может быть сделано так же просто, как с помощью двух пользовательских действий сценария до и после желаемых действий. Например:
Custom script: if GetLocalPlayer() == Player(8) then
Custom script: set udg_LocalPlayerName = GetPlayerName(GetLocalPlayer())
Game - Set Tooltip of UltimateAbility to LocalPlayerName for level 1
Custom script: endif
Это приведет к тому, что подсказка переменной способности игрока 9 (Player 0 = 1) будет изменена в соответствии с именем выбранного игрока, но только для его конкретного экземпляра игры. Другие игроки увидят, что та же способность, назначенная переменной Ultimate Ability, сохраняет всплывающую подсказку редактора объектов по умолчанию. Так как количество агентов во всех экземплярах игры остается одинаковым (изменился только описательный текст способности), то никаких десинков не будет вызвано.
Вот пример того, как это можно сделать, чтобы иметь одну и ту же способность, в одной и той же игре, отображать описания на английском и португальском языках для разных игроков (хотя нет португальского клиента WC3):
СКРЫТЫЙ ИНВЕНТАРЬ ВРАГА
В Редакторе WarCraft III есть константа игрового процесса под названием "отображение вражеского инвентаря", которая может быть помечена как истинная или ложная. Однако установка значения False скроет инвентарь героя от всех других игроков, независимо от того, являются они врагами или нет.
Это можно обойти, используя технику MultiNaming, представленную здесь, чтобы изменить имя, описание и путь к иконке всех предметов, которые подбирает вражеский герой, восстанавливая их исходные данные только тогда, когда они отбрасываются. Это, конечно, делается только для игрока локально с помощью GetLocalPlayer() native.
Как я уже упоминал в разделе предупреждения, это в версии 1.29 Warcraft III опасно и приводит к переименованию всех элементов одного типа. Это может быть показано в следующей строке 1.30 исправления ошибок changelog:
[World Editor] переименование элемента больше не меняет имен всех элементов
Обратите внимание, что это можно сделать намного проще, используя функции переименования при выборе вражеского героя. Но, к сожалению, это не работает, так как флаг от выбора единицы EVENT_PLAYER_UNIT_SELECTED, занимает слишком много времени, чтобы быть признанным после того, как игрок выбирает единицу, давая ему более чем достаточно времени, чтобы взглянуть на элементы. Теперь вы не хотели бы, чтобы у игрока было 0,5 секунды, чтобы посмотреть на предметы, прежде чем они будут замаскированы, не так ли?
Этого можно избежать, используя MultiNaming, когда герой выбирает / отбрасывает предмет, и на самом деле есть только три вещи, которые вам нужно изменить, чтобы скрыть инвентарь противника: имя предмета, его значок и его описание. Это единственная информация, которая отображается, когда вы выбираете вражеских героев, чтобы проверить их запасы-таким образом, изменения только их более чем достаточно.
1. СКРЫТИЕ ПРЕДМЕТА ПРИ ПОЛУЧЕНИИ
В идеале, вы хотите делать это каждый раз, когда герой берет предмет, локально переименовывая атрибуты предмета для всех игроков, у которых есть владелец героя в качестве врага. Звучит сложно? Ну, не совсем так. Это может быть сделано, просто устанавливая триггер так, в GUI:
Событие
Unit - A unit Acquires an item
Условие
Действие
Player Group - Pick every player in (All players) and do (Actions)
Loop - Actions
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
((Owner of (Hero manipulating item)) is an enemy of (Picked player)) Equal to True
Then - Actions
Custom script: if GetLocalPlayer() == GetEnumPlayer() then
Item - Set Name of (Item being manipulated) to Unknown Item
Item - Set Extended Tooltip of (Item being manipulated) to You do not know what item this is!
Item - Set Icon Path of (Item being manipulated) to ReplaceableTextures \CommandButtons\BTNSelectHeroOff.blp
Custom script: endif
Else - Actions
Опять же, вы хотите, чтобы это было сделано локально для игрока (не для всех), поэтому триггер проверяет через пользовательский скрипт (не доступный в GUI в противном случае), является ли локальный игрок игроком, от которого вы хотите скрыть предметы, таким образом, только выполняя свои действия для его игровой сессии.
Хорошо, хорошо, теперь всякий раз, когда игрок использует своих юнитов, чтобы забрать предмет, он будет скрыт для всех тех, кого он видит как врага. Но мы еще не закончили, теперь мы хотим сделать так, чтобы этот наш предмет в маске был разоблачен. Это может быть сделано в любое время, но пока давайте предположим, что мы хотим разоблачить предмет всякий раз, когда герой его бросает.
2. ПОКАЗЫВАТЬ ПРЕДМЕТ ПРИ ПАДЕНИИ
Для этого нам понадобится способ доступа к данным предмета, так как для игрока он был скрыт от него и навсегда потерян. Мы могли бы создавать переменные для хранения такой информации, как имя и описание элемента, каждый раз, когда он маскируется, но мы можем быть умнее - вместо этого было бы проще просто создать другой элемент того же типа, что и маскируемый элемент, скопировать его данные в элемент, который будет демаскирован, а затем удалить элемент, который мы только что создали.
Мы закончим с GUI триггер такой:
Событие
Unit - A unit Loses an item
Условие
Действие
Player Group - Pick every player in (All players) and do (Actions)
Loop - Actions
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
((Owner of (Hero manipulating item)) is an enemy of (Picked player)) Equal to True
Then - Actions
Item - Create (Item-type of (Item being manipulated)) at ((Center of (Playable map area)) offset by (99999.00, 99999.00))
Item - Hide (Last created item)
Custom script: if GetLocalPlayer() == udg_PlayerToMask then
Item - Set Name of (Item being manipulated) to (Name of (Last created item))
Item - Set Description of (Item being manipulated) to (Description of (Last created item))
Item - Set Icon Path of (Item being manipulated) to (Icon of (Last created item))
Custom script: endif
Item - Remove (Last created item)
На этом все, готово! Теперь предмет будет маскироваться всякий раз, когда его поднимает враг, и сниматься всякий раз, когда он падает. Обратите внимание, что в триггере мы создаем и удаляем элемент вне области GetLocalPlayer (). Если бы мы поместили его внутрь, это заставило бы нас создать или удалить элемент только в экземпляре локального игрока игры, очевидно, вызывая рассинхронизацию.
Если вы не хотите запускать триггер каждый раз, когда предмет подбирается, вы можете установить условие, чтобы запускать его только тогда, когда предмет подбирается в масках. Но будьте осторожны! Поскольку триггер имеет дело с созданием/удалением элементов, вам нужно, чтобы убедиться, что состояние как в маске или без маски отслеживается во всем мире, так что выше триггер будет срабатывать для всех игроков - таким образом избегая рассинхронизацию. Чтобы не сделать этот учебник дольше, чем он уже намеревается быть, я не буду подробно объяснять, как этого достичь. Вместо этого я загружу карту, содержащую пример того, как это можно сделать с помощью всплывающей подсказки того же элемента (бесполезные данные для наших целей, поскольку они отображаются только тогда, когда рассматриваемый элемент просматривается в магазине).
3. ПОРУЧЕННЫЕ ДЕТАЛЬНЫЕ ПРЕДМЕТЫ
Держитесь крепче! Прежде чем вы продолжите использовать это в ваших картах, есть одно небольшое препятствие для преодоления.
Это происходит при получении предмета с накладными расходами. Теперь, в зависимости от типа карты, которую вы делаете, это не может быть проблемой. Если это, однако, не волнуйтесь, есть простое решение, и это потому, что вы также можете локально изменить количество зарядов предмета, не приводя к рассинхронизации. Таким образом, вам просто нужно вернуться к триггеру, который вы только что сделали, когда игрок поднимает предмет, и вставляет следующее действие в область GetLocalPlayer:
Item - Set charges remaining in (Item being manipulated) to 0
При этом информация о количестве зарядов предмета может быть легко скрыта с дисплея, оставляя обнаженную красную метку допроса, как и любой другой замаскированный предмет.
Но это еще не все! Видите ли, делая это, мы создаем еще одну проблему: в Warcraft III, когда используется заряженный предмет только с одним оставшимся зарядом, он удаляется из игры. Это не произойдет автоматически с игроком, от которого мы просто спрятали заряженный предмет, поэтому, если вражеский герой использует предмет с одним зарядом, заставляя его уйти, он все равно будет существовать для нашего локального игрока, вызывая серьезную проблему рассинхронизации!
Таким образом, для того, чтобы исправить это, нам нужно глобально и постоянно хранить информацию относительно заряда предмета. На демонстрационной карте, которую я загрузил здесь, я делаю это, присваивая эту информацию пользовательскому значению предмета и делая так, чтобы элемент удалялся из игры, если его пользовательское значение когда-либо достигало нуля (поэтому балансируя количество агентов в каждом локальном экземпляре игры до того, как может произойти рассинхронизация).
Чтобы достичь этого в нашем примере, просто перейдите к триггеру, который мы только что сделали, который срабатывает всякий раз, когда герой поднимает элемент, и, в качестве его первого и главного действия (также до начала области GetLocalPlayer ()), есть функция, чтобы установить его Пользовательское значение на его заряды:
Item - Set the custom value of (Item being manipulated) to (Charges remaining in (Item being manipulated))
Затем, до конца области GetLocalPlayer () второго триггера, который мы сделали, чтобы стрелять, когда герой бросает предмет, мы меняем оставшиеся стеки нашего предмета на основе его пользовательского значения:
Item - Set charges remaining in (Item being manipulated) to (Custom value of (Item being manipulated))
Теперь количество зарядов предмета будет маскироваться и сниматься при выборе и падении вражеского героя соответственно. Но помните, что нам все равно нужно сделать так, чтобы Пользовательское значение предмета (в этом примере единственный способ для нашего локального игрока отслеживать расходы, не видя их визуально) постоянно обновлялось всякий раз, когда используется этот предмет. Для этого мы можем создать третий и последний триггер:
Событие
Unit - A unit Uses an item
Условие
Действие
Item - Set the custom value of (Item being manipulated) to ((Custom value of (Item being manipulated)) - 1)
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
(Custom value of (Item being manipulated)) Less than or equal to 0
Then - Actions
Item - Remove (Item being manipulated)
Else - Actions
Это небольшое усилие позволит удалить " заряд "из маскируемого предмета всякий раз, когда он используется, и, как объяснено, уничтожить его, если" счетчик заряда " когда-либо достигнет нуля, спасая наших игроков от проблемы рассинхронизации. Обратите внимание, что вышеупомянутый триггер проверяет, заряжен ли товар или покупается, прежде чем продолжить. Это делается, чтобы избежать удаления постоянных предметов со способностями после использования (поэтому, если ваша карта имеет дело с пользовательскими предметами, не забудьте принять необходимые меры предосторожности, чтобы они не ошиблись таким триггером).
4. ВЫВОД
Со всем этим, вы повысите свой опыт, чтобы пойти скрывать инвентарь! Если вы хотите применить это только к определенным предметам, нескольким выбранным героям или некоторым союзникам, вы можете легко сделать это, добавив больше условий к первым двум триггерам, которые я выставил. Конечно, поскольку существует множество способов адаптировать скрытый пример вражеского инвентаря, я оставляю это домашнее задание для себя, дорогой читатель.
Наконец, если на вашей карте есть динамические альянсы, не забудьте сделать дополнительный триггер, чтобы скрыть все предметы, которые в настоящее время удерживаются героями для всех врагов, когда союзники меняются. Для этого в тестовой карте, которую я прикрепил к этому посту, есть удобная для просмотра функциональность графического интерфейса, если вы хотите проверить это сами.
Надеюсь, вам понравился этот трюк с GetLocalPlayer () и функциями переименования, недавно добавленными в Редактор Warcraft III. Для любых отзывов или разъяснений, не забудьте оставить комментарий здесь.
Удачи, получайте удовольствие и наслаждайтесь тестовой картой!
Скачать карту |
