1) проблемы тут две: А) ивент не может определить мертва ли толпа юнитов. он может только срабатывать каждый раз, когда умирает один из этой толпы. Б) ты не можешь проверить через have_unit потому что последний юнит, смерть которого запустила ивент, еще как бы существует, и проверка даст положительный результат. Решить можно так (count проверяет больше ли таких юнитов чем 2. если осталось меньше двух, и один прям ща загибается, значит уже никого нет):
[event]
name = last breath
first_time_only=no
[filter]
id=Ruffian1,Ruffian2,Ruffian3,Ruffian4
[/filter]
[if]
[have_unit]
id=Ruffian1,Ruffian2,Ruffian3,Ruffian4
count=2-4
[/have_unit]
[then]
[/then]
[else]
... здесь то, что должно происходить, когда все мертвы ...
[/else]
[/if]
[/event]2) при помощи [object] добавляешь юниту и атаку и анимацию к ней. см. вики по WML или файл data/core/scenario-test.cfg - и там и там видно, как это делается.
3) делаешь ability у которой есть только id и название с описанием. тип не особо важен. потом делаешь ивент, срабатывающий... а когда срабатывающий? либо в начале каждого хода, либо после каждого передвижения. находишь при помощи [store_unit] всех юнитов с абилкой с этим id потом идешь циклом по созданному массиву и для каждого юнита делаешь {VARIABLE переменная[$счетчик].status.disabled no} а затем [unstore_unit] - это если он снимает только с себя. либо на каждом шаге цикла забираешь в [store_unit] всех юнитов стоящих рядом с данном юнитом, идешь циклом уже по ним и той же командой снимаешь статус уже с них.
4) делаешь атаке special у которого есть id и название с описанием. тип снова не особо важен. потом делаешь ивент attack end с фильтром оружия атакующего на твой special а также отдельный ивент точно такой же но с фильтром оружия обороняющегося на твой special (если сделаешь один ивент с обоими фильтрами нефига работать не будет). в ивенте при помощи object на unit и second_unit соответственно удаляешь атаку. как это делать, есть в вики по WML
5) все очень-очень плохо. меньше знаешь - крепче спишь.
6) так же, как и по всем другим. в файле юнита в movement_costs добавляешь unwalkable=1 и impassable=1 и будет ходить как миленький. Если надо не типу юнитов а отдельному юниту, при помощи object меняешь ему movement_costs и тоже самое делаешь. точно таким же способом можно например совсем запретить юниту ходить по лесу и т.п. - непроходимый террайн ничем не отличается от всех остальных, просто на него в данный момент ни у одного юнита нет разрешения.
7) лидерство и так только и для союзнических войск.
[modify_side]
side=НОМЕР
[ai]
... нужные настройки
[/ai]
[/modify_side]
9) вот так, но это не лишит тебя необходимости платить за кормежку каждого юнита, так что в реальности будут идти убытки, если все юниты не являются вернымиж.
[modify_side]
side=НОМЕР
income=0
village_gold=0
[/modify_side]10) [move_unit] - предполагая что тебе известны координаты с какого гекса толкать и на какой толкать. "прям на немного вместе со счетчиком" юниты не движутся. юнит может стоять только на каком-то гексе и его счетчики стоят на том же гексе.
11) при помощи object дать всем атакам этого юнита
[special]
[chance_to_hit]
value=100
[/chance_to_hit]
[/special]
12) сделать ивент на attacker hit где в фильтре второго юнита проверить твоего юнита. внутри ивента сделать [kill] со включенной анимацией а затем при помощи [sound] сыграть молнию. примеров применения в этих тегах полно во всех кампаниях и, конечно, они описаны в вики по WML
13) при помощи object изменить их так, как это описано в вики по WML
14) никак. можно только в ивентах отслеживающих нанесение удара узнать сколько он потерял от этого удара. исцелять при помощи [heal_unit] без указания объема.
15) при помощи [capture_village] - раз ты изменил на заснеженную, значит знаешь координаты.
16) никак - 1 мувпоинт всегда останетеся. однако при помощи object можно задать movement_costs такими высокими, что он не сможет пройти ни по какой территории
17) при помощи [animate_unit] как это описано в вики по WML
18) если тебе нужно чтобы создалась видимость нанесения ударов, то точно так же как в прошлом случае. если нужны реальные атаки со всеми последствиями, то через [do_command][attack] - читай об этом в вики и разбирайся, но это непросто.
19) при помощи object добавить атаке с определенным названием special как это описано в вики по WML
20) никак. ИИ на то интеллект, чтобы думать, а не делать то, что ты хочешь. Можно вовсе отключить интеллект, сделав врага пассивным, а все движения делать при помощи [move_unit] - тогда все будут идти точно туда куда надо, а юнитов врагу выдавать через тег [unit] - будут появляться те, кто скажешь. Если же нужно, чтобы интеллект играл, а не был марионеткой, то можно через ai указать приоритеты найма предпочтитетльные гексы - и там все зависит от того, насколько ты способен сформулировать критерии.
21) при помощи
[set_variable]
name=type
rand=Название типа 1, Название типа 2, Название типа 3...сколько их там тебе надо
[/set_variable]
в переменной окажется название типа юнита выбранное случайное. затем создаешь юнита где типом указываешь $type - и появится такой юнит.
22) при помощи тега [terrain] и фильтров, как они описаны в вики по WML
23) Также, как и в любом другом месте.
24) ивентом attack или attack end с фильтром на использование оружие со special=backstab и тип юнита, если необходимо.
25) ивентом attacker hits с теми же фильтрами
26) мне неизвестно о такой возможности. модификатор опыта принадлежит сценарию в целом, менять его по ходу игры не совсем верно, разве нет? это то же самое, что по ходу сценария изменить сценарий на другой сценарий... в сущности именно так я и предлагаю реализовывать.
27) user_team_name не влияет ни на что, а в team_name ты, очевидно, где-то ошибся. нет никаких запретов на то чтобы игроки 1 и 2 имели одну команду.
28) так же как любой террайн на любом террайне - зажать клавишу SHIFT и держа ее зажатой поставить лес поверх травы.
29) так же как и любой террайн в скрипте - при помощи [terrain]. при помощи редактора узнаешь террайн код непроходного места нужного тебе типа и создаешь его на нужном тебе месте.
30) при помощи [tunnel] как это описано в вики по WML
31) так же, как она сделана у серебряного мага - это свойство юнита, а не самого портала. при помощи object добавляешь нужным юнитам анимацию посомотрев в файле мага как она сделана.
32) так же как она сделана у белого мага - анимация лечения принадлежит юниту-лекарю. чтобы юнит лечился на хп надо дать тому кто лечит соответствующую ability. и анимации и абилки добавляются через object.
33)
[modify_unit]
id=$unit.id
facing=n
[/modify_unit]
34) при помощи modify_side как это описано в вики по WML
35) ничего соответственно не происходит в этой игре. анимации это анимации, они идут отдельно. способности это способности, они добавляются отдельно. однако анимации отравления в игре нет - в том числе и у убийцы - просто добавьте любому юниту способность отравления и враг будет становится зелененьким когда его ткнут. больше ничего делать не надо.
Так, а теперь в целом. ответы на все эти и многие другие вопросы можно почерпнуть из вики по wml:
https://wiki.wesnoth.org/EventWMLтам сбоку есть список всех тегов по которому можно удобно перемещаться и узнавать как они работают. именно эту вики и надлежит читать всем, кто хочет научится использовать WML. Программист, который не желает читать мануал - дерьмо, а не программист. Программист, который не знает английского языка и потому не может прочесть мануал - дерьмо, а не программист. Веснот это не та игра, которую может модить дерьмо. Дерьмо может делать сценарии для героев 3, где интуитивно понятный интерфейс в редакторе. В Весноте такого нет - его может модить только программист. Поэтому learn english and read the fuckin' manual
