Dragon Age Toolset Wiki - User contributions [en]

Backgrounds tutorial/ru

2011-10-20T17:33:34Z

Silderon:

{{rupage|Инструкция по созданию предыстории|Инструкции|Предыстории}}
== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете [http://social.bioware.com/project/4695/ скачать фикс] от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //извлечение с текущего события его типа
int nEventHandled = FALSE; //флаг, следящий за тем, было ли обработано события или нет.
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //предварительна загрузка ресурсов для генерации персонажа
StartCharGen(GetHero(),0,TRUE); //начало генерации
break;
}
default:
{
// -----------------------------------------------------------------
// Обработка отправленных движков события генерации персонажа.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //если событие не было обработано, оно отправляется в core-скрипт
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Отладка.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// Срабатывает, когда игрок кликает по иконке одной из доступных
// предысторий.
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Выбор предыстории для игрока и установка соответствующих предыстории
// plot-флагов.
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Проверяет шаблоны, указанные в 2DA-файлах
// и, руководствуясь ими создает герою инвентарь.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / то же самое
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Установка стандартный параметров для игрового персонажа.");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Установка переменной предыстории
// - создание внешности героя (или использование одной из заготовок)
//
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Игрок получает один навык.
// - найти нужный навык в файле backgrounds.xls
// - присвоить его игроку.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Установка plot-флагов расы: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// Сперва происходит инициализация всех флагов
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Tutorials]]
[[Category:Общий список переведённых страниц]]
[[Category:Translations_ru]]
{{Languages|Backgrounds tutorial}}
[[Category:Scripts]]

Effect keyword

2011-10-20T17:32:01Z

Silderon:

__NOTOC__
The '''effect''' type represents a modifier that can be applied to a game object.

== Constructor ==

The [[Scripting terminology#constructor|constructor]] for an effect is the [[Effect]] function.

== Literals ==

There is no [[Scripting terminology#literal|literal]] for an effect.

== Conversion ==

There is no explicit or implicit conversion to or from an effect.

== Persistence ==

The following functions allow an effect to exist outside of the scope of the current script by storing it on an object:

* [[SetLocalEffect]]

The following functions allow an effect which exists outside of the scope of the current script to be used in the current script by retrieving it from an object:

* [[GetLocalEffect]]

== Remarks ==

Every effect has a type set on it that determines how it affects the object it is applied to. They also have a number of parameters on them, which vary based on the type, that change the specific behaviour.

When the effect is removed (usually because the duration on the effect expires) the modifier is removed. These modifiers can be rule or stat based or more complicated visual and game effects.

They can be assigned different duration types which affect how they're applied and removed:

# '''Temporary:''' Applied for a short duration (measured in seconds)
# '''Permanent:''' Applied until manually removed through scripting
# '''Instant:''' These are one-shot modifiers that are not stored on the object (the death effect is an instant modifier for example)
# '''Equipped:''' Associated with an equipped item. The effect is removed when the item is unequipped.

Some effect types can only be applied as instant effects. These effects will delete themselves after they've been applied no matter what duration type was set for them. All other duration types will be stored in a list on the object they're applied to.

Effects are usually created and applied through the [[script|scripting language]]. The list of effects applied to an object can also be examined and modified through scripting. The game engine itself will apply some instant effects when appropriate (like death or damage during combat).

When an effect is applied through scripting, the designer has the option of specifying a sub-type on it. The subtype, which can be either "normal" or "magical", affects whether a "Dispel Magic" spell should clear the effect or not (Dispel Magic is an instant effect type). Magical effects are usually tagged with the spell id that created it so that more rules checking can be done when they're cleared.

Some effects trigger [[Event (dascript type)|event]]s to the object that they're applied to. This is especially important for hostile effects like damage or death. Each effect is tagged with the object id of the creator so that the target can react appropriately.

All stat modifiers stack with each other. If an object has two bonuses of the same type applied, they will get the full bonus from each.

When a game is reloaded, all the effects on an object are re-applied but with a special "loading" flag turned on. Most effects will see this and do nothing, since the object they're applying themselves to has already had the modifiers applied. A few effects will need to re-apply themselves if their effect is not easily saved.

Packages of effects can be constructed by "linking" them in the scripting language before they're applied. Any effects that are linked together will be given the same unique id when they're applied. If any effect in this group is then removed, either through expiry or scripting, then the entire group will go with them. This is most often used to tie a visual effect to a stat modifier. When the modifier expires the visual effect will disappear.

Effects are applied internally by signalling an "apply effect" event with pointer to the effect attached. They are usually removed in the same way because you don't know what else is linked to that effect and what dispelling them will do to the object.

The check to see if an effect has expired is done as part of an object's AI Update. Some effect types also have timers that are checked here to see if they need to be given an update (used for regeneration type effects).

Party members will have a series of "effect icons" that appear on their character sheets so that the player can see what effects are on them. These icons will be controlled by a special "Effect Icon" effect that will be linked to the spell's effects and managed by the scripter.

=== Effect Behaviour ===

Behaviour for effects can be defined in either the engine or in scripting. When an effect is applied or removed, the game will check for a defined handler for that effect type. If none exists, then the object will receive an event to their script with the effect attached.

To access the effect in an onApply or onRemove event, use the <code>effect GetCurrentEffect()</code> scripting command. The properties on this effect can be examined to determine type, duration and other parameters. If your script handles the effect properly and you want it to be stored (so that you get the onRemove event later) you need to call the special <code>void SetIsCurrentEffectValid(int nValid)</code> function. This will add it to the effect list on that object.

Effects will usually be handled by the core scripts rather than by an object's AI script.

== Examples ==

<dascript>
void main()
{
// uninitialised
effect eDefault;

// initialised using the constructor
effect eEmpty = Effect();

// initialised using damage effect function
effect eDamage = EffectDamage(42.0);
}
</dascript>

== See Also ==

[[IsEffectValid]],

[[Category:Keywords]]
[[Category:Effects]]
[[Category:Требуется перевод]]

Attribute

2011-10-20T17:30:29Z

Silderon:

{{Infobox script}}

Description of the attributes used by the game from a design perspective, with a focus on information needed by content and gameplay designers, such as how to incorporate attributes with ability, skill and campaign design.

=== Primary Attributes ===

The primary attributes in Dragon Age's rules system are

==== Strength ====

===== Effects =====

==== Dexterity ====

===== Effects =====

==== Cunning ====

===== Effects =====

==== Willpower ====

===== Effects =====

==== Constitution ====

===== Effects =====

==== Magic ====

===== Effects =====

[[Category: Scripts]]
[[Category: Rules]]
[[Category:Требуется перевод]]

Creature Properties

2011-10-20T17:29:24Z

Silderon:

{{Infobox script}}

The creature property system is the heart of the rules engine and defines all the numerical values that make up a character in Dragon Age.

== Detailed Description ==

Properties are 32-bit floating point values associated with every combat capable creature in the game (Creature Type field in the toolset). They are used by engine, scripting and UI to make up and display the RPG ruleset of the game.

=== Property Types ===

There are 3 types of properties that abstract the most common types of statistics found in an RPG:

==== PROPERTY_TYPE_SIMPLE ====

Simple properties are 32 bit floats that can hold a single value and that generally are not modified or influenced by other properties. Examples include Experience, Level or the number of unspent talent points a character has.

==== PROPERTY_TYPE_ATTRIBUTE ====

[[Attribute]]s are a moderately complex set of values encapsulating a single character stat. They have three fields that are independently tracked in the engine and are accessible from scripting:

* Base - A character's unmodified base value, usually only modified during level up and character creation. This number is displayed as a white number on the character sheet.

* Modifier - A float32 that holds the sum of all effect based modifications to the property. This number is shown as a red (if negative) or green (if positive) number on the character sheet.

* Total - The sum of the base and modifier fields along with any in engine modifications done to the property in C++ (for speed reasons) as defined by the engine link field. When reading this field, the engine will always clamp the return values between Min and Max, even though it stores the full, unmodified number internally.

{| style="margin:0; background:#f5fffa; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em; height:100%"
|-
|'''Example:'''
A level 1 warrior with 15 strength, a buff that grants +2 strength and a shield that has a +1 strength enhancement would be stored as as:
* Base: 15
* Modifiers: 3
* Total 18
|}

==== PROPERTY_TYPE_DEPLETABLE ====
Depletables represent the most complex type of stats usually found in an RPG, used for Health and Mana. In addition to all fields present on an Attribute, they have an additional 'Current' field.

* Current - This is the character's current value in this stat, which can be between Min and Max and can exceed Total.

Additionally, just like attributes, the EngineLink field defines some hardcoded behavior in the engine such as creating the link between the 'rengeration rate' properties.

{| style="margin:0; background:#f5fffa; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em; height:100%"
|-
|'''Example:'''
A level 1 warrior with 14 Con and 100 base health and a +5 health ring would store health who was at full health before getting hit for 20 points of damage:
* Base: 100
* Modifiers: +5
* Hidden Engine Modifiers: +20 (5 points for each point in CON after 10).
* Total: 125
* Current: 105

Hidden Engine modifiers can not be modified (obviously, they're in C++), but can be disabled by setting the EngineLink field to 0. They exist purely to speed up stats accessed with high frequency (DAScript has a 7-15x overhead per instruction compared to native code).
|}

=== Property Definitions ===

The two dimensional data array defined in [[Properties.xls]] defines numerical values that exist on every creature in the game. All properties are float32 and all rules logic of the game is based on floating point math. This dynamic data driven approach to rules relevant stats is new to Dragon Age: Origins and makes the engine extremely flexible for Designers. It enables the game to have a rules logic that is almost completely softcoded in script and data.

The following is an excerpt from the 2da that lists all rows present in the initial ship version of Dragon Age: Origins but only shows the most important columns. Note that DLC or expansion content may be overriding individual lines in the 2da.

{| class="wikitable"
|-|
! ID !! Stat !! Type !! Min !! Max !! Comment
|-|
| ''int'' || ''string'' || ''string'' || ''float'' || ''float'' || ''comment''
|-|
| 0 || INVALID || INVALID || 0 || 0 ||
|-|
| 1 || Strength || ATTRIBUTE || 0 || 1000 || STR [[Attribute]]
|-|
| 2 || Dexterity || ATTRIBUTE || 0 || 1000 || DEX [[Attribute]]
|-|
| 3 || Willpower || ATTRIBUTE || 0 || 1000 || WIL [[Attribute]]
|-|
| 4 || Magic || ATTRIBUTE || 0 || 1000 || MAG [[Attribute]]
|-|
| 5 || Cunning || ATTRIBUTE || 0 || 1000 || CUN [[Attribute]]
|-|
| 6 || Constitution || ATTRIBUTE || 0 || 1000 || CON [[Attribute]]
|-|
| 7 || Health || DEPLETABLE || 1 || 9999 || Hit Points
|-|
| 8 || Mana_Stamina || DEPLETABLE || 0 || 9999 || Mana or Stamina, based on class
|-|
| 9 || Attack || ATTRIBUTE || 0 || 1000 || Attack Power
|-|
| 10 || Defense || ATTRIBUTE || 0 || 1000 || Defense
|-|
| 11 || Armor || ATTRIBUTE || 0 || 1000 || Armor Mitigation Potential
|-|
| 12 || DamageScale || ATTRIBUTE || 1 || 10 || Based Damage Scaling (for difficulty settings and ranks)
|-|
| 13 || SpellPower || ATTRIBUTE || 0 || 1000 || Spellpower (Max(MAG-10,0)+Effects)
|-|
| 14 || Regeneration_Health || ATTRIBUTE || 0 || 50 || Health Regeneration Rate (Explore Mode) per tick.
|-|
| 15 || Level || SIMPLE || 0 || 99 || Current Character Level.
|-|
| 16 || Displacement || ATTRIBUTE || 0 || 100 || Chance to outright evade any physical attach attempt (aka Dodge)
|-|
| 17 || Inventory_Size || SIMPLE || 0 || 1000 || Inventory Slot size (on party)
|-|
| 18 || AI_BEHAVIOR || SIMPLE || 0 || 1000 || Selected AI Behavior
|-|
| 19 || Experience || SIMPLE || 0 || 186001 || Experience Points
|-|
| 20 || Flanking_Angle || ATTRIBUTE || 0 || 180 || The angle at which this creature is able to flank an enemy (default is 90)
|-|
| 21 || Melee_Crit_Modifier || ATTRIBUTE || -100 || 200 || The +melee crit modifier
|-|
| 22 || Missile_Shield || ATTRIBUTE || 0 || 100 || Chance to avoid missiles (shields and some spells increase this)
|-|
| 23 || Ranged_Crit_Modifier || ATTRIBUTE || -100 || 200 || The +ranged crit modifier
|-|
| 24 || Ranged_Aim_Speed || ATTRIBUTE || -3 || 6 || The character's speed bonus or penality when aiming with ranged weapons
|-|
| 25 || BaseAttackRating || SIMPLE || 0 || 1000 || The creature's cached base attack rating
|-|
| 26 || BaseDefenseRating || SIMPLE || 0 || 1000 || The creature's cached base defense rating
|-|
| 27 || CurrentClass || SIMPLE || 0 || 31 || The creature class (index into cla_base.xls)
|-|
| 28 || Regeneration_Health_Combat || ATTRIBUTE || 0 || 20 || The creature's health regeneration rate (per tick) in combat.
|-|
| 29 || Regeneration_Stamina || ATTRIBUTE || -20 || 50 || The creature's stamina regeneration rate (per tick) in explore mode.
|-|
| 30 || Regeneration_Stamina_Combat || ATTRIBUTE || -20 || 20 || The creature's stamina regeneration rate (per tick) in combat mode.
|-|
| 31 || AttackSpeedModifier || ATTRIBUTE || 0 || 1.5 || The creature's universal melee attack speed modifiers (used by haste, momentum, etc.)
|-|
| 32 || Resistance_Mind || ATTRIBUTE || -100 || 100 || Mental Resistance.
|-|
| 33 || Resistance_Physical || ATTRIBUTE || -100 || 100 || Physical Resistance.
|-|
| 34 || Attribute_points || SIMPLE || 0 || 100 || Holds any unspent attribute points the creature has. If this is != 0, the UI shows the levelup button.
|-|
| 35 || Skill_points || SIMPLE || 0 || 100 || Holds any unspent skill points the creature has. If this is != 0, the UI shows the levelup button.
|-|
| 36 || talent_spell_points || SIMPLE || 0 || 100 ||Holds any unspent talent points the creature has. If this is != 0, the UI shows the levelup button.
|-|
| 37 || Background || SIMPLE || 0 || 10 || The character's origin (index into backgrounds.xls).
|-|
| 38 || specialization_points || SIMPLE || 0 || 2 || Holds any unspent specialization points the creature has.
|-|
| 39 || DamageBonus || ATTRIBUTE || -100 || 100 || Universal physical attack damage bonus on the creature.
|-|
| 40 || Threat_Decrease_Rate || SIMPLE || -1000 || 1000 || The rate at which the creature's threat rating decays.
|-|
| 41 || Fatique || ATTRIBUTE || -25 || 250 || The creature's current [[Fatigue]] (% increase of ability cost).
|-|
| 42 || Damage_Resistance_Fire || ATTRIBUTE || -100 || 75 || The creature's damage resistance to fire. All fire damage is reduce by %.
|-|
| 43 || Damage_Resistance_Cold || ATTRIBUTE || -100 || 75 || The creature's damage resistance to cold. All cold damage is reduce by %.
|-|
| 44 || Damage_Resistance_Electricity || ATTRIBUTE || -100 || 75 || The creature's damage resistance to lightning. All lightning damage is reduce by %.
|-|
| 45 || Damage_Resistance_Nature || ATTRIBUTE || -100 || 75|| The creature's damage resistance to nature. All nature damage is reduce by %.
|-|
| 46 || Damage_Resistance_Spirit || ATTRIBUTE || -100 || 75 || The creature's damage resistance to spirit. All spirit damage is reduce by %.
|-|
| 47 || Damage_Shield_points || ATTRIBUTE || 0 || 9999 || Magical, damage mitigating shield (all damage types) on the creature. Creature immune to damage until the shield is depleted.
|-|
| 48 || Damage_Shield_strength || ATTRIBUTE || 0 || 100 || The maximum amount of damage the creature's magical shields can absorb (not used yet.)
|-|
| 49 || Damage_OffHand || ATTRIBUTE || 0 || 9999 || Display only cache of creature's weapon damage potential. This value is only used to marshal data into the UI, it does not have any rules implications.
|-|
| 50 || Damage_MainHand || ATTRIBUTE || 0 || 9999 || Display only cache of creature's weapon damage potential. This value is only used to marshal data into the UI, it does not have any rules implications.
|-|
| 51 || Healing_Effect_Factor || ATTRIBUTE || 100 || 200 || Percentage modifier of how effective healing is on the creature. Blood magic does NOT use this field, it is coded in effect_heal_h instead.
|-|
| 52 || Spell_resistance || ATTRIBUTE || 0 || 100 || Creature 'hostile magic resistance'. % Chance to avoid any hostile magic.
|-|
| 53 || AP_BONUS || ATTRIBUTE || -100 || 100 || Armor Penetration bonuses are stored her.
|-|
| 54 || CriticalRange || ATTRIBUTE || 0 || 200 || The 'range' which critical hits use. 150 would mean up to 150% of normal damage.
|-|
| 55 || Fire_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all fire damage dealt by the user (spells, staves, etc.)
|-|
| 56 || Spirit_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all spirit damage dealt by the user (spells, staves, etc.)
|-|
| 57 || Cold_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all cold damage dealt by the user (spells, staves, etc.)
|-|
| 58 || Nature_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all nature damage dealt by the user (spells, staves, etc.)
|-|
| 59 || Electricity_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all lightning damage dealt by the user (spells, staves, etc.)
|}

{| style="margin:0; background:#f5fffa; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
| valign="top"|
<h2 style="margin:0; background:red; font-size:150%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#fff; padding:0.2em 0.4em;">Words of Caution</h2>

Properties.xls is the most integral and powerful 2da in the game. Any changes to it have profound implications on the game and the chance of breaking existing savegames and introducing unwanted behavior.

'''Removing Rows'''
It is referenced from many other rules and UI related 2das and removing existing data can have severe consequences, including the invalidation of existing characters. You can NEVER remove rows from this 2da!

'''Changing Rows'''
Changing rows is not as dangerous as removing them, but still can have severe implications. The m2da system should be utilized to modify individual rows instead of overwriting the entire 2da. Especially the Min, Max and EngineLink columns hold a lot of rules relevant data that might not be obvious on the first glance (e.g. the Max value on 'Experience' defines the maximum XP the game will allow on a character. Any attempt to award more XP from script will silently fail.)

'''Adding rows''':
Every row added to this file will reserve several Float32 data fields on every combat capable creature in the game. While a few floats might not sound like a lot, the impact on runtime area memory, savegame size and associated load times can not be overstated. While these issues are more pressing for the console versions of the game, they still do affect the PC version and I strongly advise not to add to this file unless absolutely necessary.

|}

== Q&A ==

=== Q: Why use Floats instead of integers? ===

We had initially investigated a structure that would allow creation of typed properties but found the associated overhead and complexity in such a frequently accessed system to be too high to be worth it.

Since much of our system requires floating point values and floats can be easily rounded for display purposes, we decided to use floating point across the board.

=== Q: Won't floating point math lead to imprecision? ===

Yes, it can. Certain mathematical operations promote imprecision in floating point values. DA script, like NWScript is only precise for a limited number of digits and any existing imprecision can be magnified by consecutive divisions and other operations.

However, there are mitigating circumstances that make this much less of a problem than it might appear on paper (or fresh from university :)

* Most frequent calculations retrieve an existing floating point value cached in a property, run a bunch of calculations and then execute the result (e.g. calculating damage). The resulting values are rarely stored so imprecision has little opportunity to build up over time.

* When writing to values that are displayed as integers on the UI or used as integers in the combat math, we are casting back to integer before storing or computation (e.g. to avoid health from going into the gray realm between 0 and 1).

* Some engine commands have added security to prevent rounding errors from propagating from script into engine stored values.

* If you happen to do .004 points damage more during an attack, the gameplay impact is virtually zero, so even if imprecision manages to propagate up to the 3rd decimal, it is still not visible in the game.

=== Q: Is there anything absolutely hardcoded? ===

Yes. While nearly all C++ implemented aspects of the rules system can be turned off by removing the associated EngineLink from properties.xls, a few behaviors are not easy to modify or replace by script:

* Regeneration. While it is technically possible to turn off regeneration by setting all rates to 0, the system can not be modified. One would have to replace it with a scripted, heartbeat like construct to make changes. The reason for this is simple: Regeneration ticks at a high frequency on all combat capable creatures and the cpu time consumed by running this entirely in script is completely unacceptable.

* Some UI rules are currently hardcoded and although it is possible to control some of the UI through various 2das, replacing the entire UI with a new framework is impossible at this point.
[[category:rules]]
[[Category:Требуется перевод]]

Classes/ru

2011-10-20T17:27:03Z

Silderon:

{{rupage|Классы|Классы|Скрипты}}
{{Infobox script/ru}}

''В процессе доработки''

Dragon Age: Origins является классической ролевой игрой, которая позволяет пользователю играть героем одного из трех классов, каждый из которых обладает уникальными способностями.
== Описание ==
Данная страница описывает техническую составляющую различий между классами и создана с целью помочь пользователям, желающим создать модификации, используя возможности скриптовых правил(ruleset).

Игровые классы описаны в документе под названием '''[[CLA_base.xls]]'''.
Таблица, помещенная ниже является выдержкой из этого документа. В ней вы можете видеть различия между классами.

{| border="1" width="100%" style="font-size:xx-small"
|-
|'''ID'''||'''Label'''||'''BaseHealth'''||'''BaseManaStamina'''||'''DepletableProgression'''||'''StrAdjust'''||'''ConAdjust'''||'''WillAdjust'''||'''MagAdjust'''||'''CunAdjust'''||'''DexAdjust'''||'''BaseAttack'''||'''BaseDefense'''||'''DefensePerLevel'''||'''HealthPerLevel'''||'''LevelsPerAbility'''||'''LevelsPerSkill'''||'''DamagePerLevel'''
|-
|0||INVALID||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****|
|-
|1||Warrior||100||100||5||4||3||0||0||0||3||60||45||1||6||1||3||0.4
|-
|2||Wizard||85||115||6||0||0||4||5||1||0||50||40||1||4||1||3||0.1
|-
|3||Rogue||90||90||4||0||0||2||0||4||4||55||50||1||5||1||2||0.2
|-|
|}
Более подробное описание данных из таблицы вы можете найти здесь '''[[CLA_base.xls]]'''.
== Скриптовый этап создания персонажа ==
В начале создания, все персонажы игры являются такими себе 'болванками', у которых все параметры [[Creature Properties]] установлены по умолчанию.

Скрипты, создающие персонажа вместе с UI-файлами, основываюясь на выборах, сделанных игроком, создают данные в документе [[CLA_base.xls]]. Эти же файлы ответственны за изменение параметров игрока после получения нового уровня.

Для работы со спутниками героя используются те же файлы и скрипты. Для враждебных созданий используется более ускоренный и оптимизированный алгоритм, определяющий их параметры исходя из ранга, AI(искуственного интеллекта), поведения и уровня.
=== Скрипты ===
Вот перечень скриптов, который принимают участие в создании персонажа и изменении его параметров в результате получения нового уровня:

* sys_chargen - Точка входа для всех персонажей, создание которых основано на событиях ([[event (dascript type)|Event]]), запущенных из модуль-скрипта(module_core.nss).
* sys_chargen_h - Библиотека, которая содержит большинство логических правил, используемых при изменении параметров существа ([[Creature Properties]]). Основанная на игровых правилах(game rules).
* sys_chargen_engine - Инклуд-скрипт, содержащий несколько константных переменных и часть кода, связанную с игровым движком.
* sys_autolevelup_h - Файл, определяющий логику поднятия уровня спутников героя после их принятия. В дальнейшем используется стандартный алгоритм подьема уровня.
* sys_autoscale_h - Файл, определяющий логику автоподнятия уровня.
* sys_rewards_h - Файл, содержащий количество опыта, получаемого в качестве награды за определенное действие, точки сохранения игры и проверку персонажа на повышение уровня.

{{Languages|Classes}}
[[Category:Translations_ru]]
[[Category: Character_generation]]
[[Category:Scripts]]

Combat Rules/ru

2011-10-20T17:26:51Z

Silderon:

{{rupage|Система боя|Скрипты|Система боя}}
{{Infobox script/ru}}

'''Страница в процессе доработки'''

На этой странице описаны техническая составляющая и логика ведения боя в игровых скриптах.
В основном она касается боя с использованием исключительно оружия. О заклинаниях и способностях читайте [[Ability|Abilities]].

Примечание: Термин 'свойства', используемый на этой страницы относиться к свойствам существ здесь -> [[Creature Properties]].

== Детальное описание ==

Бой в игре Dragon age: Начало обрабатывается в основном скриптами. Движок имеет малое понятие об основных показателях, вляющих на бой, таких как 'Сила' 'Модификатор урона' или 'Пробиваемость доспеха'.

=== Последствия удара ===

Последствия удара определены в функции [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] в библиотеке скриптов [[combat_h.nss]], которые срабатывают, когда скрипт [[creature_core.nss]] обрабатывает такое событие как удар. Функция возвращает одну или несколько [[COMBAT_RESULT|COMBAT_RESULT_*]] константных переменных и сообщает игровому движку, какую анимацию нужно проиграть.

В целом, боевая система Dragon age является 'тяжело ударной' так как доспех цели никак не влияет на шанс попадания.

Упрощенный скрипт для обработки последствий удара виглядит так:

<dascript>

if Target Is Placeable Object
return COMBAT_RESULT_HIT

if Target Displacement/Dodge < RandomF(100.0)
return COMBAT_RESULT_MISS

if Attacker Is Using BASE_ITEM_TYPE_STAFF
return COMBAT_RESULT_HIT

bHit = RandomF(100.0) < AttackRating - DefenseRating
bCrit = CheckCricital()
bBackstab = CheckBackstab()

if bHit
if HasEffect(attacker, EFFECT_TYPE_MISDIRECTION_HEX)
if bCrit
return COMBAT_RESULT_HIT
else
return COMBAT_RESULT_MISS

if bBackstab
return COMBAT_RESULT_BACKSTAB
else
if bCrit
return COMBAT_RESULT_CRITICAL_HIT
else
return COMBAT_RESULT_HIT

else
return COMBAT_RESULT_MISS

</dascript>

==== Мощность удара ====

Мощность удара включает в себя:

* Базовый наносимый урон (54.0f)
* + [[#Flanking Bonus Determination|Flanking Bonus]] (позиция атакующего относительно цели, умения жертвы, например, укрытие щитом. Здесь бонус получают разбойники).
* + Штрафы, основанные на расстоянии к цели (для дальнего боя)
* + Значение наносимого нападающим урона(вместе со всеми бафами и тому подобным)
* + Любые предметы(руны), которые являются частью оружия и влияют на нанесение урона
* + Любые внешние бонусы или штрафы, которые попадают в функцию (из скриптов умений, например)
* + Уровень сложности игры

==== Уровень защиты ====

Уровень защиты включает в себя:

* Значение защиты обороняющегося (и уклонения, если речь идет о защите от оружия дальнего боя). Включает в себя бонусы от предметов, эффектов и различные магические бонусы.
* Уровень сложности игры

==== Бонусы от атак с фланга ====

* Значение бонуса атак с фланга содержится во float-переменной и влияет на мощность атаки и шанс нанесения критического урона.
* Бонус зависит от того, насколько близко атакующий находится к наиболее выгодному для атаки положению(за спиной цели).
* Различные способности боя со щитом уменьшают вероятность атакующего получить бонус от атаки с фланга.
* Чем дальше атакующий от позиции "со спины", тем меньше бонус.
* Бонус колеблеться от +0 до +15 (+20 с "Движением в бою") и влияет на мощность атаки и частично на (1+(Бонус атаки со фланга/5)) на шанс нанесения критического урона.
* Большинство персонажей могут подойти к врагу максимум на 60 градусов относительно спины, "Движение с бою" позволяет подойти на 90 градусов (положение "со спины"=180 градусам).
* Максимальный бонус от атаки с фланга получают только разбойники, все остальные получают половину.
* Понять логику лучше вы сможете, изучив скрипт [[combat_h.nss#Combat_GetFlankingBonus|Combat_GetFlankingBonus]] и [[combat_h.nss]].

==== Удар в спину ====

* Удар в спину может быть нанесен только в ближнем бою.
* Для выполнения удара в спину нужно, чтобы бонус атаки с фланга был больше 0(некоторые таланты обходят это ограничение).
* Наносить удар в спину могут только создания класса Разбойник [[Classes|Character Class]]. Это классовая привилегия.
* Наносить удар в спину могут только человекоподобные существа (это касается и порождений тьмы).
* Общую логику вы сможете понять изучив функции [[combat_h.nss#Combat_CheckBackstab|Combat_CheckBackstab]] и [[combat_h.nss]].
* Логику нанесения урона вы сможете понять, изучив [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]].

==== Нанесение критического урона ====

* Нанести критический урон могут только бойцы дальнего и ближнего боя(не маги). Значение критического урона зависит от типа атаки.
* + бонус к критическому урону от используемого оружия.
* + 1.20x (1.1x для неразбойников) the attacker's [[#Flanking Bonus Determination|Flanking Bonus]] in the current situation.
* + 3.5 если атакующий сражается с двумя соратниками против одного и того же воина и использует талант "Храбрость".
* Критический урон наносится, когда шанс нанесения меньшый чем РандомнаяПеременая()*100.0f.
* Некоторые эффекты и заклинания (например Death Hex) делают каждый нанесенный удар критическим.
* Логику вы сможете понять, изучив функции [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] в скриптовой библиотеке [[combat_h.nss]]

=== Урон ===

Значение урона рассчитывается в скрипте [[combat_damage_h.nss]].

==== Бонус к шансу нанесения критического урона ====

* Критические удары увеличивают урон от обычного удара, добавляя к нему определенное фиксированное значение.
* Величина добавляемого значение регулируется предметами и эффектами. Аттрибуты персонажа на нее не влияют.
* Историческое примечание: раньше критический урон мог принимать значения 'вплоть до...', но позже стали использовать константую переменную, что позволяло предвидеть значение наносимого урона.
* Логику рассчета критического урона вы сможете понять, изучив [[combat_damage_h.nss#GetCriticalDamageModifier]].

==== Бонус к удару в спину ====

* Урон от удара в спине часто равен критическому урону, но на него также влияют некоторые таланты разбойника.
* Логику вы сможете понять, изучив [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]] и [[combat_damage_h.nss]].

[[Category: Scripts]]
[[Category:Translations_ru]]
{{Languages|Combat Rules}}

ABI base.xls/ru

2011-10-20T17:26:37Z

Silderon:

{{rupage|ABI base.xls|Способности|2DAs}}

Здесь есть 2DA-файлы со всеми талантами и заклинаниями из игры. Они определяют их названия, иконки, требования, и другие детали, описывающие их функцию (анимации, время перезарядки, и т. л.)

Лучший способ создания новых способностей, это копирование похожей способности и редактирования необходимых параметров.

Во время разработки Dragon Age, этот файл обновлялся автоматически из базы данных. Мы же можем редактировать его вручную.

== Рабочий лист ABI_Base ==

{{2da start|ABI_Base}}
{{2da column| label |string| Описания для игроков. Способности, ориентированные на предметы отображается в списке '''Активные способности'''.}}
{{2da column| namestrref |int| ID string-переменной, которая содержит название способности.}}
{{2da column| descstrref |int| ID string-переменной, которая содержит описание способности.}}
{{2da column| tooltipstrref |int| String Ref ID of the buff/deff format on mouse over. (Caution: Abilities with ID over 500000 is considered as debuff and will not take the format of normal buffs.) }}
{{2da column| strid_effect| int| ID-номер строчки, в которой содержится описания способности, которое можно увидеть при наведении мышки.}}
{{2da column| icon|string| Название иконки без расширения.}}
{{2da column| abilitytype | int|Тип способности. Смотрите [[abilitytype.xls]] и [[ABILITY_TYPE_*]], а константые переменные в [[2da_constants_h]]:
* 1 - талант
* 2 - заклинание
* 3 - умение
* 4 - предмет}}
{{2da column| abilitymode |int| }}
{{2da column| conditions |int| Флаги, которые определяют, какие условие должны выполняться, чтобы игрок мог использовать описанною способность:
* 1 - экипировано одноручное оружие
* 2 - экипирован щит
* 4 - экипировано дальнобойное оружие
* 8 - игрок находится за спиной цели
* 16 - активирован нужный режим
* 32 - использующий способность является человекообразным созданием
* 64 - dual wielding
* 128 - экипировано два оружия
* 256 - использующий способноть является псом.
* 512 - использующий является магом}}
{{2da column| condition_mode | int| Если значения условий(Conditions) равно 16, в этой колонке содержится ID-номер способности продолжительного действия, которая должна быть активирована перед использованием данной способности. }}
{{2da column| condition_group |int| Связь между способностями продолжительного действия. Используйте минимальное значение группы. Когда активна одна из связанных способностей, другие выключаются. }}
{{2da column| cost| float| Количество Маны\Выносливость, которое будет потрачено на использование способности.}}
{{2da column| costupkeep |float| Сколько маны\выносливости резервирует способность. (только способности продолжительного действия)}}
{{2da column| prereqability |int | ID-номер способности, которую нужно знать для изучания данной.}}
{{2da column| prereqlevel | int| Минимальный уровень персонажа для изучения способности.}}
{{2da column| prereqattribute | int | Какой аттрибут нужен для способности. Смотрите [[properties.xls]] for what this number maps to.}}
{{2da column| prereqattvalue | int | Минимальное значения указанного аттрибута, которое нужно для использования способности.}}
{{2da column| guitype | int | Категория способности. К примеру, "Создание" и "Основные". Смотрите [[guitypes.xls]].}}
{{2da column| targettype | int | Оператор, который определяет тип цели, которая может быть поражена способностью. Смотрите [[targettype.xls]] и [[Ability#Targeting Behavior]]}}
{{2da column| autotarget | int| Если TRUE, игра автоматически выберит цель способности, будь то друг или враг. }}
{{2da column| range | int| Область действия:
* 0 - ближний бой (прикасаясь к цели)
* 1 - заклинания ближнего расстояния (почти ближний бой)
* 2 - moderate spell range (заклинания с конусообразной областью действия)
* 3 - заклинания дальнего расстояния (расстояние действия равно расстоянии обнаружения противника)
* 4+ - очень большое расстояние}}
{{2da column| speed |int| Значение колонки определяет, как долго способность будет готовиться к использованию. 0 - сработает сразу, 1 - проиграется выбранная анимация. 2+ - над головой использующего будет создана полоса прогресса, после заполнения которой проиграется выбранная анимация, а затем сработет способность.}}
{{2da column| usetype |int | Является ли способность пассивной, способностью длительного действия или одноразовой. Смотрите [[abilityusetype.xls]]:
* 2 - sustained
* 3 - пассивные
* 4 - activated}}
{{2da column| spellscript |string| Скрипт, который запустится после использования способности. Расширения скрипта типа ".ncs" также сработают.}}
{{2da column| cooldown | float | Время восстановления способности в секундах.}}
{{2da column| conjurevfx | int| Визуальный(VFX) эффект, который проигрывается во время подготовки и наложения заклинания.. Значения определены в [[VFX_base.xls]].}}
{{2da column| blendtree | string| Устанавливается для способностей, которые требуют изменения стандартных анимаци игрока или сопартийца. К примеру во время использования способности "Стена щита" персонаж занимает защитную позицию и прикрывается щитом.}}
{{2da column| conjureanim | int | Анимация, которая проигрывается во время подготовки заклинания. Список возможных значений расположен здесь [[ANIM_base.xls]].}}
{{2da column| castanim | int | Анимация, которая проигрывается во время наложения заклинания. Список возможных значений расположен здесь [[ANIM_base.xls]].}}
{{2da column| projectile | int | Название используемых снарядов. Смотрите [[PRJ_base.xls]]. 1 - стрела.}}
{{2da column| autocancel | int| Устаревшее }}
{{2da column| autodraw |int| Определяет поведение способности по отношению к оружие. 0 - способность игнорирует состояние оружия, 1 - перед использованием способности оружие нужно вытянуть, 2 - перед использованием оружие нужно вложить в ножны.
Значение любого заклинания со скоростью больше, чем 1, должно быть равно 2. The sheathing animation occurs during the conjure sequence without slowing it down, and putting away the weapon will prevent clipping.}}
{{2da column| threat_use|float| Устаревшее}}
{{2da column| threat_impact|float| Урон,наносимый каждый ударом. Использовать не обязательно.}}
{{2da column| aoe_type|int| 1 - круг, 2 - конус.}}
{{2da column| aoe_idx|int| Определяет области действия. Расположены в [[VFX_base.xls]].}}
{{2da column| aoe_param1 |float| Радиус круга действия или размер конуса.}}
{{2da column| aoe_param2 |float| Устаревшее}}
{{2da column| vfx_impact0| int| Визуальный(VFX) эффект, который проигрывается при каждом ударе. [[VFX_base.xls]]. Смотрите [[Ability_GetImpactLocationVfxId]]}}
{{2da column| vfx_impact1|int| Не используется движком, но может быть использовано в качестве константы в скриптах. При помощи этого параметра многие ПРЕДМЕТЫ удерживает свой VFX-эффект. Смотрите [[Ability_GetImpactObjectVfxId]]
Как правило, используется для длительных способностей или способностей продолжительного действия. Указывается на VFX-эффект, который будет использован.}}
{{2da column| flags |int| Установить значение 1 для способности, которая использует анимации атаки с оружие дальнего боя, значение 64 для способностей длительного действия, которые выключаются когда у существа заканчивается выносливость, 128 для снятия заклинания с субъекта (?), значение 192 для способностей длительного действия, которые выключаются когда у существа заканчивается мана }}
{{2da column| showintactics| int| Установите значение 1 тем способностям, которые герой или его сопартийцы захотят использовать в тактической системе.}}
{{2da column| showinchargen |int| Возможные значения:
* 1 - {{undocumented}}
* 2 - показывать только в окне генерации персонажа
* 4 - показывать в таланте\заклинании\навыке\книге
Если вы, к примеру, установите значение 7, будет отображаться и в окне генерации, и в таланте\заклинании\навыке\книге}}
{{2da column| passive_id |int| Соответствует ID-номеру способности в листе passive_abilities документа [[ABI_base.xls]]. }}
{{2da column| crust_id | int| Устаревшее}}
{{2da column| resistance |int | {{undocumented}} }}
{{2da column| damageinfo | int| {{undocumented}} }}
{{2da column| condition_appgroup|int|{{undocumented}} }}
{{2da column| ProcessWithEvent | int| Если установить флаг в этой колонке, при применении способности будет запускаться и обрабатываться событие. Работает даже когда игра поставлена на паузу. Использовать осторожно.}}
{{2da column| fatigue | float | Если способность является способостью продолжительного действия, значения этой колонки определяет степень усталости в то время, как способность активна. }}
{{2da end}}

== Рабочий лист ability_data ==

{{2da start|ability_data}}
{{2da column| Label | comment | {{undocumented}} }}
{{2da column| bHostileint | int | {{undocumented}} }}
{{2da column| effectImpact | int | {{undocumented}} }}
{{2da column| effectResisted| int | {{undocumented}} }}
{{2da column| effectDuration| float |
* positive: temporary
* 0.0 instant
* negative permanent }}
{{2da column| dmg_function | int | {{undocumented}} }}
{{2da column| dmg_param0 | float | {{undocumented}} }}
{{2da column| dmg_param1| int | {{undocumented}} }}
{{2da column| dmg_type| int |
*const int DAMAGE_TYPE_INVALID - 0;
*const int DAMAGE_TYPE_PHYSICAL - 1;
*const int DAMAGE_TYPE_FIRE - 2;
*const int DAMAGE_TYPE_COLD - 3;
*const int DAMAGE_TYPE_ELECTRICITY - 4;
*const int DAMAGE_TYPE_POISON - 5;
*const int DAMAGE_TYPE_LETHAL - 6;
*const int DAMAGE_TYPE_TBD - 7;}}
{{2da column| dmg_flags | int |
*const int DAMAGE_EFFECT_FLAG_NONE - 0x00000000 ;
*const int DAMAGE_EFFECT_FLAG_CRITICAL - 0x00000001; //критический удар
*const int DAMAGE_EFFECT_FLAG_DEATHBLOW - 0x00000002; //фаталити
*const int DAMAGE_EFFECT_FLAG_UPDATE_GORE - 0x00000004; //на атакующем существе появляется кровь
*const int DAMAGE_EFFECT_FLAG_LEECH_50 - 0x00000008; //возвращает атакующему 50% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_75 - 0x00000010; //возвращает атакующему 75% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_100 - 0x00000020; //возвращает атакующему 100% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_MANA - 0x00000040; //возвращает ману вместо жизни}}
{{2da end}}

== Рабочий лист ability_effects (эффекты способностей) ==

{{2da start|ability_effects}}
{{2da column| Label| string | {{undocumented}} }}
{{2da column| effect| int | {{undocumented}} }}
{{2da column| effect_label| comment | {{undocumented}} }}
{{2da column| effect_int1| int | {{undocumented}} }}
{{2da column| effect_int2| int | {{undocumented}} }}
{{2da column| effect_int3| int | {{undocumented}} }}
{{2da column| effect_float0| float | {{undocumented}} }}
{{2da column| effect_float1| float | {{undocumented}} }}
{{2da column| effect_object0 |int|
* 0 - не установлено
* 1 - set to OBJECT_SELF
* 2 - set to caster}}
{{2da column| scaled_field |int|
*0 - none
* 1 - float0
* 2 - float1}}
{{2da column| vfx| int | {{undocumented}} }}
{{2da column| resistance| int |
*const int PROPERTY_ATTRIBUTE_RESISTANCE_MENTAL - 32;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_AVOIDANCE - 31;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_PHYSICAL - 33;}}
{{2da end}}

== Рабочий лист passive_abilities (пассивных способностей) ==

{{2da start|passive_abilities}}
{{2da column| Label | comment | }}
{{2da column| Prop1 |int| Ссылка на [[properties.xls]]}}
{{2da column| Modifier1|float| Этот модификатор применяет способность только на персонажа-владельца.}}
{{2da column| Prop2| int | }}
{{2da column| Modifier2| float | }}
{{2da column| Prop3| int | }}
{{2da column| Modifier3| float | }}
{{2da column| Comment| comment | Итог способности в читабельной форме. }}
{{2da end}}

[[Category:XLS files]]
[[Category:Abilities]]
[[Category:Translations_ru]]
{{Languages|ABI_base.xls}}

Script error/ru

2011-10-20T17:12:04Z

Silderon:

{{Infobox script/ru}}

На данный момент в этой статье описываются ошибки выполнения скрипта. Ошибки в процессе компиляции пока не описаны.

== Ошибки ==
Всего существует два типа ошибок:

* Ошибки выполнения (недостающие файлы и тому подобное)
* Ошибки стека (переполнение, недостаточное наполнение, деление на 0 и тому подобное)

=== Ошибки выполнения ===

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

==== Ошибка запуска ====

*'''Сообщение: ''' "''<recursion level> Script failed to run: (filename)''" (Скрипту не удалось запуститься)
*'''Причина: ''' Зачастую скрипт попросту не существует.
*'''Решение: '''

==== Ошибка чтения ====

*'''Сообщение: ''' "''Error: Failed to read script file''" (Ошибка: не удалось прочитать файл скрипта)
*'''Причина: ''' Общее сообщение для всех неизвестных ошибок. Вводит в заблуждение, так как чаще всего файл считывается, но не обрабатывается.
*'''Решение: '''

==== Ошибка загрузки ====

*'''Сообщение: ''' "''Error: Script couldn't load''" (Ошибка: не удалось загрузить скрипт)
*'''Причина: ''' Общее сообщение для всех проблем, связанных с нечитаемостью игры.
*'''Решение: ''' Убедитесь, что скрипт был экспортирован в игру. Проверьте, есть ли он в папке toolsetexport соответсвующего модуля.

=== Ошибки стека / Неизвестные ошибки ===

Когда стек портится, игра выдаст одну из ошибок, описанных ниже. В таком случае нужно проверить журнал(лог) выполнения команд на наличие вниманий\ошибок возле недавно написанных скриптовых команд.

==== Стек переполнен ====

*'''Сообщение: ''' "''Stack Overflow in script: (filename)''" (Стек переполнен в скрипте: название_файла)
*'''Причина: ''' Стек был испорчен из-за слишком большого количества параметров движка.
*'''Решение: ''' Декларация команды в script.ldf может не совпадать с его реализацией в виртуальной машине. Проверьте на совместимость ваш '''exe'''шник и '''script.ldf'''. Локально обновите script.ldf (скопируйте его в папку '''/packages/core/override''' и перезапустите тулсет), после чего заново экспортируйте все скрипты.

==== Недополнение стека ====

*'''Сообщение: ''' "''Stack Underflow in script: (filename)''" (Стен недополнен в скрипте: название_скрипта)
*'''Причина: ''' Стек был испорчен в виду отсутствия значений всех его команд.
*'''Решение: ''' То же, что и в случае с переполнением.

==== Ошибки стека ====

*'''Сообщение: ''' "''Stack Error (code) in script: (filename) ''"
*'''Причина: ''' Смотрите список ошибок и их кодов ниже.

{|
|-
! Код || Причина || Решение
|-
|TOO_MANY_INSTRUCTIONS (632) ||The VM has terminated the offending script after executing the maximum number of instructions (131072). This is ALWAYS an error made by the scripter, most likely triggered by an infinite loop. ||Any script that manages to run even closely to the maximum number of allowed instructions is either broken or badly designed and needs to be rewritten with a more efficient design.||
|-
|TOO_MANY_RECURSION_LEVELS (633) ||The VM has terminated the offending script after hitting the maximum recursion level (8). This is always an error made by the scripter, often caused by layered HandleEvent calls ||Ensure the current event is handled earlier in the code and not propagated through a long chain of HandleEvents.||
|-
|CANNOT_READ_FILE (634) ||Скрипт не может быть прочитан. Скорее всего потому, что он не существует. Откройте нужный скрипт в тулсете и экспортируйте его||
|-
|STACK_OVERFLOW (638) || Компилятор ограничил скрипт, после того, как он испортил стек. ||О переполнении стека читайте выше.||
|-
|STACK_UNDERFLOW (639) || Компилятор ограничил скрипт, после того, как он испортил стек. ||О недополнении стека читайте выше..||
|-
|INVALID_COMMMAND (642) ||Компилятор засек вызов команды, неизвестной '''exe'''шнику. Возможно '''Script.ldf''' было обновлен командой, которая неизвестна текущему '''exe'''шнику. || Обновите ваш '''exe'''шник.
|-
|DIVISION_BY_ZERO (644) || В скрипте присутствует операция деления на 0 или же внутренняя команда не принимает 0 в качестве параметра (например команда Рандом(Random)). || Убедитесь, что параметры скрипта защищены от превращения в 0(например во время их считывания из '''2DA'''-файла). Найдите проблему с помощью проверки соответствующих лог-файлов. ('''FW_SCRIPT''' и '''FW_SCRIPT_COMMANDS''')||

|}

==== Определения ====

<pre>
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_INSTRUCTIONS 632
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_LEVELS_OF_RECURSION 633
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_OPENED 634
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_COMPILED_SUCCESSFULLY 635
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_AUX_CODE 636
#define STRREF_VIRTUALMACHINE_ERROR_NULL_VIRTUAL_MACHINE_NODE 637
#define STRREF_VIRTUALMACHINE_ERROR_STACK_OVERFLOW 638
#define STRREF_VIRTUALMACHINE_ERROR_STACK_UNDERFLOW 639
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_OP_CODE 640
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_EXTRA_DATA_ON_OP_CODE 641
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_COMMAND 642
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_SHORTCUT_LOGICAL_OPERATION 643
#define STRREF_VIRTUALMACHINE_ERROR_DIVIDE_BY_ZERO 644
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_ABORT_SCRIPT 645
#define STRREF_VIRTUALMACHINE_ERROR_IP_OUT_OF_CODE_SEGMENT 646
#define STRREF_VIRTUALMACHINE_ERROR_COMMAND_IMPLEMENTER_NOT_SET 647
#define STRREF_VIRTUALMACHINE_ERROR_UNKNOWN_TYPE_ON_RUN_TIME_STACK 648
#define STRREF_VIRTUALMACHINE_ERROR_ARRAY_ACCESS_OUT_OF_BOUNDS 649
</pre>

{{Languages|Script error}}
[[Category:Translations_ru]]
[[Category:Scripts]]
[[Category:Error messages]]

Script error/ru

2011-10-20T17:07:05Z

Silderon:

{{Infobox script}}

На данный момент в этой статье описываются ошибки выполнения скрипта. Ошибки в процессе компиляции пока не описаны.

== Ошибки ==
Всего существует два типа ошибок:

* Ошибки выполнения (недостающие файлы и тому подобное)
* Ошибки стека (переполнение, недостаточное наполнение, деление на 0 и тому подобное)

=== Ошибки выполнения ===

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

==== Ошибка запуска ====

*'''Сообщение: ''' "''<recursion level> Script failed to run: (filename)''" (Скрипту не удалось запуститься)
*'''Причина: ''' Зачастую скрипт попросту не существует.
*'''Решение: '''

==== Ошибка чтения ====

*'''Сообщение: ''' "''Error: Failed to read script file''" (Ошибка: не удалось прочитать файл скрипта)
*'''Причина: ''' Общее сообщение для всех неизвестных ошибок. Вводит в заблуждение, так как чаще всего файл считывается, но не обрабатывается.
*'''Решение: '''

==== Ошибка загрузки ====

*'''Сообщение: ''' "''Error: Script couldn't load''" (Ошибка: не удалось загрузить скрипт)
*'''Причина: ''' Общее сообщение для всех проблем, связанных с нечитаемостью игры.
*'''Решение: ''' Убедитесь, что скрипт был экспортирован в игру. Проверьте, есть ли он в папке toolsetexport соответсвующего модуля.

=== Ошибки стека / Неизвестные ошибки ===

Когда стек портится, игра выдаст одну из ошибок, описанных ниже. В таком случае нужно проверить журнал(лог) выполнения команд на наличие вниманий\ошибок возле недавно написанных скриптовых команд.

==== Стек переполнен ====

*'''Сообщение: ''' "''Stack Overflow in script: (filename)''" (Стек переполнен в скрипте: название_файла)
*'''Причина: ''' Стек был испорчен из-за слишком большого количества параметров движка.
*'''Решение: ''' Декларация команды в script.ldf может не совпадать с его реализацией в виртуальной машине. Проверьте на совместимость ваш '''exe'''шник и '''script.ldf'''. Локально обновите script.ldf (скопируйте его в папку '''/packages/core/override''' и перезапустите тулсет), после чего заново экспортируйте все скрипты.

==== Недополнение стека ====

*'''Сообщение: ''' "''Stack Underflow in script: (filename)''" (Стен недополнен в скрипте: название_скрипта)
*'''Причина: ''' Стек был испорчен в виду отсутствия значений всех его команд.
*'''Решение: ''' То же, что и в случае с переполнением.

==== Ошибки стека ====

*'''Сообщение: ''' "''Stack Error (code) in script: (filename) ''"
*'''Причина: ''' Смотрите список ошибок и их кодов ниже.

{|
|-
! Код || Причина || Решение
|-
|TOO_MANY_INSTRUCTIONS (632) ||The VM has terminated the offending script after executing the maximum number of instructions (131072). This is ALWAYS an error made by the scripter, most likely triggered by an infinite loop. ||Any script that manages to run even closely to the maximum number of allowed instructions is either broken or badly designed and needs to be rewritten with a more efficient design.||
|-
|TOO_MANY_RECURSION_LEVELS (633) ||The VM has terminated the offending script after hitting the maximum recursion level (8). This is always an error made by the scripter, often caused by layered HandleEvent calls ||Ensure the current event is handled earlier in the code and not propagated through a long chain of HandleEvents.||
|-
|CANNOT_READ_FILE (634) ||Скрипт не может быть прочитан. Скорее всего потому, что он не существует. Откройте нужный скрипт в тулсете и экспортируйте его||
|-
|STACK_OVERFLOW (638) || Компилятор ограничил скрипт, после того, как он испортил стек. ||О переполнении стека читайте выше.||
|-
|STACK_UNDERFLOW (639) || Компилятор ограничил скрипт, после того, как он испортил стек. ||О недополнении стека читайте выше..||
|-
|INVALID_COMMMAND (642) ||Компилятор засек вызов команды, неизвестной '''exe'''шнику. Возможно '''Script.ldf''' было обновлен командой, которая неизвестна текущему '''exe'''шнику. || Обновите ваш '''exe'''шник.
|-
|DIVISION_BY_ZERO (644) || В скрипте присутствует операция деления на 0 или же внутренняя команда не принимает 0 в качестве параметра (например команда Рандом(Random)). || Убедитесь, что параметры скрипта защищены от превращения в 0(например во время их считывания из '''2DA'''-файла). Найдите проблему с помощью проверки соответствующих лог-файлов. ('''FW_SCRIPT''' и '''FW_SCRIPT_COMMANDS''')||

|}

==== Определения ====

<pre>
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_INSTRUCTIONS 632
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_LEVELS_OF_RECURSION 633
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_OPENED 634
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_COMPILED_SUCCESSFULLY 635
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_AUX_CODE 636
#define STRREF_VIRTUALMACHINE_ERROR_NULL_VIRTUAL_MACHINE_NODE 637
#define STRREF_VIRTUALMACHINE_ERROR_STACK_OVERFLOW 638
#define STRREF_VIRTUALMACHINE_ERROR_STACK_UNDERFLOW 639
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_OP_CODE 640
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_EXTRA_DATA_ON_OP_CODE 641
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_COMMAND 642
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_SHORTCUT_LOGICAL_OPERATION 643
#define STRREF_VIRTUALMACHINE_ERROR_DIVIDE_BY_ZERO 644
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_ABORT_SCRIPT 645
#define STRREF_VIRTUALMACHINE_ERROR_IP_OUT_OF_CODE_SEGMENT 646
#define STRREF_VIRTUALMACHINE_ERROR_COMMAND_IMPLEMENTER_NOT_SET 647
#define STRREF_VIRTUALMACHINE_ERROR_UNKNOWN_TYPE_ON_RUN_TIME_STACK 648
#define STRREF_VIRTUALMACHINE_ERROR_ARRAY_ACCESS_OUT_OF_BOUNDS 649
</pre>

{{Languages|Script error}}
[[Category:Translations_ru]]
[[Category:Scripts]]
[[Category:Error messages]]

Script error

2011-10-20T17:02:04Z

Silderon:

{{Infobox script}}

Currently this document covers errors when executing a script at run-time. Compilation errors aren't covered yet.

== Errors ==
There are two general types of errors that can happen:

* Execution Errors (File missing, etc.)
* Stack Errors (Overflows, Underflows, Division by 0, etc.)

=== Execution Errors ===

General execution errors often involve the script not being present in the game or other general problems preventing the vm from processing the script correctly.

==== Failure to Run ====

*'''Message: ''' "''<recursion level> Script failed to run: (filename)''"
*'''Reason: ''' Often the script does not actually exist.
*'''Solution: '''

==== Failure to Read ====

*'''Message: ''' "''Error: Failed to read script file''"
*'''Reason: ''' This is a generic message that shows up for all non specific errors. It's kind of misleading as the file might be read fine from disk but otherwise fail to execute.
*'''Solution: '''

==== Failure to Load ====

*'''Message: ''' "''Error: Script couldn't load''"
*'''Reason: ''' This is a generic message that shows up for all problems where the game could not be read.
*'''Solution: ''' Make sure the script file was properly exported to the game by manually checking if it resides in the toolset export directory for the module.

=== Stack Errors / Unknown Error ===

When the stack gets corrupted, the game will produce one of the errors listed below. A good first step for any stack related problems is to check the ExecuteCommand channel for warnings/error messages near recently implemented scripting commands.

==== Stack Overflow ====

*'''Message: ''' "''Stack Overflow in script: (filename)''"
*'''Reason: ''' The stack got corrupted by pushing too many parameters from the engine.
*'''Solution: ''' The declaration for the command in script.ldf and its implementation in the virtual machine may not match; check if you've got incompatible versions of script.ldf and the executable file. Update script.ldf locally (by copying into /packages/core/override and restarting the toolset) and reexport all scripts.

==== Stack Underflow ====

*'''Message: ''' "''Stack Underflow in script: (filename)''"
*'''Reason: ''' The stack got corrupted by not popping of all values of a command from the stack.
*'''Solution: ''' The same as for a stack overflow.

==== Stack Error ====

*'''Message: ''' "''Stack Error (code) in script: (filename) ''"
*'''Reason: ''' See common error codes listed below.

{|
|-
! Code || Reason || Solution
|-
|TOO_MANY_INSTRUCTIONS (632) ||The VM has terminated the offending script after executing the maximum number of instructions (131072). This is ALWAYS an error made by the scripter, most likely triggered by an infinite loop. ||Any script that manages to run even closely to the maximum number of allowed instructions is either broken or badly designed and needs to be rewritten with a more efficient design.||
|-
|TOO_MANY_RECURSION_LEVELS (633) ||The VM has terminated the offending script after hitting the maximum recursion level (8). This is always an error made by the scripter, often caused by layered HandleEvent calls ||Ensure the current event is handled earlier in the code and not propagated through a long chain of HandleEvents.||
|-
|CANNOT_READ_FILE (634) ||Script could not be read, probably because it didn't exist. Export scripts from toolset||
|-
|STACK_OVERFLOW (638) ||The VM has terminated the offending script after the stack was corrupted. ||See Stack Overflow above.||
|-
|STACK_UNDERFLOW (639) ||The VM has terminated the offending script after the stack was corrupted. ||See Stack Underflow above.||
|-
|INVALID_COMMMAND (642) ||The VM encountered a call to a command not known to the executable. Script.ldf was probably updated with a command that is not known to the current executable.|| Get an up to date executable. ||
|-
|DIVISION_BY_ZERO (644) ||A script has triggered a division by zero, either directly or inside a command not accepting a 0 parameter (e.g. Random) ||Ensure that the script is properly shielded against parameters becoming 0 (e.g. when read from a 2da). Find the location of the problem by checking the approriate log channels (FW_SCRIPT and FW_SCRIPT_COMMANDS)||
|}

==== Defines ====

<pre>
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_INSTRUCTIONS 632
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_LEVELS_OF_RECURSION 633
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_OPENED 634
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_COMPILED_SUCCESSFULLY 635
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_AUX_CODE 636
#define STRREF_VIRTUALMACHINE_ERROR_NULL_VIRTUAL_MACHINE_NODE 637
#define STRREF_VIRTUALMACHINE_ERROR_STACK_OVERFLOW 638
#define STRREF_VIRTUALMACHINE_ERROR_STACK_UNDERFLOW 639
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_OP_CODE 640
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_EXTRA_DATA_ON_OP_CODE 641
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_COMMAND 642
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_SHORTCUT_LOGICAL_OPERATION 643
#define STRREF_VIRTUALMACHINE_ERROR_DIVIDE_BY_ZERO 644
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_ABORT_SCRIPT 645
#define STRREF_VIRTUALMACHINE_ERROR_IP_OUT_OF_CODE_SEGMENT 646
#define STRREF_VIRTUALMACHINE_ERROR_COMMAND_IMPLEMENTER_NOT_SET 647
#define STRREF_VIRTUALMACHINE_ERROR_UNKNOWN_TYPE_ON_RUN_TIME_STACK 648
#define STRREF_VIRTUALMACHINE_ERROR_ARRAY_ACCESS_OUT_OF_BOUNDS 649
</pre>

{{Languages|Script error}}

[[Category:Scripts]]
[[Category:Error messages]]

Script error/ru

2011-10-20T17:00:56Z

Silderon:

Script error/ru

2011-10-20T16:59:16Z

Silderon:

Script error/ru

2011-10-20T16:56:32Z

Silderon: Created page with "{{Infobox script}} На данный момент в этой статье описываются ошибки выполнения скрипта. Ошибки в процес..."

{{Infobox script}}

На данный момент в этой статье описываются ошибки выполнения скрипта. Ошибки в процессе компиляции пока не описаны.

== Ошибки ==
Всего существует два типа ошибок:

* Ошибки выполнения (недостающие файлы и тому подобное)
* Ошибки стека (переполнение, недостаточное наполнение, деление на 0 и тому подобное)

=== Ошибки выполнения ===

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

==== Ошибка запуска ====

*'''Сообщение: ''' "''<recursion level> Script failed to run: (filename)''" (Скрипту не удалось запуститься)
*'''Причина: ''' Зачастую скрипт попросту не существует.
*'''Решение: '''

==== Ошибка чтения ====

*'''Сообщение: ''' "''Error: Failed to read script file''" (Ошибка: не удалось прочитать файл скрипта)
*'''Причина: ''' Общее сообщение для всех неизвестных ошибок. Вводит в заблуждение, так как чаще всего файл считывается, но не обрабатывается.
*'''Решение: '''

==== Ошибка загрузки ====

*'''Сообщение: ''' "''Error: Script couldn't load''" (Ошибка: не удалось загрузить скрипт)
*'''Причина: ''' Общее сообщение для всех проблем, связанных с нечитаемостью игры.
*'''Решение: ''' Убедитесь, что скрипт был экспортирован в игру. Проверьте, есть ли он в папке toolsetexport соответсвующего модуля.

=== Ошибки стека / Неизвестные ошибки ===

Когда стек портится, игра выдаст одну из ошибок, описанных ниже. В таком случае нужно проверить журнал(лог) выполнения команд на наличие вниманий\ошибок возле недавно написанных скриптовых команд.

==== Стек переполнен ====

*'''Сообщение: ''' "''Stack Overflow in script: (filename)''" (Стек переполнен в скрипте: название_файла)
*'''Причина: ''' Стек был испорчен из-за слишком большого количества параметров движка.
*'''Решение: ''' Декларация команды в script.ldf может не совпадать с его реализацией в виртуальной машине. Проверьте на совместимость ваш exeшник и script.ldf. Локально обновите script.ldf (скопируйте его в папку /packages/core/override и перезапустите тулсет), после чего заново экспортируйте все скрипты.

==== Недополнение стека ====

*'''Сообщение: ''' "''Stack Underflow in script: (filename)''" (Стен недополнен в скрипте: название_скрипта)
*'''Причина: ''' Стек был испорчен в виду отсутствия значений всех его команд.
*'''Решение: ''' То же, что и в случае с переполнением.

==== Ошибки стека ====

*'''Сообщение: ''' "''Stack Error (code) in script: (filename) ''"
*'''Причина: ''' Смотрите список ошибок и их кодов ниже.

{|
|-
! Код || Причина || Решение
|-
|TOO_MANY_INSTRUCTIONS (632) ||The VM has terminated the offending script after executing the maximum number of instructions (131072). This is ALWAYS an error made by the scripter, most likely triggered by an infinite loop. ||Any script that manages to run even closely to the maximum number of allowed instructions is either broken or badly designed and needs to be rewritten with a more efficient design.||
|-
|TOO_MANY_RECURSION_LEVELS (633) ||The VM has terminated the offending script after hitting the maximum recursion level (8). This is always an error made by the scripter, often caused by layered HandleEvent calls ||Ensure the current event is handled earlier in the code and not propagated through a long chain of HandleEvents.||
|-
|CANNOT_READ_FILE (634) ||Скрипт не может быть прочитан. Скорее всего потому, что он не существует. Откройте нужный скрипт в тулсете и экспортируйте его||
|-
|STACK_OVERFLOW (638) || Компилятор ограничил скрипт, после того, как он испортил стек. ||Смотрите передополнение стека выше.||
|-
|STACK_UNDERFLOW (639) || Компилятор ограничил скрипт, после того, как он испортил стек. ||Смотрите недополнение стека выше.||
|-
|INVALID_COMMMAND (642) ||Компилятор засек вызов команды, неизвестной exeшнику. Возможно Script.ldf было обновлен командой, которая неизвестна текущему exeшнику. || Обновите ваш exeшник.
|-
|DIVISION_BY_ZERO (644) || В скрипте присутствует операция деления на 0 или же внутренняя команда не принимает 0 в качестве параметра (например команда Рандом(Random)). || Убедитесь, что параметры скрипта защищены от превращения в 0(например во время их считывания из 2DA-файла). Найдите проблему с помощью проверки соответствующих лог-файлов. ('''FW_SCRIPT''' и '''FW_SCRIPT_COMMANDS''')||

|}

==== Определения ====

<pre>
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_INSTRUCTIONS 632
#define STRREF_VIRTUALMACHINE_ERROR_TOO_MANY_LEVELS_OF_RECURSION 633
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_OPENED 634
#define STRREF_VIRTUALMACHINE_ERROR_FILE_NOT_COMPILED_SUCCESSFULLY 635
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_AUX_CODE 636
#define STRREF_VIRTUALMACHINE_ERROR_NULL_VIRTUAL_MACHINE_NODE 637
#define STRREF_VIRTUALMACHINE_ERROR_STACK_OVERFLOW 638
#define STRREF_VIRTUALMACHINE_ERROR_STACK_UNDERFLOW 639
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_OP_CODE 640
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_EXTRA_DATA_ON_OP_CODE 641
#define STRREF_VIRTUALMACHINE_ERROR_INVALID_COMMAND 642
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_SHORTCUT_LOGICAL_OPERATION 643
#define STRREF_VIRTUALMACHINE_ERROR_DIVIDE_BY_ZERO 644
#define STRREF_VIRTUALMACHINE_ERROR_FAKE_ABORT_SCRIPT 645
#define STRREF_VIRTUALMACHINE_ERROR_IP_OUT_OF_CODE_SEGMENT 646
#define STRREF_VIRTUALMACHINE_ERROR_COMMAND_IMPLEMENTER_NOT_SET 647
#define STRREF_VIRTUALMACHINE_ERROR_UNKNOWN_TYPE_ON_RUN_TIME_STACK 648
#define STRREF_VIRTUALMACHINE_ERROR_ARRAY_ACCESS_OUT_OF_BOUNDS 649
</pre>

[[Category:Scripts]]
[[Category:Error messages]]

Combat Rules

2011-10-08T11:32:48Z

Silderon:

{{Infobox script}}

'''This page is work in progress'''

This page describes the technical implementation and flow of combat logic in the game scripts.
It deals mostly with weapon based combat, for spells and abilities, please see [[Ability|Abilities]].

Note: The term 'property' used on this page refers to [[Creature Properties]].

== Detailed Description ==

Combat in Dragon Age: Origin is handled mainly through scripts - the game engine itself has little knowledge of rule concepts such as 'Strength', 'Damage Modifier' or 'Armor Penetration'.

=== Hit Resolution ===

Hit resolution is implemented in the function [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] in the script library [[combat_h.nss]], which is invoked from the [[creature_core.nss]] script whenever an attack event is received. The function returns one of several [[COMBAT_RESULT|COMBAT_RESULT_*]] constants and handles messaging to the game engine which animation to play.

Overall, Dragon Age: Origin's combat system is 'hit heavy' as a target's armor does not modify its chance of getting hit.

The simplified decision tree for to hit resolution is as follows:

<dascript>

if Target Is Placeable Object
return COMBAT_RESULT_HIT

if Target Displacement/Dodge < RandomF(100.0)
return COMBAT_RESULT_MISS

if Attacker Is Using BASE_ITEM_TYPE_STAFF
return COMBAT_RESULT_HIT

bHit = RandomF(100.0) < AttackRating - DefenseRating
bCrit = CheckCricital()
bBackstab = CheckBackstab()

if bHit
if HasEffect(attacker, EFFECT_TYPE_MISDIRECTION_HEX)
if bCrit
return COMBAT_RESULT_HIT
else
return COMBAT_RESULT_MISS

if bBackstab
return COMBAT_RESULT_BACKSTAB
else
if bCrit
return COMBAT_RESULT_CRITICAL_HIT
else
return COMBAT_RESULT_HIT

else
return COMBAT_RESULT_MISS

</dascript>

==== Attack Rating ====

Attack rating includes:

* Base attack value (54.0f)
* + [[#Flanking Bonus Determination|Flanking Bonus]] (position based, modified by attacker and enemy talents and effects as well as shields. Rogues have a bonus here).
* + Distance based penalties (for ranged attacks)
* + Attacker's attack property value (this includes modifiers from buffs, etc.)
* + Any +attack item bonuses on the weapon that performs the attack.
* + Any external bonuses or penalties passed into the function (from talent scripts, etc.)
* + Difficulty setting based modifications

==== Defense Rating ====

Defense rating includes:

* Defender defense value (and missile deflection if attack was ranged). This includes items, effects and magical bonus.
* Difficulty setting based modifications

==== Flanking Bonus Determination ====

* Flanking bonus is a floating point value that applies to both AttackRating and to the chance to score a critical hit.
* It is essentially a representation of how close the character is to the best position when attacking the enemy (directly in the back)
* Various shield abilities on the target reduce or prevent the attacker from getting the bonus.
* The further away the character is from that position, the more the bonus is diluted.
* The magnitude of the bonus ranges from +0 to +15 (+20 with combat_movement) and is applied to AttackRating and partially (1+(FlankingBonus/5)) to critical hit chance.
* Most characters only flank 60 degrees in each direction, combat movement allows an increase to 90 degrees (the full back 180).
* Only rogues get the full flanking bonus, everyone else still gets half.
* The full logic is implemented in the function [[combat_h.nss#Combat_GetFlankingBonus|Combat_GetFlankingBonus]] in [[combat_h.nss]].

==== Backstab Determination ====

* Backstab is determined for each melee attack only.
* Backstab requires the attacker to have a flanking bonus > 0 (some talents waive this restriction)
* Only creatures with the Rogue [[Classes|Character Class]] may backstab. This is a class benefit.
* Only humanoid attackers can backstab (this includes darkspawn)
* The full logic is implemented in the function [[combat_h.nss#Combat_CheckBackstab|Combat_CheckBackstab]] in [[combat_h.nss]].
* The damage logic is implemented in [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]].

==== Critical Hit Determination ====

* Critical Hit Chance uses the attackers Melee or Ranged critical hit modifier based on attack type.
* + the attacking weapon's critical hit modifier stat.
* + 1.20x (1.1x for non rogues) the attacker's [[#Flanking Bonus Determination|Flanking Bonus]] in the current situation.
* + 3.5 for each enemy past the 2nd that is fighting a warrior with the bravery talent.
* A critical hit occurs when the resulting CriticalHitChance is smaller than RandomFloat()*100.0f.
* Certain effects and spells (e.g. Death Hex) can always override the result, as will attacking from stealth (always hits critical).
* The logic is implemented in the function [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] in the script library [[combat_h.nss]]

=== Damage Resolution ===

Damage resolution logic is implemented in the script [[combat_damage_h.nss]].

==== Critical Hit Damage Modification ====

* Critical hits increase the amount of damage done by an attack by a fixed multiplier.
* The magnitude of the multiplier can be affected by items and effects, but is not affected by any of the character's attributes.
* Historical Note: Critical damage used to be variable 'up to...', but was changed to constant to provide a more predictable flow of damage.
* The logic for critical damage is implemented in [[combat_damage_h.nss#GetCriticalDamageModifier]].

==== Backstab Damage Modification ====

* Backstab damage is essentially identical to critical damage, but modified by certain rogue talents.
* The full logic is implemented [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]] in [[combat_damage_h.nss]].

[[Category: Scripts]]
{{Languages|Combat Rules}}

Combat Rules/ru

2011-10-08T11:32:28Z

Silderon:

{{Infobox script}}

'''Страница в процессе доработки'''

На этой странице описаны техническая составляющая и логика ведения боя в игровых скриптах.
В основном она касается боя с использованием исключительно оружия. О заклинаниях и способностях читайте [[Ability|Abilities]].

Примечание: Термин 'свойтсва', используемый на этой страницы относиться к свойствам существ здесь -> [[Creature Properties]].

== Детальное описание ==

Бой в игре Dragon age: Начало обрабатывается в основном скриптами. Движок имеет малое понятие об основных показателях, вляющих на бой, таких как 'Сила' 'Модификатор урона' или 'Пробиваемость доспеха'.

=== Последствия удара ===

Последствия удара определены в функции [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] в библиотеке скриптов [[combat_h.nss]], которые срабатывают, когда скрипт [[creature_core.nss]] обрабатывает такое событие как удар. Функция возвращает одну или несколько [[COMBAT_RESULT|COMBAT_RESULT_*]] константных переменных и сообщает игровому движку, какую анимацию нужно проиграть.

В целом, боевая система Dragon age является 'тяжело ударной' так как доспех цели никак не влияет на шанс попадания.

Упрощенный скрипт для обработки последствий удара виглядит так:

<dascript>

if Target Is Placeable Object
return COMBAT_RESULT_HIT

if Target Displacement/Dodge < RandomF(100.0)
return COMBAT_RESULT_MISS

if Attacker Is Using BASE_ITEM_TYPE_STAFF
return COMBAT_RESULT_HIT

bHit = RandomF(100.0) < AttackRating - DefenseRating
bCrit = CheckCricital()
bBackstab = CheckBackstab()

if bHit
if HasEffect(attacker, EFFECT_TYPE_MISDIRECTION_HEX)
if bCrit
return COMBAT_RESULT_HIT
else
return COMBAT_RESULT_MISS

if bBackstab
return COMBAT_RESULT_BACKSTAB
else
if bCrit
return COMBAT_RESULT_CRITICAL_HIT
else
return COMBAT_RESULT_HIT

else
return COMBAT_RESULT_MISS

</dascript>

==== Мощность удара ====

Мощность удара включает в себя:

* Базовый наносимый урон (54.0f)
* + [[#Flanking Bonus Determination|Flanking Bonus]] (позиция атакующего относительно цели, умения жертвы, например, укрытие щитом. Здесь бонус получают разбойники).
* + Штрафы, основанные на расстоянии к цели (для дальнего боя)
* + Значение наносимого нападающим урона(вместе со всеми бафами и тому подобным)
* + Любые предметы(руны), которые являются частью оружия и влияют на нанесение урона
* + Любые внешние бонусы или штрафы, которые попадают в функцию (из скриптов умений, например)
* + Уровень сложности игры

==== Уровень защиты ====

Уровень защиты включает в себя:

* Значение защиты обороняющегося (и уклонения, если речь идет о защите от оружия дальнего боя). Включает в себя бонусы от предметов, эффектов и различные магические бонусы.
* Уровень сложности игры

==== Бонусы от атак с фланга ====

* Значение бонуса атак с фланга содержится во float-переменной и влияет на мощность атаки и шанс нанесения критического урона.
* Бонус зависит от того, насколько близко атакующий находится к наиболее выгодному для атаки положению(за спиной цели).
* Различные способности боя со щитом уменьшают вероятность атакующего получить бонус от атаки с фланга.
* Чем дальше атакующий от позиции "со спины", тем меньше бонус.
* Бонус колеблеться от +0 до +15 (+20 с "Движением в бою") и влияет на мощность атаки и частично на (1+(Бонус атаки со фланга/5)) на шанс нанесения критического урона.
* Большинство персонажей могут подойти к врагу максимум на 60 градусов относительно спины, "Движение с бою" позволяет подойти на 90 градусов (положение "со спины"=180 градусам).
* Максимальный бонус от атаки с фланга получают только разбойники, все остальные получают половину.
* Понять логику лучше вы сможете, изучив скрипт [[combat_h.nss#Combat_GetFlankingBonus|Combat_GetFlankingBonus]] и [[combat_h.nss]].

==== Удар в спину ====

* Удар в спину может быть нанесен только в ближнем бою.
* Для выполнения удара в спину нужно, чтобы бонус атаки с фланга был больше 0(некоторые таланты обходят это ограничение).
* Наносить удар в спину могут только создания класса Разбойник [[Classes|Character Class]]. Это классовая привилегия.
* Наносить удар в спину могут только человекоподобные существа (это касается и порождений тьмы).
* Общую логику вы сможете понять изучив функции [[combat_h.nss#Combat_CheckBackstab|Combat_CheckBackstab]] и [[combat_h.nss]].
* Логику нанесения урона вы сможете понять, изучив [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]].

==== Нанесение критического урона ====

* Нанести критический урон могут только бойцы дальнего и ближнего боя(не маги). Значение критического урона зависит от типа атаки.
* + бонус к критическому урону от используемого оружия.
* + 1.20x (1.1x для неразбойников) the attacker's [[#Flanking Bonus Determination|Flanking Bonus]] in the current situation.
* + 3.5 если атакующий сражается с двумя соратниками против одного и того же воина и использует талант "Храбрость".
* Критический урон наносится, когда шанс нанесения меньшый чем РандомнаяПеременая()*100.0f.
* Некоторые эффекты и заклинания (например Death Hex) делают каждый нанесенный удар критическим.
* Логику вы сможете понять, изучив функции [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] в скриптовой библиотеке [[combat_h.nss]]

=== Урон ===

Значение урона рассчитывается в скрипте [[combat_damage_h.nss]].

==== Бонус к шансу нанесения критического урона ====

* Критические удары увеличивают урон от обычного удара, добавляя к нему определенное фиксированное значение.
* Величина добавляемого значение регулируется предметами и эффектами. Аттрибуты персонажа на нее не влияют.
* Историческое примечание: раньше критический урон мог принимать значения 'вплоть до...', но позже стали использовать константую переменную, что позволяло предвидеть значение наносимого урона.
* Логику рассчета критического урона вы сможете понять, изучив [[combat_damage_h.nss#GetCriticalDamageModifier]].

==== Бонус к удару в спину ====

* Урон от удара в спине часто равен критическому урону, но на него также влияют некоторые таланты разбойника.
* Логику вы сможете понять, изучив [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]] и [[combat_damage_h.nss]].

[[Category: Scripts]]
== Переводчики ==
Silderon / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]
{{Languages|Combat Rules}}

Backgrounds tutorial/ru

2011-10-08T11:30:55Z

Silderon:

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете [http://social.bioware.com/project/4695/ скачать фикс] от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //извлечение с текущего события его типа
int nEventHandled = FALSE; //флаг, следящий за тем, было ли обработано события или нет.
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //предварительна загрузка ресурсов для генерации персонажа
StartCharGen(GetHero(),0,TRUE); //начало генерации
break;
}
default:
{
// -----------------------------------------------------------------
// Обработка отправленных движков события генерации персонажа.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //если событие не было обработано, оно отправляется в core-скрипт
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Отладка.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// Срабатывает, когда игрок кликает по иконке одной из доступных
// предысторий.
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Выбор предыстории для игрока и установка соответствующих предыстории
// plot-флагов.
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Проверяет шаблоны, указанные в 2DA-файлах
// и, руководствуясь ими создает герою инвентарь.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / то же самое
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Установка стандартный параметров для игрового персонажа.");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Установка переменной предыстории
// - создание внешности героя (или использование одной из заготовок)
//
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Игрок получает один навык.
// - найти нужный навык в файле backgrounds.xls
// - присвоить его игроку.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Установка plot-флагов расы: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// Сперва происходит инициализация всех флагов
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Tutorials]]
== Переводчики ==
Silderon / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]
{{Languages|Backgrounds tutorial}}
[[Category:Scripts]]

Combat Rules/ru

2011-10-08T11:30:33Z

Silderon: Created page with "{{Infobox script}} '''Страница в процессе доработки''' На этой странице описаны техническая составляющая ..."

Ability

2011-10-07T11:29:28Z

Silderon:

{{Infobox script}}

The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.

== Detailed Description ==

Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.

The most important 2da file for abilities is '''[[ABI_base.xls]]''', as it defines each ability and all aspects of execution and handling in both scripting and engine code.

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Ability Design Notes'''

When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines

* Keep it useful.
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow.
For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant trait (such as cunning for rogues) to ensure they stay useful throughout the game.

* No repetition.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.

* Thematic matching.
Abilities within the same chain should follow a common theme.

* Avoid binary abilities. Design hit heavy.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.

* Use meaningful effects
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.

* Avoid 'zero-sum' abilities
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.

* No emulation of defining class capabilities
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibility or magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades).

|}

=== Basic Ability Types ===

Abilities are divided into 4 subtypes, as defined in the 'abilitytype' column in [[ABI_base.xls]]:

* Talents - Abilities used by warriors and rogues, usually non magical in nature. (abilitytype=1)
* Spells - Abilities used by mages, either spell or passive abilities. (abilitytype=2)
* Skills - Abilities usable by all classes, such as Survival and Combat training (abilitytype=3).
* Items - Abilities present on an item that are triggered when the item is used on the quickbar. (ability_type=4)

Note: Talents do not show up on mages and spells do not show up on rogue or warrior characters, so to create abilities that can be used by all classes, abilitytype 3 (Skill) must be used. To define under which heading an ability shows up on the character's talent/spell page, the field 'guitype' is used. It resolves against [[guitype.xls]] which lists all known headings.

There are 3 basic ability types in the game, defined by the field 'use_type' in [[ABI_base.xls]].

'''Passive Abilities'''

Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.

A passive ability may grant up to 3 modifications to creature properties ([[properties.xls]]). Those modifications are defined in the passive_abilities worksheet of [[ABI_base.xls]] and linked to the ability through the passive_id column in ABI_base.xls.

Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.

Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids directly in the combat resolution scripts (e.g. HasAbility( oCreature, ABILITY_TALENT_LETHALITY )). The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.

Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.

'''Sustained Abilities'''

Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user.
Most 'buffs' are implemented this way.

Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).

Most sustained abilities follow the same pattern:
* They do not have any activation cost, encouraging tactical use of buffs.
* They increase the users [[Fatigue]] property, therefore increasing the activation cost of all other abilities.
* They reduce the users maximum available mana or stamina by a constant value.
* They use cooldown to prevent the user from being too opportunistic with their use.
* Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.

The benefits from sustained abilities are calculated when the ability is activated. So if a character levels up or otherwise changes stats that influence the magnitude of a sustained ability, they will not update until the ability is reactivated the next time.

Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in [[ABI_base.xls]]. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Gameplay Design Note'''
* Unlike in games like Baldur's Gate, the system in DA: Origins is designed to encourage tactical use of buffs over strategical. We wanted to put an emphasis on the player making smart choices during an encounter vs. the player guessing which buffs might be useful ahead of time or having to employ save-die-reload to find out.

* It is generally wise to run only one or two buffs all around and activate additional buffs only when needed.
|}

'''Activated Abilities'''

Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as

* Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
* Ground targeted abilities (such as Blizzard or various Glyphs)
* Self targeted activated abilities.

=== Targeting Behavior ===

An abilities targeting behavior is controlled by several settings in [[ABI_base.xls]]

'''AutoTarget''' is a boolean field that defines how the UI resolves targeting.

{| class="wikitable"
|-
! Value !! Effect
|-
| 0 || The UI will always bring up a targeting cursor.
|-
| 1 || The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting.
|}

Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -

'''TargetType''' is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.

{| class="wikitable"
|-
! Bitmask !! Effect
|-
| 0x1 || Self
|-
| 0x2 || Friendly Creature
|-
| 0x4 || Hostile Creature
|-
| 0x8 || Placeable Object
|-
| 0x10 || Area of Effect Object (deprecated)
|-
| 0x20 || Ground (see details)
|-
| 0x40 || Dead Body (deprecated)
|-
| 0x80 || Party Member
|}

'''AutoDraw''' is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.

{| class="wikitable"
|-
! Value !! Effect
|-
| 0 || The ability will not affect the player's weapon sheath status.
|-
| 1 || The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities.
|-
| 2 || The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly.
|}

=== Balancing (Cost, Cooldown, etc) ===

Abilities in Dragon Age are balanced along several vectors, most of which boil down to simple 'use frequency'. As a general rule of thumb, the more specialized and limited the effect of an ability is, the more outrageously powerful an ability can be.

Use frequency of abilities can be adjusted by modifying the following field in [[ABI_base.xls]]

* Cost: This is the simple mana (spells) or stamina (talents) activation cost of an ability. It is subtracted when the conjure phase of the spell has succesfully completed (e.g. no cost for spell interruptions). Without sufficient resources to cover activation cost, the UI will not allow the player to execute the ability. The value is a constant integer and is multiplied with 1+(Current Fatigue) of the caster.

* Cooldown: Cooldown is a constant float in seconds that defines how long the player has to wait after the successful activation of an ability until he can use it again. For abilities that apply duration based debuffs or effects to a target, cooldown is usually set slightly higher than the duration of the effect to avoid stacking by the same caster.

* Upkeep: Defines how much mana or stamina is removed from the casters overall pool while a sustained ability is active. This naturally limits the number of sustained abilities present on a creature and ensures that the more beneficial buffs are active on the caster, the less mana is available for immediate use.

* [[Fatigue]]: Fatigue affects use frequency only indirectly, but it prevents characters from stacking too many buffs on each other, as each sustained ability active usually adds around 5-10% fatigue to the caster.

* Mana/Stamina drain: By reducing the mana/stamina regeneration rate on a creature, the duration for which a sustained ability can be used can be restricted. This mechanic is used only for the most powerful sustained abilities in the game, which are flagged to turn off when the caster sustaining them reaches 0 mana/stamina.

Other balancing vectors:

* AoESize and AoeShape: Area of effect spells that deal friendly fire are location and situation restricted on normal+ difficulty (hard+ on the consoles). Since dropping an Inferno on your own party members is hardly a good idea in most cases, the usefulness of the spell becomes restricted to careful positioning and the earlier stages of combat.

* Threat Generation: Abilities apply threat not just by damage but often by activation. Higher activation threat of an ability can balance out outrageously powerful effects by making it harder for the player to use the spell. The prime example is the Walking Bomb kind of spells which deal excellent damage, but, on higher difficulties, also make the targets very very angry at the caster. Using these spells effectively often requires a tactical approach by the player, thus limiting their universal usefulness and offsetting their very powerful effects.

* Threat Removal: Some abilities are designed to only provide a short term benefit (Such as 3s stun on Mindblast) but offset their weakness by removing threat from the caster, often by reinitializing the threat tables on the target, causing enemies to randomly seek new targets.

* Conjure time: Spells with a conjure time of 1+ (Speed in [[ABI_base.xls]]) can be interrupted by damage, limiting their usefulness in melee situations or when only one party member remains on the battlefield. Many of the very powerful Area of Effect type spells use this feature. Most activated spells have a conjure time of 0, making them instant cast.

* Range: Lower ranges force the ability user into potentially more dangerous situations, adding additional risk to the use of an ability.

== Q&A ==

=== Q: Where do we find the exact formula for abilities ? ===

A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from [[ABI_base.xls]], a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.

This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:

Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.

=== Q: What is Spellpower and how does it interact with abilities ===

Spellpower is probably the most important stat for a mage character (and only exists on mage characters). It is calculated as max(Magic - 10,0) and therefore increases by one point for every point a mage spends on his Magic attribute.

Most mage spells benefit directly from higher spellpower by increased damage, effect magnitude and duration. It also plays a role in a mages ability to overcome mental or physical resistance on a target (where applicable). The actual impact of spellpower on an ability varies from spell to spell but the most common construct equates to something like 1% increase in spell potency per point of Spellpower. Thus, items and spells that increase spellpower are very powerful as they increase the potency of every spell the mage can cast.

Spellpower is the only factor that causes an increase of a spells potency over time, so a level 20 mage with neglected the Magic attribute would be much less powerful than a mage that didn't neglect Magic.

Some examples:

* The damage potential for Winter's Grasp is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.36f;
* The healing potential for the heal spell is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.40f;
* The damage over time component of blizzard is executed as ApplyEffectDamageOverTime(a[i], oCreator, ABILITY_SPELL_BLIZZARD, (100.0f + GetCreatureSpellPower(oCreator)) * 0.1, (BLIZZARD_INTERVAL_DURATION - 0.5f), DAMAGE_TYPE_COLD);

Note that these formulas only list the raw damage potential and do not take into account the effects of damage types, difficulty, rank, resistances, magical shields and any other mitigating factors on the target or enhancing factors on the caster. This means that just comparing the numbers will not give you an idea which spell is better or worse.

For non-mage spells and abilities, spellpower is often substituted by an appropriate other construct (such as max(Cunning-10,0) for rogue abilities).

=== Q: Can we have the damage formula for abilities ? ===

A: There is no damage formula for abilities, as mentioned before, each ability follows their own rules.

In general, talent damage is based on the weapon being used (e.g. Assault does 3 melee attacks that deal weapon damage with some additional bonuses) and are modified by external cirumstances such as location, critical chance and ability to deliver a backstab and are mitigated by armor on the target.

Spells deal damage of different damage types following a rough rule of (Constant * (Spellpower / Variable)) / [Variables] ) + Modifiers but this only tells part of the story as actual damage is dependent on the target, it's resistances, rank and a number of other factors.

Some additional factors affecting spell damage are:

* damage resistance.
* magical shields.
* difficulty level.
* elemental damage bonuses from spells or items
* Environmental conditions (frozen targets take less damage from fire, etc.)

=== Q: What are the differences between damage types? ===

A: Creatures have variable damage resistances based on their type and rank. Dragons might get 60% less damage from fire (60% fire resistance), other creatures will have different immunities. Additional effects are:

* Electricity: In addition to normal damage, these also reduce the targets stamina (but not mana) by the same amount, making them very effective boss killers.

* Fire: Cancels Cold based damage over time effects and applies damage over time.

* Cold: Cancel Fire based damage over time effects and often is accompanied by slow or slipping effects.

* Spirit: There are very few ways of increasing spirit resistance in the game, so spells dealing spirit damage are universally useful...

* Nature: Rarely found on spells. Many creatures are resistant to this.

(This should probably go on its own wiki page)

=== Q: Are sustained abilities mutually exclusive ? ===

A: There is a very limited number of sustained abilities that are mutually exclusive, usually because it makes sense. Mutually exclusive abilities cancel each other upon activation.

* Shield stances (Shield Wall, Shield Cover, Shield Defense) are mutually exclusive.
* Archery stances (Aim, Rapid Fire, Defensive Fire) are mutually exclusive.
* Shapeshifting forms (Sorry, no Bear-Wolfspider) are mutually exclusive.
* Weapon Enhancement spells are too, but only for the same caster (so two mages can run two different weapon enhancements if they want to).
* Bard Songs are mutually exclusive.
* The Death Syphon and Death Magic spells are mutually exclusive.

Technically, all abilities in [[ABI_base.xls]] that share the same 'condition_group' value are mutually exclusive.

=== Q: What are the rules for stacking effects and damage ? ===

A: The general rules of stacking for abilities are:

* Identical effect from different abilities stack (e.g. getting +10 attack from one ability and +10 attack from another nets +20 attack).
* The effects of identical abilities stack as long as they are from different caster. (Same caster usually does not apply as cooldown often exceeds duration).
* Weapon enhancement spells of the same type (e.g. 2 mages with flame weapons) do not stack. The sword does not get more flaming, sorry :)
* Animation based effects (knockdown, stun, etc.) stack, but only the one with the highest priority is played. This is defined in the priority column in [[effects.xls]].
* Glyphs do stack but there is a limit of 5 active glyphs per caster.
* Fire and Cold DoT effects do not stack, the spell cast last will cancel any existing spell of the opposite type.
* Fire and Cold AoEs cancel each other, other AoEs might interact rather violently, handle with care :)

For equipment and item based effects, the game usually stacks within the minumum and maximum clamp values of a property ([[properties.xls]]). This means that you can accumulate a lot of +damage or +critical critical chance effects, but for some stat types there is a point where you are no longer gaining any benefits (e.g. speed modification - animations can only be sped up to a certain point before breaking, so stacking momentum, haste and a weapon with a speed based effect will not result in a -3.0s attack time, sorry :p)

For almost all effects, the total result of all property modifications on a creature are visible on the main character UI by hovering over the individual stats.

=== Q: How does game difficulty affect abilities ? ===

A: Our approach to game difficulty dictates that the effect of your chosen setting are

* non punishing - You do not get less XP for chosing a lower difficulty mode, etc.
* challenge scaling - Higher difficulty will reward you with greater obstacles to overcome.
* fair - Lower difficulties grant benefits that gradually get removed. (This does not mean the rules are symmetric and is not true on nightmare at all. Nightmare is evil. And unfair.)
* non persistent - Difficulty changes are possible on the fly, at any time and take immediate effect.

The game is balanced so that Hard mode is challenging for a Baldur's gate veteran.

Based on these guidelines, you can expect the following ability behaviors in game:

* The lower the difficulty, the longer your hostile effects such as stuns will last on enemies and the shorter they will last on you.
* The lower the difficulty, the more damage your abilities will do.
* The lower the difficulty, the less likely the enemy AI will use devastating special abilities (Note: less likely does not mean 'does not use').
* Casual and Normal have reduced friendly or nullified fire damage damage from area effect spells. Hard and Nightmare require careful positioning and tactical use of spells.
* The higher the difficulty, the more careful you need to manage threat when using spells and abilities (The AI becomes smarter about picking targets).

=== Q: What is spell affinity ? ===

A: Spell Affinity was a design we toyed with for a while during development but decided not to implement.

=== Q: How does Rank Based Mitigation Work ? ===

A: In line with Dragon Age: Origin's asymmetric approach to rules, the game uses creature ranks (instead of levels) in addition to stats and resistances to define how creatures get affected by abilities. In short: Boss monsters get affected differently by abilities and effects than Lieutenants or Critters.

The rank system is the primary balancing vector for the games difficulty levels and profoundly affects all aspects of combat. The gory details of this system are defined in [[creature_ranks.xls]] and [[difficulty.xls]].

Rank mitigation affects not just damage in- and output of a creature, but also the duration that hostile effects persist on it and is different for each difficulty level of the game. Note that party members have their own rank in this system and are handled differently from other creatures in some cases.

Below is the formula used for rank based effect duration mitigation:

<dascript>
// sys_resistances_h
// @brief Returns an effect duration scaled by rank of oCreature and game difficulty
// @author Georg
float GetRankAdjustedEffectDuration(object oCreature, float fDur)
{

// -------------------------------------------------------------------------
// Georg: This deserves some explanation:
//
// One of the core issues when designing the combat system was always
// the fact that the story called for sequences during the game in which
// your main character acts solo.
//
// Characters reliant on special abilities, such as rogues, would require
// them to be very effective in order to beat enemies that a standard tank
// can plow through. However, if these abilities would maintain the same
// effectiveness in a full party, most encounters would turn into a stunfest.
//
// The solution is to add 1 second flat to each detrimental effect duration
// lasting at least 1 second for each unoccupied slot in the party - before applying
// rank and difficulty modifiers. This also makes solo play a bit more viable.
//
// This is in addition to the diminishing returns on quickly successive stuns.
//
// -------------------------------------------------------------------------
if (!IsPartyMember(oCreature))
{
float fPartySizeModifier = IntToFloat(Max(0,4 - GetArraySize(GetPartyList())));

if (fDur >= 1.0f)
{
fDur += fPartySizeModifier;
}
}

float fRankDurMod = Diff_GetDurationModifier(oCreature);
if (fRankDurMod >0.0f)
{
return (fDur * fRankDurMod);
}
else
{
return fDur;
}
}
</dascript>

=== Q: What does 'asymmetric rules system' mean ? ===

The goal behind Dragon Age: Origin's rule system was to create a fun and challenging video game experience first and foremost.

We describe the rules as 'asymmetric' because a subset of the game rules treats player controlled characters and monsters differently, which is a deviation from pen and paper rule design that often require player and opponents to be treated exactly the same.

Notable Examples:
* Party members never die permanently (get shattered, etc.)
* Differently ranked creatures (including party members) get affected for different durations by effects
* In limited situations in the game, we apply benefits to the player to overcome greater odds than they would usually be able to.
* Some abilities will work diferently when deployed against the party (although the visual results might be identical).
* Elimination of instant death situations (not fun!) against players but not against monsters (fun!).
* Sustained abilities only work for players (the overhead is not justified for monsters that won't ever reappear after they die).

[[Category:Abilities]]

{{Languages|Ability}}

Ability/ru

2011-10-07T11:29:02Z

Silderon:

Здесь есть 2DA-файлы со всеми талантами и заклинаниями из игры. Они определяют их названия, иконки, требования, и другие детали, описывающие их функцию (анимации, время перезарядки, и т. л.)

Лучший способ создания новых способностей, это копирование похожей способности и редактирования необходимых параметров.

Во время разработки Dragon Age, этот файл обновлялся автоматически из базы данных. Мы же можем редактировать его вручную.

== Рабочий лист ABI_Base ==

{{2da start|ABI_Base}}
{{2da column| label |string| Описания для игроков. Способности, ориентированные на предметы отображается в списке '''Активные способности'''.}}
{{2da column| namestrref |int| ID string-переменной, которая содержит название способности.}}
{{2da column| descstrref |int| ID string-переменной, которая содержит описание способности.}}
{{2da column| tooltipstrref |int| String Ref ID of the buff/deff format on mouse over. (Caution: Abilities with ID over 500000 is considered as debuff and will not take the format of normal buffs.) }}
{{2da column| strid_effect| int| ID-номер строчки, в которой содержится описания способности, которое можно увидеть при наведении мышки.}}
{{2da column| icon|string| Название иконки без расширения.}}
{{2da column| abilitytype | int|Тип способности. Смотрите [[abilitytype.xls]] и [[ABILITY_TYPE_*]], а константые переменные в [[2da_constants_h]]:
* 1 - талант
* 2 - заклинание
* 3 - умение
* 4 - предмет}}
{{2da column| abilitymode |int| }}
{{2da column| conditions |int| Флаги, которые определяют, какие условие должны выполняться, чтобы игрок мог использовать описанною способность:
* 1 - экипировано одноручное оружие
* 2 - экипирован щит
* 4 - экипировано дальнобойное оружие
* 8 - игрок находится за спиной цели
* 16 - активирован нужный режим
* 32 - использующий способность является человекообразным созданием
* 64 - dual wielding
* 128 - экипировано два оружия
* 256 - использующий способноть является псом.
* 512 - использующий является магом}}
{{2da column| condition_mode | int| Если значения условий(Conditions) равно 16, в этой колонке содержится ID-номер способности продолжительного действия, которая должна быть активирована перед использованием данной способности. }}
{{2da column| condition_group |int| Связь между способностями продолжительного действия. Используйте минимальное значение группы. Когда активна одна из связанных способностей, другие выключаются. }}
{{2da column| cost| float| Количество Маны\Выносливость, которое будет потрачено на использование способности.}}
{{2da column| costupkeep |float| Сколько маны\выносливости резервирует способность. (только способности продолжительного действия)}}
{{2da column| prereqability |int | ID-номер способности, которую нужно знать для изучания данной.}}
{{2da column| prereqlevel | int| Минимальный уровень персонажа для изучения способности.}}
{{2da column| prereqattribute | int | Какой аттрибут нужен для способности. Смотрите [[properties.xls]] for what this number maps to.}}
{{2da column| prereqattvalue | int | Минимальное значения указанного аттрибута, которое нужно для использования способности.}}
{{2da column| guitype | int | Категория способности. К примеру, "Создание" и "Основные". Смотрите [[guitypes.xls]].}}
{{2da column| targettype | int | Оператор, который определяет тип цели, которая может быть поражена способностью. Смотрите [[targettype.xls]] и [[Ability#Targeting Behavior]]}}
{{2da column| autotarget | int| Если TRUE, игра автоматически выберит цель способности, будь то друг или враг. }}
{{2da column| range | int| Область действия:
* 0 - ближний бой (прикасаясь к цели)
* 1 - заклинания ближнего расстояния (почти ближний бой)
* 2 - moderate spell range (заклинания с конусообразной областью действия)
* 3 - заклинания дальнего расстояния (расстояние действия равно расстоянии обнаружения противника)
* 4+ - очень большое расстояние}}
{{2da column| speed |int| Значение колонки определяет, как долго способность будет готовиться к использованию. 0 - сработает сразу, 1 - проиграется выбранная анимация. 2+ - над головой использующего будет создана полоса прогресса, после заполнения которой проиграется выбранная анимация, а затем сработет способность.}}
{{2da column| usetype |int | Является ли способность пассивной, способностью длительного действия или одноразовой. Смотрите [[abilityusetype.xls]]:
* 2 - sustained
* 3 - пассивные
* 4 - activated}}
{{2da column| spellscript |string| Скрипт, который запустится после использования способности. Расширения скрипта типа ".ncs" также сработают.}}
{{2da column| cooldown | float | Время восстановления способности в секундах.}}
{{2da column| conjurevfx | int| Визуальный(VFX) эффект, который проигрывается во время подготовки и наложения заклинания.. Значения определены в [[VFX_base.xls]].}}
{{2da column| blendtree | string| Устанавливается для способностей, которые требуют изменения стандартных анимаци игрока или сопартийца. К примеру во время использования способности "Стена щита" персонаж занимает защитную позицию и прикрывается щитом.}}
{{2da column| conjureanim | int | Анимация, которая проигрывается во время подготовки заклинания. Список возможных значений расположен здесь [[ANIM_base.xls]].}}
{{2da column| castanim | int | Анимация, которая проигрывается во время наложения заклинания. Список возможных значений расположен здесь [[ANIM_base.xls]].}}
{{2da column| projectile | int | Название используемых снарядов. Смотрите [[PRJ_base.xls]]. 1 - стрела.}}
{{2da column| autocancel | int| Устаревшее }}
{{2da column| autodraw |int| Определяет поведение способности по отношению к оружие. 0 - способность игнорирует состояние оружия, 1 - перед использованием способности оружие нужно вытянуть, 2 - перед использованием оружие нужно вложить в ножны.
Значение любого заклинания со скоростью больше, чем 1, должно быть равно 2. The sheathing animation occurs during the conjure sequence without slowing it down, and putting away the weapon will prevent clipping.}}
{{2da column| threat_use|float| Устаревшее}}
{{2da column| threat_impact|float| Урон,наносимый каждый ударом. Использовать не обязательно.}}
{{2da column| aoe_type|int| 1 - круг, 2 - конус.}}
{{2da column| aoe_idx|int| Определяет области действия. Расположены в [[VFX_base.xls]].}}
{{2da column| aoe_param1 |float| Радиус круга действия или размер конуса.}}
{{2da column| aoe_param2 |float| Устаревшее}}
{{2da column| vfx_impact0| int| Визуальный(VFX) эффект, который проигрывается при каждом ударе. [[VFX_base.xls]]. Смотрите [[Ability_GetImpactLocationVfxId]]}}
{{2da column| vfx_impact1|int| Не используется движком, но может быть использовано в качестве константы в скриптах. При помощи этого параметра многие ПРЕДМЕТЫ удерживает свой VFX-эффект. Смотрите [[Ability_GetImpactObjectVfxId]]
Как правило, используется для длительных способностей или способностей продолжительного действия. Указывается на VFX-эффект, который будет использован.}}
{{2da column| flags |int| Установить значение 1 для способности, которая использует анимации атаки с оружие дальнего боя, значение 64 для способностей длительного действия, которые выключаются когда у существа заканчивается выносливость, 128 для снятия заклинания с субъекта (?), значение 192 для способностей длительного действия, которые выключаются когда у существа заканчивается мана }}
{{2da column| showintactics| int| Установите значение 1 тем способностям, которые герой или его сопартийцы захотят использовать в тактической системе.}}
{{2da column| showinchargen |int| Возможные значения:
* 1 - {{undocumented}}
* 2 - показывать только в окне генерации персонажа
* 4 - показывать в таланте\заклинании\навыке\книге
Если вы, к примеру, установите значение 7, будет отображаться и в окне генерации, и в таланте\заклинании\навыке\книге}}
{{2da column| passive_id |int| Соответствует ID-номеру способности в листе passive_abilities документа [[ABI_base.xls]]. }}
{{2da column| crust_id | int| Устаревшее}}
{{2da column| resistance |int | {{undocumented}} }}
{{2da column| damageinfo | int| {{undocumented}} }}
{{2da column| condition_appgroup|int|{{undocumented}} }}
{{2da column| ProcessWithEvent | int| Если установить флаг в этой колонке, при применении способности будет запускаться и обрабатываться событие. Работает даже когда игра поставлена на паузу. Использовать осторожно.}}
{{2da column| fatigue | float | Если способность является способостью продолжительного действия, значения этой колонки определяет степень усталости в то время, как способность активна. }}
{{2da end}}

== Рабочий лист ability_data ==

{{2da start|ability_data}}
{{2da column| Label | comment | {{undocumented}} }}
{{2da column| bHostileint | int | {{undocumented}} }}
{{2da column| effectImpact | int | {{undocumented}} }}
{{2da column| effectResisted| int | {{undocumented}} }}
{{2da column| effectDuration| float |
* positive: temporary
* 0.0 instant
* negative permanent }}
{{2da column| dmg_function | int | {{undocumented}} }}
{{2da column| dmg_param0 | float | {{undocumented}} }}
{{2da column| dmg_param1| int | {{undocumented}} }}
{{2da column| dmg_type| int |
*const int DAMAGE_TYPE_INVALID - 0;
*const int DAMAGE_TYPE_PHYSICAL - 1;
*const int DAMAGE_TYPE_FIRE - 2;
*const int DAMAGE_TYPE_COLD - 3;
*const int DAMAGE_TYPE_ELECTRICITY - 4;
*const int DAMAGE_TYPE_POISON - 5;
*const int DAMAGE_TYPE_LETHAL - 6;
*const int DAMAGE_TYPE_TBD - 7;}}
{{2da column| dmg_flags | int |
*const int DAMAGE_EFFECT_FLAG_NONE - 0x00000000 ;
*const int DAMAGE_EFFECT_FLAG_CRITICAL - 0x00000001; //критический удар
*const int DAMAGE_EFFECT_FLAG_DEATHBLOW - 0x00000002; //фаталити
*const int DAMAGE_EFFECT_FLAG_UPDATE_GORE - 0x00000004; //на атакующем существе появляется кровь
*const int DAMAGE_EFFECT_FLAG_LEECH_50 - 0x00000008; //возвращает атакующему 50% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_75 - 0x00000010; //возвращает атакующему 75% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_100 - 0x00000020; //возвращает атакующему 100% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_MANA - 0x00000040; //возвращает ману вместо жизни}}
{{2da end}}

== Рабочий лист ability_effects (эффекты способностей) ==

{{2da start|ability_effects}}
{{2da column| Label| string | {{undocumented}} }}
{{2da column| effect| int | {{undocumented}} }}
{{2da column| effect_label| comment | {{undocumented}} }}
{{2da column| effect_int1| int | {{undocumented}} }}
{{2da column| effect_int2| int | {{undocumented}} }}
{{2da column| effect_int3| int | {{undocumented}} }}
{{2da column| effect_float0| float | {{undocumented}} }}
{{2da column| effect_float1| float | {{undocumented}} }}
{{2da column| effect_object0 |int|
* 0 - не установлено
* 1 - set to OBJECT_SELF
* 2 - set to caster}}
{{2da column| scaled_field |int|
*0 - none
* 1 - float0
* 2 - float1}}
{{2da column| vfx| int | {{undocumented}} }}
{{2da column| resistance| int |
*const int PROPERTY_ATTRIBUTE_RESISTANCE_MENTAL - 32;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_AVOIDANCE - 31;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_PHYSICAL - 33;}}
{{2da end}}

== Рабочий лист passive_abilities (пассивных способностей) ==

{{2da start|passive_abilities}}
{{2da column| Label | comment | }}
{{2da column| Prop1 |int| Ссылка на [[properties.xls]]}}
{{2da column| Modifier1|float| Этот модификатор применяет способность только на персонажа-владельца.}}
{{2da column| Prop2| int | }}
{{2da column| Modifier2| float | }}
{{2da column| Prop3| int | }}
{{2da column| Modifier3| float | }}
{{2da column| Comment| comment | Итог способности в читабельной форме. }}
{{2da end}}

== Переводчики ==
Silderon / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]

[[Category:XLS files]]
[[Category:Abilities]]

{{Languages|Ability}}

Ability/ru

2011-10-07T11:28:16Z

Silderon:

Ability/ru

2011-10-07T11:27:13Z

Silderon:

Ability/ru

2011-10-07T11:24:28Z

Silderon:

Ability/ru

2011-10-07T11:17:06Z

Silderon: Created page with "Здесь есть 2DA-файлы со всеми талантами и заклинаниями из игры. Они определяют их названия, иконки, ..."

Здесь есть 2DA-файлы со всеми талантами и заклинаниями из игры. Они определяют их названия, иконки, требования, и другие детали, описывающие их функцию (анимации, время перезарядки, и т. л.)

Лучший способ создания новых способностей, это копирование похожей способности и редактирования необходимых параметров.

Во время разработки Dragon Age, этот файл обновлялся автоматически из базы данных. Мы же можем редактировать его вручную.

== Рабочий лист ABI_Base ==

{{2da start|ABI_Base}}
{{2da column| label |string| Описания для игроков. Способности, ориентированные на предметы отображается в списке '''Активные способности'''.}}
{{2da column| namestrref |int| ID string-переменной, которая содержит название способности.}}
{{2da column| descstrref |int| ID string-переменной, которая содержит описание способности.}}
{{2da column| tooltipstrref |int| String Ref ID of the buff/deff format on mouse over. (Caution: Abilities with ID over 500000 is considered as debuff and will not take the format of normal buffs.) }}
{{2da column| strid_effect| int| ID-номер строчки, в которой содержится описания способности, которое можно увидеть при наведении мышки.}}
{{2da column| icon|string| Название иконки без расширения.}}
{{2da column| abilitytype | int|Тип способности. Смотрите [[abilitytype.xls]] и [[ABILITY_TYPE_*]], а константые переменные в [[2da_constants_h]]:
* 1 - талант
* 2 - заклинание
* 3 - умение
* 4 - предмет}}
{{2da column| abilitymode |int| }}
{{2da column| conditions |int| Флаги, которые определяют, какие условие должны выполняться, чтобы игрок мог использовать описанною способность:
* 1 - экипировано одноручное оружие
* 2 - экипирован щит
* 4 - экипировано дальнобойное оружие
* 8 - игрок находится за спиной цели
* 16 - активирован нужный режим
* 32 - использующий способность является человекообразным созданием
* 64 - dual wielding
* 128 - экипировано два оружия
* 256 - использующий способноть является псом.
* 512 - использующий является магом}}
{{2da column| condition_mode | int| Если значения условий(Conditions) равно 16, в этой колонке содержится ID-номер способности продолжительного действия, которая должна быть активирована перед использованием данной способности. }}
{{2da column| condition_group |int| Связь между способностями продолжительного действия. Используйте минимальное значение группы. Когда активна одна из связанных способностей, другие выключаются. }}
{{2da column| cost| float| Количество Маны\Выносливость, которое будет потрачено на использование способности.}}
{{2da column| costupkeep |float| Сколько маны\выносливости резервирует способность. (только способности продолжительного действия)}}
{{2da column| prereqability |int | The ID of a prereq ability.}}
{{2da column| prereqlevel | int| Минимальный уровень персонажа для изучения способности.}}
{{2da column| prereqattribute | int | Какой аттрибут нужен для способности. Смотрите [[properties.xls]] for what this number maps to.}}
{{2da column| prereqattvalue | int | Минимальное значения указанного аттрибута, которое нужно для использования способности.}}
{{2da column| guitype | int | Категория способности. К примеру, "Создание" и "Основные". Смотрите [[guitypes.xls]].}}
{{2da column| targettype | int | Оператор, который определяет тип цели, которая может быть поражена способностью. Смотрите [[targettype.xls]] и [[Ability#Targeting Behavior]]}}
{{2da column| autotarget | int| Если TRUE, игра автоматически выберит цель способности, будь то друг или враг. }}
{{2da column| range | int| Область действия:
* 0 - ближний бой (прикасаясь к цели)
* 1 - заклинания ближнего расстояния (почти ближний бой)
* 2 - moderate spell range (заклинания с конусообразной областью действия)
* 3 - заклинания дальнего расстояния (расстояние действия равно расстоянии обнаружения противника)
* 4+ - очень большое расстояние}}
{{2da column| speed |int| Значение колонки определяет, как долго способность будет готовиться к использованию. 0 - сработает сразу, 1 - проиграется выбранная анимация. 2+ - над головой использующего будет создана полоса прогресса, после заполнения которой проиграется выбранная анимация, а затем сработет способность.}}
{{2da column| usetype |int | Является ли способность пассивной, способностью длительного действия или одноразовой. Смотрите [[abilityusetype.xls]]:
* 2 - sustained
* 3 - пассивные
* 4 - activated}}
{{2da column| spellscript |string| Скрипт, который запустится после использования способности. Расширения скрипта типа ".ncs" также сработают.}}
{{2da column| cooldown | float | Время восстановления способности в секундах.}}
{{2da column| conjurevfx | int| Визуальный(VFX) эффект, который проигрывается во время подготовки и наложения заклинания.. Значения определены в [[VFX_base.xls]].}}
{{2da column| blendtree | string| Set by animators for abilities that change the default animations of a PC or party member, e.g. when you use "Shield Wall" your idle becomes a defensive crouch using your shield prominently.}}
{{2da column| conjureanim | int | Анимация, которая проигрывается во время подготовки заклинания. Список возможных значений расположен здесь [[ANIM_base.xls]].}}
{{2da column| castanim | int | Анимация, которая проигрывается во время наложения заклинания. Список возможных значений расположен здесь [[ANIM_base.xls]].}}
{{2da column| projectile | int | Название используемых снарядов. Смотрите [[PRJ_base.xls]]. 1 - стрела.}}
{{2da column| autocancel | int| Устаревшее }}
{{2da column| autodraw |int| Определяет поведение способности по отношению к оружие. 0 - способность игнорирует состояние оружия, 1 - перед использованием способности оружие нужно вытянуть, 2 - перед использованием оружие нужно вложить в ножны.
Значение любого заклинания со скоростью больше, чем 1, должно быть равно 2. The sheathing animation occurs during the conjure sequence without slowing it down, and putting away the weapon will prevent clipping.}}
{{2da column| threat_use|float| Устаревшее}}
{{2da column| threat_impact|float| Урон,наносимый каждый ударом. Использовать не обязательно.}}
{{2da column| aoe_type|int| 1 - круг, 2 - конус.}}
{{2da column| aoe_idx|int| Определяет области действия. Расположены в [[VFX_base.xls]].}}
{{2da column| aoe_param1 |float| Радиус круга действия или размер конуса.}}
{{2da column| aoe_param2 |float| Устаревшее}}
{{2da column| vfx_impact0| int| Визуальный(VFX) эффект, который проигрывается при каждом ударе. [[VFX_base.xls]]. Смотрите [[Ability_GetImpactLocationVfxId]]}}
{{2da column| vfx_impact1|int| Не используется движком, но может быть использовано в качестве константы в скриптах. При помощи этого параметра многие ПРЕДМЕТЫ удерживает свой VFX-эффект. Смотрите [[Ability_GetImpactObjectVfxId]]
Как правило, используется для длительных способностей или способностей продолжительного действия. Указывается на VFX-эффект, который будет использован.}}
{{2da column| flags |int| Установить значение 1 для способности, которая использует анимации атаки с оружие дальнего боя, значение 64 для способностей длительного действия, которые выключаются когда у существа заканчивается выносливость, 128 для снятия заклинания с субъекта (?), значение 192 для способностей длительного действия, которые выключаются когда у существа заканчивается мана }}
{{2da column| showintactics| int| Установите значение 1 тем способностям, которые герой или его сопартийцы захотят использовать в тактической системе.}}
{{2da column| showinchargen |int| Возможные значения:
* 1 - {{не задокументировано}}
* 2 - показывать только в окне генерации персонажа
* 4 - показывать в таланте\заклинании\навыке\книге
Если вы, к примеру, установите значение 7, будет отображаться и в окне генерации, и в таланте\заклинании\навыке\книге}}
{{2da column| passive_id |int| Соответствует ID-номеру способности в листе passive_abilities документа [[ABI_base.xls]]. }}
{{2da column| crust_id | int| Устаревшее}}
{{2da column| resistance |int | {{не задокументировано}} }}
{{2da column| damageinfo | int| {{не задокументировано}} }}
{{2da column| condition_appgroup|int|{{не задокументировано}} }}
{{2da column| ProcessWithEvent | int| Если установить флаг в этой колонке, при применении способности будет запускаться и обрабатываться событие. Работает даже когда игра поставлена на паузу. Использовать осторожно.}}
{{2da column| fatigue | float | Если способность является способостью продолжительного действия, значения этой колонки определяет степень усталости в то время, как способность активна. }}
{{2da end}}

== Рабочий лист ability_data ==

{{2da start|ability_data}}
{{2da column| Label | comment | {{не задокументировано}} }}
{{2da column| bHostileint | int | {{не задокументировано}} }}
{{2da column| effectImpact | int | {{не задокументировано}} }}
{{2da column| effectResisted| int | {{не задокументировано}} }}
{{2da column| effectDuration| float |
* positive: temporary
* 0.0 instant
* negative permanent }}
{{2da column| dmg_function | int | {{не задокументировано}} }}
{{2da column| dmg_param0 | float | {{не задокументировано}} }}
{{2da column| dmg_param1| int | {{не задокументировано}} }}
{{2da column| dmg_type| int |
*const int DAMAGE_TYPE_INVALID - 0;
*const int DAMAGE_TYPE_PHYSICAL - 1;
*const int DAMAGE_TYPE_FIRE - 2;
*const int DAMAGE_TYPE_COLD - 3;
*const int DAMAGE_TYPE_ELECTRICITY - 4;
*const int DAMAGE_TYPE_POISON - 5;
*const int DAMAGE_TYPE_LETHAL - 6;
*const int DAMAGE_TYPE_TBD - 7;}}
{{2da column| dmg_flags | int |
*const int DAMAGE_EFFECT_FLAG_NONE - 0x00000000 ;
*const int DAMAGE_EFFECT_FLAG_CRITICAL - 0x00000001; //критический удар
*const int DAMAGE_EFFECT_FLAG_DEATHBLOW - 0x00000002; //фаталити
*const int DAMAGE_EFFECT_FLAG_UPDATE_GORE - 0x00000004; //на атакующем существе появляется кровь
*const int DAMAGE_EFFECT_FLAG_LEECH_50 - 0x00000008; //возвращает атакующему 50% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_75 - 0x00000010; //возвращает атакующему 75% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_100 - 0x00000020; //возвращает атакующему 100% здоровья
*const int DAMAGE_EFFECT_FLAG_LEECH_MANA - 0x00000040; //возвращает ману вместо жизни}}
{{2da end}}

== ability_effects worksheet ==

{{2da start|ability_effects}}
{{2da column| Label| string | {{не задокументировано}} }}
{{2da column| effect| int | {{не задокументировано}} }}
{{2da column| effect_label| comment | {{не задокументировано}} }}
{{2da column| effect_int1| int | {{не задокументировано}} }}
{{2da column| effect_int2| int | {{не задокументировано}} }}
{{2da column| effect_int3| int | {{не задокументировано}} }}
{{2da column| effect_float0| float | {{не задокументировано}} }}
{{2da column| effect_float1| float | {{не задокументировано}} }}
{{2da column| effect_object0 |int|
* 0 - не установлено
* 1 - set to OBJECT_SELF
* 2 - set to caster}}
{{2da column| scaled_field |int|
*0 - none
* 1 - float0
* 2 - float1}}
{{2da column| vfx| int | {{не задокументировано}} }}
{{2da column| resistance| int |
*const int PROPERTY_ATTRIBUTE_RESISTANCE_MENTAL - 32;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_AVOIDANCE - 31;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_PHYSICAL - 33;}}
{{2da end}}

== Рабочий лист passive_abilities (пассивных способностей) ==

{{2da start|passive_abilities}}
{{2da column| Label | comment | }}
{{2da column| Prop1 |int| Ссылка на [[properties.xls]]}}
{{2da column| Modifier1|float| Этот модификатор применяет способность только на персонажа-владельца.}}
{{2da column| Prop2| int | }}
{{2da column| Modifier2| float | }}
{{2da column| Prop3| int | }}
{{2da column| Modifier3| float | }}
{{2da column| Comment| comment | Итог способности в читабельной форме. }}
{{2da end}}

[[Category:XLS files]]
[[Category:Abilities]]

Shortcuts/ru

2011-09-27T14:13:38Z

Silderon:

== Скриптинг ==

В окне скриптов:

*F1: Общая справка (в отдельном окне)
*F2: Автозавершение
*F7: Компиляция
*CTRL+Space: Автозавершение
*CTRL+Shift+Space: Подсказка по функции (почти весь список)
*Двойной щелчок (на функции): Помощь (на панели помощи)

На панели просмотра Функций/Переменных/Констант/Шаблонов:

*Единичный щелчок (на функции): Помощь
*Двойной щелчок (на любом элементе): вставить в скрипт
*Return/Enter (на любом элементе): вставить в скрипт
*Курсор вправо/вниз: следующая запись в списке
*Курсор влево/вверх: предыдущая запись в списке
*Page Up: первая видимая запись
*Page Down: последняя видимая запись
*Home: первая запись в списке
*End: последнаяя запись в списке

Когда открыто окошко автозавершения:
*Двойной щелчок (на любом элементе): вставить в скрипт
*Return/Enter (на любом элементе): вставить в скрипт
*Курсор вправо/вниз: следующая запись в списке
*Курсор влево/вверх: предыдущая запись в списке
*Page Up: первая видимая запись
*Page Down: последняя видимая запись
*Home: первая запись в списке
*End: последнаяя запись в списке

== Area editor(Редактор области) ==

Более подпобная информация здесь [[3D control]].

*"r": Включить стандартный инструмент выделения (Standard selection tool) (объект должен быть выбран)
*"q": Включить инструмент перемещения по осям (объект должен быть выбран)
*"e": Включить инструмент вращения по осям (объект должен быть выбран)
*"t": Использование локальных координат (объект должен быть выбран)

*Средняя кнопка мышки: Вращение
*CTRL: панорама
*CTRL+Правая кнопка мышки: Вращение
*Функция ZDrag (Перемещение объектов вверх и вниз): Левая кнопка мышки + Shift + Alt (Предварительно нужно кликнуть на выбранный объект)
*Двигать камеру: Левая кнопка мышки + Ctrl
*Rotate Objects Yaw Left: Правая кнопка мышки + Shift

Думаю, для этих команд нужно использовать один из инструментов 3d-перемещения.
*Rotate Objects Pitch Up: Правая кнопка мышки + Shift + Ctrl
*Rotate Objects Roll Right: Правая кнопка мышки + Shift + Alt

== Cutscene curve editor(Редактор катсцен-кривых) ==

*K - Установить все ключи
*P - Установить позицию
*O - Установить ориентацию
*F - FOV

* Вставить камеру = C
* Вставить VFX = V
* Добавить трэк = T
* Добавить действие:
** Проиграть анимацию = alt+A
**(Дополнительные горячие клавиши для других полезных функций)
* Добавить переход = X
* Добавить эффект:
** Появление= I
** Исчезание= O
*Редактировать FaceFX = alt+F

== Stage Editor(Редактор сцен) ==

* Вставить позицию(Place)= P
* Вставить камеру = C
* Скрыть объект = H
* Показать объекты= S

== Dialog Editor(Редактор диалогов) ==

* Редактировать FaceFX= alt+F
* Сгенерировать жесты для строчки= alt+G
* Найти ссылки= alt+L
* Предпросмотр строки=alt+/
* Открыть катсцену(Cutscene)= alt+C
* Открыть сцену(Stage)= alt+S
* Создать катсцену(cutscene)= alt+ctrl+C

[[Category:Interface]]

== Переводчики ==
Silderon / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]

Shortcuts/ru

2011-09-27T14:12:00Z

Silderon:

== Скриптинг ==

В окне скриптов:

*F1: Общая справка (в отдельном окне)
*F2: Автозавершение
*F7: Компиляция
*CTRL+Space: Автозавершение
*CTRL+Shift+Space: Подсказка по функции (почти весь список)
*Двойной щелчок (на функции): Помощь (на панели помощи)

На панели просмотра Функций/Переменных/Констант/Шаблонов:

*Единичный щелчок (на функции): Помощь
*Двойной щелчок (на любом элементе): вставить в скрипт
*Return/Enter (на любом элементе): вставить в скрипт
*Курсор вправо/вниз: следующая запись в списке
*Курсор влево/вверх: предыдущая запись в списке
*Page Up: первая видимая запись
*Page Down: последняя видимая запись
*Home: первая запись в списке
*End: последнаяя запись в списке

Когда открыто окошко автозавершения:
*Двойной щелчок (на любом элементе): вставить в скрипт
*Return/Enter (на любом элементе): вставить в скрипт
*Курсор вправо/вниз: следующая запись в списке
*Курсор влево/вверх: предыдущая запись в списке
*Page Up: первая видимая запись
*Page Down: последняя видимая запись
*Home: первая запись в списке
*End: последнаяя запись в списке

== Area editor(Редактор области) ==

Более подпобная информация здесь [[3D control]].

*"r": Включить стандартный инструмент выделения (Standard selection tool) (объект должен быть выбран)
*"q": Включить инструмент перемещения по осям (объект должен быть выбран)
*"e": Включить инструмент вращения по осям (объект должен быть выбран)
*"t": Использование локальных координат (объект должен быть выбран)

*Средняя кнопка мышки: Вращение
*CTRL: панорама
*CTRL+Правая кнопка мышки: Вращение
*Функция ZDrag (Перемещение объектов вверх и вниз): Левая кнопка мышки + Shift + Alt (Предварительно нужно кликнуть на выбранный объект)
*Двигать камеру: Левая кнопка мышки + Ctrl
*Rotate Objects Yaw Left: Правая кнопка мышки + Shift

Думаю, для этих команд нужно использовать один из инструментов 3d-перемещения.
*Rotate Objects Pitch Up: Правая кнопка мышки + Shift + Ctrl
*Rotate Objects Roll Right: Правая кнопка мышки + Shift + Alt

== Cutscene curve editor(Редактор катсцен-кривых) ==

*K - Установить все ключи
*P - Установить позицию
*O - Установить ориентацию
*F - FOV

* Вставить камеру = C
* Вставить VFX = V
* Добавить трєк = T
* Добавить действие:
** Проиграть анимацию = alt+A
**(Дополнительные горячие клавиши для других полезных функций)
* Добавить переход = X
* Добавить эффект:
** Появление= I
** Исчезание= O
*Редактировать FaceFX = alt+F

== Stage Editor(Редактор сцен) ==

* Вставить позицию(Place)= P
* Вставить камеру = C
* Скрыть объект = H
* Показать объекты= S

== Dialog Editor(Редактор диалогов) ==

* Редактировать FaceFX= alt+F
* Сгенерировать жесты для строчки= alt+G
* Найти ссылки= alt+L
* Предпросмотр строки=alt+/
* Открыть катсцену(Cutscene)= alt+C
* Открыть сцену(Stage)= alt+S
* Создать катсцену(cutscene)= alt+ctrl+C

[[Category:Interface]]

== Переводчики ==
Silderon / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]

Shortcuts/ru

2011-09-27T14:03:06Z

Silderon: Created page with "== Скриптинг == В окне скриптов: *F1: Compiled doxygen Help (in separate window) *F2: АвтоЗавершение *F7: Компиляция *CTRL+Space: ..."

== Скриптинг ==

В окне скриптов:
*F1: Compiled doxygen Help (in separate window)
*F2: АвтоЗавершение
*F7: Компиляция
*CTRL+Space: АвтоЗавершение
*CTRL+Shift+Space: Parameter Tooltip (actually the full declaration)
*Double-click (on a function): Help (in the Help panel)

В панели просмотра Функций/Переменных/Констант/Шаблонов:
*Единичный щелчок (на функции): Помощь
*Двойной щелчок (на любом элементе): вставить в скрипт
*Return/Enter (на любом элементе): вставить в скрипт
*Курсор вправо/вниз: следующая запись в списке
*Курсор влево/вверх: предыдущая запись в списке
*Page Up: первая видимая запись
*Page Down: последняя видимая запись
*Home: первая запись в списке
*End: последнаяя запись в списке

When the AutoComplete pop-up is open:
*Двойной щелчок (на любом элементе): вставить в скрипт
*Return/Enter (на любом элементе): вставить в скрипт
*Курсор вправо/вниз: следующая запись в списке
*Курсор влево/вверх: предыдущая запись в списке
*Page Up: первая видимая запись
*Page Down: последняя видимая запись
*Home: первая запись в списке
*End: последнаяя запись в списке

== Area editor(Редактор области) ==

Более подпобная информация здесь [[3D control]].

*"r": Включить стандартный инструмент выделения (Standard selection tool) (объект должен быть выбран)
*"q": Включить инструмент перемещения по осям (объект должен быть выбран)
*"e": Включить инструмент вращения по осям (объект должен быть выбран)
*"t": Использование локальных координат (объект должен быть выбран)

*Средняя кнопка мышки: Вращение
*CTRL: панорама
*CTRL+Правая кнопка мышки: Вращение
*Функция ZDrag (Перемещение объектов вверх и вниз): Левая кнопка мышки + Shift + Alt (Предварительно нужно кликнуть на выбранный объект)
*Двигать камеру: Левая кнопка мышки + Ctrl
*Rotate Objects Yaw Left: Правая кнопка мышки + Shift

Думаю, для этих команд нужно использовать один из инструментов 3d-перемещения.
*Rotate Objects Pitch Up: Правая кнопка мышки + Shift + Ctrl
*Rotate Objects Roll Right: Правая кнопка мышки + Shift + Alt

== Cutscene curve editor(Редактор катсцен-кривых) ==
*K - Установить все ключи
*P - Установить позицию
*O - Установить ориентацию
*F - FOV

* Вставить камеру = C
* Вставить VFX = V
* Добавить трєк = T
* Добавить действие:
** Проиграть анимацию = alt+A
**(Дополнительные горячие клавиши для других полезных функций)
* Добавить переход = X
* Добавить эффект:
** Появление= I
** Исчезание= O
*Редактировать FaceFX = alt+F

== Stage Editor(Редактор сцен) ==

* Вставить позицию(Place)= P
* Вставить камеру = C
* Скрыть объект = H
* Показать объекты= S

== Dialog Editor(Редактор диалогов) ==

* Редактировать FaceFX= alt+F
* Сгенерировать жесты для строчки= alt+G
* Найти ссылки= alt+L
* Предпросмотр строки=alt+/
* Открыть катсцену(Cutscene)= alt+C
* Открыть сцену(Stage)= alt+S
* Создать катсцену(cutscene)= alt+ctrl+C

[[Category:Interface]]

== Переводчики ==
Silderon / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]

Backgrounds tutorial/ru

2011-08-28T12:55:08Z

Silderon:

Template:Infobox script

2011-08-27T11:50:05Z

Silderon:

{{infobox template
|title=Скрипты
|contents=
*{{ulink|Script|Начало|ru}}
*{{ulink|Scripting overview|Обзор|ru}}
*{{ulink|Scripting tutorial|Инструкция|ru}}
*{{ulink|Event (dascript type)|События DA|ru}}
**{{ulink|Event override|Подмена обработки|ru}}
*{{ulink|Useful Scripts|Примеры|ru}}
*{{ulink|Script error|Ошибки|ru}}
*{{ulink|Rules|Правила|ru}}
**{{ulink|Creature Properties|Свойства существ|ru}}
***{{ulink|Attribute|Атрибуты|ru}}
**{{ulink|Classes|Классы|ru}}
**{{ulink|Combat Rules|Правила боя|ru}}
**{{ulink|Ability|Способности|ru}}
*{{ulink|:Category:Scripts|Категория "Скрипты"|ru}}
:<small>содержит все статьи категории</small>
*{{ulink|:Category:Script_functions|Категория "Функции"|ru}}
:<small>содержит описание функций</small>
|collapsed=no
}}<noinclude>

Classes/ru

2011-08-27T11:47:23Z

Silderon:

{{Infobox script}}

''В процессе доработки''

Dragon Age: Origins является классической ролевой игрой, которая позволяет пользователю играть героем одного из трех классов, каждый из которых обладает уникальными способностями.
== Описание ==
Данная страница описывает техническую составляющую различий между классами и создана с целью помочь пользователям, желающим создать модификации, используя возможности скриптовых правил(ruleset).

Игровые классы описаны в документе под названием '''[[CLA_base.xls]]'''.
Таблица, помещенная ниже является выдержкой из этого документа. В ней вы можете видеть различия между классами.

{| border="1" width="100%" style="font-size:xx-small"
|-
|'''ID'''||'''Label'''||'''BaseHealth'''||'''BaseManaStamina'''||'''DepletableProgression'''||'''StrAdjust'''||'''ConAdjust'''||'''WillAdjust'''||'''MagAdjust'''||'''CunAdjust'''||'''DexAdjust'''||'''BaseAttack'''||'''BaseDefense'''||'''DefensePerLevel'''||'''HealthPerLevel'''||'''LevelsPerAbility'''||'''LevelsPerSkill'''||'''DamagePerLevel'''
|-
|0||INVALID||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****|
|-
|1||Warrior||100||100||5||4||3||0||0||0||3||60||45||1||6||1||3||0.4
|-
|2||Wizard||85||115||6||0||0||4||5||1||0||50||40||1||4||1||3||0.1
|-
|3||Rogue||90||90||4||0||0||2||0||4||4||55||50||1||5||1||2||0.2
|-|
|}
Более подробное описание данных из таблицы вы можете найти здесь '''[[CLA_base.xls]]'''.
== Скриптовый этап создания персонажа ==
В начале создания, все персонажы игры являются такими себе 'болванками', у которых все параметры [[Creature Properties]] установлены по умолчанию.

Скрипты, создающие персонажа вместе с UI-файлами, основываюясь на выборах, сделанных игроком, создают данные в документе [[CLA_base.xls]]. Эти же файлы ответственны за изменение параметров игрока после получения нового уровня.

Для работы со спутниками героя используются те же файлы и скрипты. Для враждебных созданий используется более ускоренный и оптимизированный алгоритм, определяющий их параметры исходя из ранга, AI(искуственного интеллекта), поведения и уровня.
=== Скрипты ===
Вот перечень скриптов, который принимают участие в создании персонажа и изменении его параметров в результате получения нового уровня:

* sys_chargen - Точка входа для всех персонажей, создание которых основано на событиях ([[event (dascript type)|Event]]), запущенных из модуль-скрипта(module_core.nss).
* sys_chargen_h - Библиотека, которая содержит большинство логических правил, используемых при изменении параметров существа ([[Creature Properties]]). Основанная на игровых правилах(game rules).
* sys_chargen_engine - Инклуд-скрипт, содержащий несколько константных переменных и часть кода, связанную с игровым движком.
* sys_autolevelup_h - Файл, определяющий логику поднятия уровня спутников героя после их принятия. В дальнейшем используется стандартный алгоритм подьема уровня.
* sys_autoscale_h - Файл, определяющий логику автоподнятия уровня.
* sys_rewards_h - Файл, содержащий количество опыта, получаемого в качестве награды за определенное действие, точки сохранения игры и проверку персонажа на повышение уровня.

[[Category: Character_generation]]
== Переводчики ==
Silderon / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]
{{Languages|Scripting overview}}
[[Category:Scripts]]

Classes/ru

2011-08-27T11:46:41Z

Silderon: Created page with "{{Infobox script}} ''В процессе доработки'' Dragon Age: Origins является классической ролевой игрой, которая позво..."

{{Infobox script}}

''В процессе доработки''

Dragon Age: Origins является классической ролевой игрой, которая позволяет пользователю играть героем одного из трех классов, каждый из которых обладает уникальными способностями.
== Описание ==
Данная страница описывает техническую составляющую различий между классами и создана с целью помочь пользователям, желающим создать модификации, используя возможности скриптовых правил(ruleset).

Игровые классы описаны в документе под названием '''[[CLA_base.xls]]'''.
Таблица, помещенная ниже является выдержкой из этого документа. В ней вы можете видеть различия между классами.

{| border="1" width="100%" style="font-size:xx-small"
|-
|'''ID'''||'''Label'''||'''BaseHealth'''||'''BaseManaStamina'''||'''DepletableProgression'''||'''StrAdjust'''||'''ConAdjust'''||'''WillAdjust'''||'''MagAdjust'''||'''CunAdjust'''||'''DexAdjust'''||'''BaseAttack'''||'''BaseDefense'''||'''DefensePerLevel'''||'''HealthPerLevel'''||'''LevelsPerAbility'''||'''LevelsPerSkill'''||'''DamagePerLevel'''
|-
|0||INVALID||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****|
|-
|1||Warrior||100||100||5||4||3||0||0||0||3||60||45||1||6||1||3||0.4
|-
|2||Wizard||85||115||6||0||0||4||5||1||0||50||40||1||4||1||3||0.1
|-
|3||Rogue||90||90||4||0||0||2||0||4||4||55||50||1||5||1||2||0.2
|-|
|}
Более подробное описание данных из таблицы вы можете найти здесь '''[[CLA_base.xls]]'''.
== Скриптовый этап создания персонажа ==
В начале создания, все персонажы игры являются такими себе 'болванками', у которых все параметры [[Creature Properties]] установлены по умолчанию.

Скрипты, создающие персонажа вместе с UI-файлами, основываюясь на выборах, сделанных игроком, создают данные в документе [[CLA_base.xls]]. Эти же файлы ответственны за изменение параметров игрока после получения нового уровня.

Для работы со спутниками героя используются те же файлы и скрипты. Для враждебных созданий используется более ускоренный и оптимизированный алгоритм, определяющий их параметры исходя из ранга, AI(искуственного интеллекта), поведения и уровня.
=== Скрипты ===
Вот перечень скриптов, который принимают участие в создании персонажа и изменении его параметров в результате получения нового уровня:

* sys_chargen - Точка входа для всех персонажей, создание которых основано на событиях ([[event (dascript type)|Event]]), запущенных из модуль-скрипта(module_core.nss).
* sys_chargen_h - Библиотека, которая содержит большинство логических правил, используемых при изменении параметров существа ([[Creature Properties]]). Основанная на игровых правилах(game rules).
* sys_chargen_engine - Инклуд-скрипт, содержащий несколько константных переменных и часть кода, связанную с игровым движком.
* sys_autolevelup_h - Файл, определяющий логику поднятия уровня спутников героя после их принятия. В дальнейшем используется стандартный алгоритм подьема уровня.
* sys_autoscale_h - Файл, определяющий логику автоподнятия уровня.
* sys_rewards_h - Файл, содержащий количество опыта, получаемого в качестве награды за определенное действие, точки сохранения игры и проверку персонажа на повышение уровня.

[[Category: Character_generation]]
== Переводчики ==
Silderon / [[User:Silderon|Страница]] / [mailto:lordmilten95@gmail.com Почта] / [[Translation/ru|Как переводить DA Builder Wiki]]
{{Languages|Scripting overview}}
[[Category:Scripts]]

Backgrounds tutorial/ru

2011-08-26T11:27:29Z

Silderon:

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете [http://social.bioware.com/project/4695/ скачать фикс] от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //извлечение с текущего события его типа
int nEventHandled = FALSE; //флаг, следящий за тем, было ли обработано события или нет.
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //предварительна загрузка ресурсов для генерации персонажа
StartCharGen(GetHero(),0,TRUE); //начало генерации
break;
}
default:
{
// -----------------------------------------------------------------
// Обработка отправленных движков события генерации персонажа.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //если событие не было обработано, оно отправляется в core-скрипт
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Отладка.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// Срабатывает, когда игрок кликает по иконке одной из доступных
// предысторий.
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Выбор предыстории для игрока и установка соответствующих предыстории
// plot-флагов.
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Проверяет шаблоны, указанные в 2DA-файлах
// и, руководствуясь ими создает герою инвентарь.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / то же самое
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Установка стандартный параметров для игрового персонажа.");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Установка переменной предыстории
// - создание внешности героя (или использование одной из заготовок)
//
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Игрок получает один навык.
// - найти нужный навык в файле backgrounds.xls
// - присвоить его игроку.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Установка plot-флагов расы: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// Сперва происходит инициализация всех флагов
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Character generation]]
[[Category:Tutorials]]
[[Category:Translations_ru]]
{{Languages|Backgrounds tutorial}}

Backgrounds tutorial

2011-08-26T11:27:26Z

Silderon:

== Introduction ==
This tutorial shows you how to modify the character backgrounds that can be selected during character generation. This is likely only of use if you are creating your own module or campaign as there would be no point to changing the background in the single player campaign unless you were also going to make extensive additions to support the new backgrounds (e.g a completely new origin story). So the example we will use for this tutorial is a new stand alone module in which we completely replace the existing backgrounds. Changing backgrounds is especially useful if your module is set in a different lore to the main Dragon Age game or if you simply want to reduce the scope of the number of different backgrounds.

We will also demonstrate some important principals that can be followed when modifying other core rules such as available races or classes. Most importantly we will add the new backgrounds in a way that doesn’t require any editing of core resources. By leaving the core resources alone we make our changes compatible with future patches which might otherwise overwrite our work. Furthermore keeping the core resources in tact allows us to make different modifications to different modules within the same toolset.

It is recommended that the reader should have some experience with scripting or coding in order to carry out the operations involved. The more you are relying on just copy pasting these instructions the more likely you are to make mistakes that you won’t know how to fix.

== The backgrounds demo module ==
Any basic module will do for the purposes of this tutorial. If you want to create a test module for this tutorial then just create a simple module with a single area and a starting location. Make sure that the only thing selected in the module’s hierarchy is ''Core game resources''. This will ensure that the module is a stand alone module rather than an add-in to the single player campaign or some other module. For the purposes of this tutorial we will assume the module is called ''Backgrounds demo'' and I will prefix my resources with ''bdm_'' to be sure that they are distinct from any that are already in existence.

We are going to completely replace the existing backgrounds with 3 new ones of our own. You can use new backgrounds in your module however you see fit. You could create entire origin stories for each one like in the single player campaign (possibly a major undertaking depending on length) or you can just use them to influence dialogue and plot options in the main part of your game.

For our demo we are creating a module in which the player starts off in a small human village (we will not be creating the details of this module so this is just for the purpose of an example). There is a wizard in this village who plays a pivotal role in the story. We allow the player to start as the wizard’s apprentice (if they are a mage) or as his servant (if they are human or elven and not a mage) or as a wandering traveller who has come to visit the wizard (if they are not human and not a mage). So the three backgrounds will be:

* Servant
* Apprentice
* Traveller

== Creating the background strings ==
Before we start modifying the 2DA files we are going to create some strings. Open the string editor in the toolset and create the following strings in your ‘Backgrounds demo’ talk table:

[[Image:Back_tut_talk_table.png]]

Your string IDs might be different to these so be sure to reference the right string ID in the instructions that follow. Simply replace these string Ids with your own.

'''IMPORTANT!''' ''There is currently a bug in the game that causes it to crash if a background description ID has a value greater than 109 912 680. There is a [http://social.bioware.com/project/4695/ community fix] for this. Alternatively, you can go into your module’s properties and change the start ID for strings to be less than the critical value. After that the string editor will generate IDs in a range that won’t crash. Reset the start ID to its original value after you create the background descriptions (that way you have less to alter once Bioware fix this, and less risk of incompatibility with other mods).''

You may have noticed that we have given two different names and descriptions for the traveller background depending on the PC’s race. We will say more about that in the following section.

{{TutorialRef|String editor}}

== Modifying the 2DAs ==
The next thing we need to do is to modify the worksheets in backgrounds.xls. Be sure to make a copy of the spreadsheet first so that you leave the original intact. See LINK for general information about editing 2DA files. The first worksheet is called ‘backgrounds’; modify it to look like the following:

[[Image:back_tut_backgrounds.png]]

Note that since 2DAs combine together to form M2DAs, and we don’t want the existing backgrounds in our game, we have overwritten the last two slots as unused1 and unused2, even though we won’t be using them. The name and desc string refs on this tab will be overwritten by the race specific ones on the names tab so we can leave those blank (AFAIK these string refs are not used providing the ones on the names tab are provided - also the tooltip string ref seems not to be used anywhere – if you prefer you can set these to something just to be safe).

The three race columns determine which backgrounds can be selected by which race and the 3 class columns determine which background can be selected by which class. So, as you can see from the picture our Servant background is accessible to elf or human warriors and rogues, the Apprentice background can be selected by elf or human mages and the Traveller background by elf or dwarf warriors and rogues.

The last three tabs indicate a starting ability for each background by race. Note that by default these columns are not hooked up into the character generation script (instead they are hard coded in the script) and are not used, but we will correct that later on when we do the scripting. You have to be careful here because the columns relate to the race IDs, so 1=dwarf, 2=elf and 3=human, which is in a different order to the other race columns in this table. The number in the column is an ability ID as given in ABI_base.xls. For this demo we have just given the same skill for each race for a given background. Servants get combat tactics, Apprentices get persuade and Travellers get survival.

The next tab table to modify is background_names.

[[Image:back_tut_bg_names.png]]

Make sure that the IDs here match the IDs in your string table. Note that for Apprentices and Servants we use the same strings regardless of race, but for the Traveller background we use different strings. This is to illustrate how you can divide a single background up into multiple names and descriptions. Internally they are both stored as the same background ID but during character generation a different name, description and icon can be shown to the player. In the single player game this was done with the Noble background by splitting it into human and dwarf Noble variations.

NOTE – you must be careful when splitting a single background into different parts for each race. You must make both the names and descriptions different! If you don’t make the descriptions different then the engine will not recognise them as different even if they have different names.

Now modify the background_desc table as follows

[[Image:back_tut_bg_desc.png]]

Again note the distinct descriptions for the Traveller background.

Now for the background_icons table. For this demo we will just use some of the existing icons but you may want to create your own icons to add here.

[[Image:back_tut_bg_icons.png]]

The background_defaults table must have an entry for each race, background and class combination that is allowed. The ID column must be calculated as follows:

(1000 * raceID) + (100 * classID) + backgroundID

[[Image:back_tute_bg_defaults.png]]

The label column should give a description of the row (AFAIK this is not used anywhere).
For this simple demo we will have each background combination spawn in the same place (the module default start location) but if you wanted different origins to spawn in different places then you can use the next two columns to specify this (AFAIK you have to write your own scripts to accomplish this though).

In the template column you can put the name of a creature resource that you want to use as a template for this race/background/class combination. In the picture you can see that we have just used some default templates that shipped with the toolset but you can easily create your own. Note that only the inventory is copied across to the PC so if you want to create your own templates you do not need to alter anything on the creature except for their inventory.

The name columns take string Ids. If you want to add your own names then you’ll have to create new strings in the string editor.

Finally we have the ability column. As with the skill columns in the backgrounds table these IDs correspond to entries in the ABI_base.xls file. It should be noted that race, class and background are all possible sources of starting abilities so before you decide what to put in this column you should familiarise yourself with what skills are already being added in different parts of character generation in order to ensure that you don’t duplicate an ability somewhere.

The final table is the chargen_preload table. The two columns here should exactly match the entries from the ID and Template columns of the previous table.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Compiling and fixing the GDAs ==
Now compile backgrounds.xls and place the resulting GDAs into your ''AddIns\module_name\module\override'' directory.
Never place anything in your ''AddIns\module_name\core\override'' directory or it will affect other modules than the one you are editing.

There used to be a [[Bug: ExcelProcessor doesn't handle row IDs above 8.3 million correctly|bug]] that prevented large string IDs from compiling correctly. This is now fixed. For the record, the old workaround was to edit the GDA files in the toolset to correct the string IDs manually, but you should now see that the string IDs are correct.

{{TutorialRef|Compiling 2DAs|GDA}}

== Creating the backgrounds plot ==
The background plot is used for keeping track of a PC’s background and can be used to affect conversation options.

The single player game uses a plot called gen00pt_backgrounds to keep track of the PC background. You can find it in the ''\_Global\Generic'' folder of the plots tab if you want to take a look. We will create a similar plot for our custom backgrounds. Create a new plot and call it ''bdm_000pt_backgrounds'' (My naming convention is to use 000 to indicate a resource that isn’t tied to any particular area – feel free to use your own convention but remember to update any references later in the tutorial). Add main plot flags as indicated in the picture below:

[[Image:Back_tut_bg_plot.png]]

You could also add some defined flags if you wanted. Defined flags can be used to return some combination of the main flags such as TRAVELLER or add some extra condition like FEMALE_APPRENTICE or ELVEN_APPRENTICE. Defined flags are beyond the scope of this tutorial however.

{{TutorialRef|Designer Resources|Plot}}

== Creating the scripts ==
We are not going to edit any of the original core game scripts, we will only be adding new scripts of our own. As we discuss how to do this you should examine the core scripts that are referred to, but under no circumstances should you make any changes to those files. By leaving the core scripts as they are we make our modification more compatible with any future patches that may be released. If you modified the core scripts and then a patch was released that overwrote those scripts you would lose your changes. Also keeping your modification contained within your own module allows you to make different modifications to different modules within the one toolset.

Lets start off with a script to handle the character generation events that are normally handled by the module_core script. Create a new script called ''bdm_module_core''. It is up to you what directory structure to use for your scripts but it can be a good idea to keep all your scripts in a directory with your module name to make them distinct from the core scripts. Then if you are emulating the functionality of a particular core script you can mirror the original directory structure underneath your main module folder. So in this case the module_core script is contained in the ''\_Core Scripts'' folder so we will put our bdm_module_core in ''\Backgrounds demo\_Core Scripts'' (the underscore ensures the core directories come first – looks like Bioware accidentally created one without it! I’m pretty sure Core and _Core are meant to be the same directory). Organising things this way will really help with keeping track of your scripts.

The ''bdm_module_core'' script should contain the following code:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //extract event type from current event
int nEventHandled = FALSE; //keep track of whether the event has been handled
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //preloads resources for character generation
StartCharGen(GetHero(),0,TRUE); //initiates character generation
break;
}
default:
{
// -----------------------------------------------------------------
// Handle character generation events sent by the engine.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //If this event wasn't handled by this script, let the core script try
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Now go to ''file > manage modules'' and open the properties for your module and set the script property to point at this script.

Our new script handles some of the events that are usually handled by the module_core script. Once it has handled the event it chooses whether or not to pass the event on to module_core. The first event that we handle is EVENT_TYPE_MODULE_START, which is where we initiate character generation. In this case we pass the event on to the core script to handle after we have done what we need to.

NOTE : you may find that you don't need to change any other scripts. It's not clear what the scripts in the rest of this section are trying to do - see discussion.

The second thing we handle is actually a group of events. If you look in the module_core script you will see that right down the bottom in the default event handler is some code that looks just like the code we have added in our default event, with a couple of little differences. Instead of passing the character generation events to the sys_chargen.ncs script we are going to pass it to our own script called ''bdm_sys_chargen.ncs'' which we will write shortly. If we catch one of those character generation events then we want to handle it ourselves and prevent the core script from handling it so we set nEventHandled = TRUE. Note that any other event that is caught by the default handler but isn’t a character generation event is going to go straight on through to the core script.

Before we create the ''bdm_sys_chargen'' script we are going to need some new constants defined. Create a new script called ''bdm_2da_constants_h'' and put it in folder ''\Backgrounds demo\_Core Includes''. Now add the following to this script:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

These constants provide a way for us to refer to the background IDs that we defined in the 2DA files without having to remember the numbers. Constants like this also make your code more readable. If you need to add more new items to 2DAs when you are modding something else you can also add constants for them here. From now on we will be using these background constants instead of the original single player background constants that you can find in the ''2da_constants_h'' script. That means we’d better find all the places where those constants are used and update them with our own scripts.

Create another new script and call it ''bdm_sys_chargen'' and put it in a folder called ''\Backgrounds demo\_Systems''. Put the following code in it:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Debug Data.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// This fires when the player selects the icon corresponding to any of
// the available backgrounds
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Set the background on the player and reinitialize plot flags
// for the background
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Generate the index into the equipment template 2da and
// then load the starting equipment based on the data returned.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / treat as the same
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Setting default values for player character");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

There are two events in the original sys_chargen script that we need to replace because they deal with backgrounds. The first of these is EVENT_TYPE_CHARGEN_SELECT_BACKGROUND and the other is EVENT_TYPE_CHARGEN_END. For the second event we only need to change the case where the character is being created in quickstart mode, so we just handle that section of the code. The objective here is to change only as much as we need to and then pass any remaining events through to the original sys_chargen script. Take some time to compare the new script with Bioware’s ''sys_chargen'' script .

You will notice that we include a script called ''bdm_sys_chargen_h'' and that we use some functions with a ''bdm_'' prefix. Those functions are contained in that include file which we’ll write now. Essentially these are modifications of a couple of functions from the ''sys_chargen_h'' include file. Create a new script and call it ''bdm_sys_chargen_h''. Put it in folder ''\Backgrounds demo\_Systems\Includes'' and add the following code:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Set the background variable
// - Create creature property (or check what we used so far
// - We don't set backgrounds on non player generated chars.
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Give one skill
// - retrieve the skill that is granted by the background from backgrounds.xls
// - give it to the player.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Setting plot flags, race: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// First, init all flags (debug setup)
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Lets examine these two functions. First you should compare them to their original versions. For ''bdm_Chargen_SelectBackground()'' we have actually made a more generic version of the function that should work with any backgrounds. We have removed the hard coded values for the background abilities and now use the function ChargenGetBackgroundSkill() which actually gets the background skill from the backgrounds 2DA file that we edited earlier (recall the last three columns that give a skill depending on background and race). If you need fancier logic than just reading the values form the GDA (e.g. like Bioware’s logic for the Noble background) then you can always go back to hard coding them the way Bioware did.

The second function is ''bdm_Chargen_SetupPlotFlags()'' which does just what it says. Remember the plot we created earlier? Here we set the appropriate flag based on race and background.

{{TutorialRef|Script}}

== Testing that everything works ==
Now compile your scripts and export your module. Also, make sure that you export your talk table.

'''IMPORTANT!''' ''Always make sure you empty your \Dragon Age\packages\core\override folder after doing an export. Due to a bug in the current toolset your single player game will become damaged if you don’t do this before playing.''

You should now be able to run your game and see the backgrounds you created appear in character generation. If you want to test that the background plots have been set correctly, add an NPC to the start area and create a conversation for them in which each line is switched according to a background plot flag. You can also check that the character is receiving the abilities that we set in the 2DAs.

'''NOTE''' ''There seems to be no way to change the popup message that comes up at the beginning of character generation. Altering the Pre-chargen string ID in the loadhints GDA does not seem to do anything.''

{{TutorialRef|Exporting a module}}

== Optional extras ==
There are a couple of other Bioware scripts that reference the background constants. They are not essential to modify because they are not used anywhere by default. The genev_tutorial script uses a background check but unless you plan on firing the tutorial from your module then you won’t have need of it. Also there is at least one debug script that makes use of the original single player backgrounds (to grant a background plot flag to the PC) so if you want similar debug functionality you may have to roll your own function.

== Race & Gender descriptions ==
If your module is not set in Ferelden, you may wish to change the descriptions of the Race and Gender buttons that appear during Character Creation.

The Race descriptions are in the Description column of the RACE_base 2DA, so you can replace them with new strings. As before, until the bug is fixed, use a string id in the 100000000 range.

Unfortunately, the gender description is hard-coded in the game as string id 377283. Fortunately, you can make a [[String_editor#Editing_a_string_with_a_specific_id | local version]] of this string, which only applies to your campaign.

Alternatively, if you an advanced user who is familar with the [[UI_Tutorial_%28draft%29 | UI Tutorial]], it's set in the GUI's Localization.as file as LOC_GENDER_DESCRIPTION = 377283, which is then used in the RaceGenderScene.as file. after editing the Localization.as file, you compile it and inject it into the appropriate .gfx'es.

== Conclusion ==
In this tutorial we have demonstrated a way to modify the backgrounds used in the game without altering any of the core scripts. It is expected that a similar approach could be taken to modding other aspects of the game such as adding classes or races. In these cases the scripts that were created in this tutorial could be extended to handle other parts of the character generation process such as class and race selection.

[[Category:Character generation]]
[[Category:Tutorials]]
[[Category:Translations_ru]]
{{Languages|Backgrounds tutorial}}

Backgrounds tutorial/ru

2011-08-26T11:25:02Z

Silderon:

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете [http://social.bioware.com/project/4695/ скачать фикс] от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //извлечение с текущего события его типа
int nEventHandled = FALSE; //флаг, следящий за тем, было ли обработано события или нет.
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //предварительна загрузка ресурсов для генерации персонажа
StartCharGen(GetHero(),0,TRUE); //начало генерации
break;
}
default:
{
// -----------------------------------------------------------------
// Обработка отправленных движков события генерации персонажа.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //если событие не было обработано, оно отправляется в core-скрипт
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Отладка.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// Срабатывает, когда игрок кликает по иконке одной из доступных
// предысторий.
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Выбор предыстории для игрока и установка соответствующих предыстории
// plot-флагов.
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Проверяет шаблоны, указанные в 2DA-файлах
// и, руководствуясь ими создает герою инвентарь.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / то же самое
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Установка стандартный параметров для игрового персонажа.");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Установка переменной предыстории
// - создание внешности героя (или использование одной из заготовок)
//
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Игрок получает один навык.
// - найти нужный навык в файле backgrounds.xls
// - присвоить его игроку.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Установка plot-флагов расы: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// Сперва происходит инициализация всех флагов
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Создание персонажа]]
[[Category:Tutorials]]
[[Category:Translations_ru]]
{{Languages|Backgrounds tutorial}}

Backgrounds tutorial/ru

2011-08-26T11:23:43Z

Silderon:

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете [http://social.bioware.com/project/4695/ скачать фикс] от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //извлечение с текущего события его типа
int nEventHandled = FALSE; //флаг, следящий за тем, было ли обработано события или нет.
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //предварительна загрузка ресурсов для генерации персонажа
StartCharGen(GetHero(),0,TRUE); //начало генерации
break;
}
default:
{
// -----------------------------------------------------------------
// Обработка отправленных движков события генерации персонажа.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //если событие не было обработано, оно отправляется в core-скрипт
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Отладка.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// Срабатывает, когда игрок кликает по иконке одной из доступных
// предысторий.
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Выбор предыстории для игрока и установка соответствующих предыстории
// plot-флагов.
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Проверяет шаблоны, указанные в 2DA-файлах
// и, руководствуясь ими создает герою инвентарь.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / то же самое
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Установка стандартный параметров для игрового персонажа.");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Установка переменной предыстории
// - создание внешности героя (или использование одной из заготовок)
//
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Игрок получает один навык.
// - найти нужный навык в файле backgrounds.xls
// - присвоить его игроку.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Установка plot-флагов расы: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// Сперва происходит инициализация всех флагов
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Character generation]]
[[Category:Tutorials]]
[[Category:Translations_ru]]
{{Languages|Backgrounds tutorial}}

Backgrounds tutorial/ru

2011-08-26T11:22:56Z

Silderon:

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете [http://social.bioware.com/project/4695/ скачать фикс] от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //извлечение с текущего события его типа
int nEventHandled = FALSE; //флаг, следящий за тем, было ли обработано события или нет.
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //предварительна загрузка ресурсов для генерации персонажа
StartCharGen(GetHero(),0,TRUE); //начало генерации
break;
}
default:
{
// -----------------------------------------------------------------
// Обработка отправленных движков события генерации персонажа.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //если событие не было обработано, оно отправляется в core-скрипт
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Отладка.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// Срабатывает, когда игрок кликает по иконке одной из доступных
// предысторий.
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Выбор предыстории для игрока и установка соответствующих предыстории
// plot-флагов.
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Проверяет шаблоны, указанные в 2DA-файлах
// и, руководствуясь ими создает герою инвентарь.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / то же самое
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Установка стандартный параметров для игрового персонажа.");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Установка переменной предыстории
// - создание внешности героя (или использование одной из заготовок)
//
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Игрок получает один навык.
// - найти нужный навык в файле backgrounds.xls
// - присвоить его игроку.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Установка plot-флагов расы: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// Сперва происходит инициализация всех флагов
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Character generation]]
[[Category:Tutorials]]
[[Category:Translations_ru]]
{{Languages|Area tutorial}}

Backgrounds tutorial/ru

2011-08-20T17:37:10Z

Silderon:

Backgrounds tutorial/ru

2011-08-19T21:52:24Z

Silderon:

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете скачать фикс от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //извлечение с текущего события его типа
int nEventHandled = FALSE; //флаг, следящий за тем, было ли обработано события или нет.
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //предварительна загрузка ресурсов для генерации персонажа
StartCharGen(GetHero(),0,TRUE); //начало генерации
break;
}
default:
{
// -----------------------------------------------------------------
// Обработка отправленных движков события генерации персонажа.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //если событие не было обработано, оно отправляется в core-скрипт
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Отладка.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// Срабатывает, когда игрок кликает по иконке одной из доступных
// предысторий.
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Выбор предыстории для игрока и установка соответствующих предыстории
// plot-флагов.
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Проверяет шаблоны, указанные в 2DA-файлах
// и, руководствуясь ими создает герою инвентарь.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / то же самое
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Установка стандартный параметров для игрового персонажа.");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Установка переменной предыстории
// - создание внешности героя (или использование одной из заготовок)
//
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Игрок получает один навык.
// - найти нужный навык в файле backgrounds.xls
// - присвоить его игроку.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Установка plot-флагов расы: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// Сперва происходит инициализация всех флагов
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Character generation]]
[[Category:Tutorials]]

Backgrounds tutorial/ru

2011-08-19T19:16:39Z

Silderon:

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете скачать фикс от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //extract event type from current event
int nEventHandled = FALSE; //keep track of whether the event has been handled
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //preloads resources for character generation
StartCharGen(GetHero(),0,TRUE); //initiates character generation
break;
}
default:
{
// -----------------------------------------------------------------
// Handle character generation events sent by the engine.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //If this event wasn't handled by this script, let the core script try
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Debug Data.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// This fires when the player selects the icon corresponding to any of
// the available backgrounds
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Set the background on the player and reinitialize plot flags
// for the background
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Generate the index into the equipment template 2da and
// then load the starting equipment based on the data returned.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / treat as the same
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Setting default values for player character");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Set the background variable
// - Create creature property (or check what we used so far
// - We don't set backgrounds on non player generated chars.
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Give one skill
// - retrieve the skill that is granted by the background from backgrounds.xls
// - give it to the player.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Setting plot flags, race: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// First, init all flags (debug setup)
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Character generation]]
[[Category:Tutorials]]

Backgrounds tutorial/ru

2011-08-19T19:15:53Z

Silderon: Created page with "== Вступление == В этом туториале мы расскажем вам, как можно редактировать предыстории, которые м..."

== Вступление ==

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

1 – если сюжет вашей кампании разворачивается не в мире Dragon age;

2 – если вы хотите уменьшить количество существующих предысторий.

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

Для прохождения данного туториала читателям рекомендуется быть ознакомленными с основами скриптинга и программирования. В ином случае удачное прохождение маловероятно. Чем больше вы будете слепо копировать код, используемый в туториале, тем выше вероятность того, что возникнут ошибки, которые вы будете не в силах исправить.

== Демо модуль для предысторий ==
Для данного туториала подойдет любой модуль. Если вы хотите создать отдельный тестовый модуль специально для прохождения туториала, просто создайте модуль с одной локацией и начальной территорией. Убедитесь, что единственным выбранным пунктом в иерархии модуля является '''Core game resources'''(Базовые игровые ресурсы). Это будет означать, что модуль отдельный и что он не вносит никаких изменений в оригинальную кампанию или в другие модули. Давайте назовем наш модуль Backgrounds demo и будем добавлять к названиям наших файлов префикс '''bdm_''', чтобы быть уверенными, что файла с таким названием больше нет.
Мы заменим существующие предыстории тремя собственными. Вы можете использовать их как угодно. Можете написать отдельный сюжет для каждой предыстории, как это сделано в оригинале (важно, чтобы длинна сюжетов были одинакова). Или же ваша предыстория может влиять только на диалоги, '''plot'''-опции и основную часть вашей игры.
Для нашей демки мы создадим модуль, сюжет которого начинается в маленькой человеческой деревушке (это поможет нам придумать предыстории, на практике мы создавать деревню не будем). В деревне есть маг, который играет в сюжете важную роль. Мы позволим игроку начать игру в качестве ученика этого мага (если игрок - маг), его слуги (если игрок человек или эльф и при этом не маг) или путешественника, который пришел навестить мага (если игрок не человек и не маг). Таким образом, у нас получилось три предыстории:

* Слуга
* Ученик
* Путешественник

== Создание string-переменных для предыстории ==
Перед тем, как мы приступим к редактированию файлов '''2DA''', нужно создать несколько переменных типа '''string'''. Откройте '''string'''-редактор в тулсете и создайте таблицу с названием '''“Background Demo”'''. В ней создайте следующие переменные:

[[Image:Back_tut_talk_table.png]]

'''ID'''-номера ваших строчек могут быть другими. Это не страшно, просто в дальнейшем вам придется заменять указанные мною '''ID''' на свои.

'''ВАЖНО!''' ''В игре присутствует баг, который не позволяет '''ID'''-номеру принимать значения выше '''109 912 680'''. Чтобы исправить его, вы можете скачать фикс от сообщества. Или же вы можете зайти в свойства модуля и изменить начальное значение '''ID''' так, чтобы оно было меньше критического. После этого, '''string'''-редактор будет генерировать '''ID'''-номера, значения которых не приведут к багу. После создания переменных для предысторий, перезагрузите начальное значение '''ID'''-номера (это позволит вам избежать нужды в скачивании фикса от Bioware и уменьшит возможность несовместимости с другими модулями).''

Вы, должно быть, заметили, что мы задали разные названия и описания предыстории путешественника в зависимости от расы героя. Об этом мы расскажем вам дальше.

{{TutorialRef|String editor}}

== Редактирование 2DA-файлов ==
Следующим шагом будет редактирование рабочих листов документа под названием '''backgrounds.xls'''. Скопируйте этот документ: мы будем редактировать копию, а не оригинал. Рекомендую вам прочесть статью с описанием работы с '''2DA'''-файлами.
Первый лист называется '''“background”'''. Отредактируйте его так, чтобы у вас получилось как на скриншоте:

[[Image:back_tut_backgrounds.png]]

'''2DA'''-файлы соединяются и создают '''M2DA'''-файлы, которые заменяют оригиналы с аналогичными названиями. В этом случае нам надо будет заполнить неиспользуемые слоты, чтобы в модуле не было предысторий из оригинала. Поэтому два последних слота мы назвали '''unused1''' и '''unused2'''.
Названия и описания предысторий в зависимости от выбранной расы будут взяты с таблицы string-переменных, так что здесь мы можем оставить соответствующие поля пустыми(если в таблице '''string'''-переменных указаны названия и описания предысторий, столбцы '''NameStrRef''' и '''DesStrRef''' не используются. Похоже, что '''ToolTipStrRef''' также нигде не используется. Если хотите, можете его чем-то заполнить).

Существует три колонки с расами, каждая из которых определяет, какая предыстория какой расе доступна. Также есть три колонки класса, которые определяют, какая предыстория какому классу доступна. На скриншоте видно, что предыстория слуги доступна эльфу и человеку, воину и разбойнику, предыстория ученика доступна магу-эльфу и магу-человеку, предыстория путешественника – эльфу и гному, воину и разбойнику.

Последние три колонки определяют стартовый навык для каждой предыстории и расы. Заметьте, по умолчанию эти колонки не связаны со скриптом генерации персонажа (они содержатся в сложном блоке кода) и не используются, но мы исправим это на стадии скриптинга. Вы должны быть внимательными, так как каждая колонка связана с '''ID'''-номером расы:

'''1 – гном, 2 – эльф, 3 – человек. '''

Номера могут быть размещены в другом порядке по отношению к столбцам расы данной таблицы. Номером в колонке является значение '''ID'''-номера навыка, указанное в таблице '''ABI_base.xls'''. В этой демке мы просто зададим одинаковые навыки всем расам определенных предысторий. Слуги получат бонус к тактике боя, ученики – бонус к убеждению, а путешественники - к выживанию.

Далее мы отредактируем таблицу под названием '''background_names'''.

[[Image:back_tut_bg_names.png]]

Убедитесь, что '''ID'''-номера этой таблицы совпадают с '''ID'''-номерами ваших '''string'''-переменных. Обратите внимание, что для учеников и слуг вне зависимости от расы мы используем одинаковые переменные, а для путешественников разные строчки. Это чтобы вы увидели, как одной и той же предыстории можно присваивать разные имена и описания. Все они хранятся в одном и том же '''ID'''-номере предыстории, но во время генерации персонажа игрок может увидеть разные названия, описания и иконки для одной и той же предыстории. В оригинальной кампании этот метод применялся в случае героем знатного происхождения, которое менялось на человеческое или гномье в зависимости от выбранной расы.

'''ПРИМЕЧАНИЕ''' ''– во время разделения единой предыстории на части вы должны быть внимательными. Названия и описания должны быть разными! Если описания будут одинаковыми, движок сочтет предыстории идентичными, даже если их названия будут разными.''

Теперь отредактируйте '''background_desc''' как показано на скрине.

[[Image:back_tut_bg_desc.png]]

Снова обратите внимания на различные описания для предыстории путешественника.
Теперь отредактируем '''background_icons'''. В этой демке мы будем использовать иконки из оригинала, но при желании вы можете использовать собственные.
'''“background_icons"'''

[[Image:back_tut_bg_icons.png]]

Таблица под названием '''background_defaults''' должна содержать все возможные комбинации расы, предыстории и класса. Значение '''ID'''-номера колонки считается следующим образом:
'''(1000 * IDрасы) + (100 * IDкласса) + Idпредыстории'''

[[Image:back_tute_bg_defaults.png]]

В колонке '''“Label”''' должна содержаться комбинация (правда, это ни на что не влияет). В нашей демке место появления героя всех комбинации будет одинаковым (локация, выбранная в модуле по умолчанию) но если вы хотите создать индивидуальное начало для каждой предыстории, вы можете использовать для этого две следующие колонки (чтобы это сработало, нужно написать скрипт).
В колонке '''“Template”''' вы можете вписать название файла с существом, которое вы хотите использовать в качестве шаблона для определенной комбинации расы\предыстории\класса. На скриншоте вы можете увидеть, что мы используем стандартные шаблоны, идущие в комплекте с тулсетом, но вы запросто можете пользоваться своими. Заметьте, что от шаблона герой получает только инвентарь, так что для шаблонных персонажей вам не нужно задавать ничего кроме инвентаря.

Имя берется со '''string'''-переменных, так что если вы хотите задать герою новое имя, вам придется создать новые переменные в '''string'''-редакторе.
В конце мы видим столбец с возможностями. Как и в случае с навыками в таблице предыстории, '''ID'''-номера возможностей соответствуют записям в файле '''ABI_base.xls'''. Раса, класс и предыстория являются единственными источниками стартовых возможностей. Поэтому перед тем, как вписывать в столбец '''ID'''-номер возможности, вам следует узнать, какие возможности уже добавлены. Это поможет избежать дубликатов.
Последняя таблица называется '''chargen_preload'''. Два столбца этой таблицы должны точно совпадать со значениями '''ID'''-номеров и шаблонов из предыдущей.

[[Image:back_tut_chargen_preload.png]]

{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}

== Компиляция и исправления файлов GDA ==
Теперь скомпилируйте файл '''backgrounds.xls''' и положите полученный в результате компиляции '''GDA'''-файл в папку '''AddIns\название_модуля\module\override'''
Никогда не кладите ничего в папке '''AddIns\название_модуля\core\override''' иначе изменения коснуться всех модулей.
Раньше был баг, из-за которого '''string'''-переменный с большими '''ID'''-значениями компилировались некорректно. Сейчас он исправлен. Чтобы обойти этот баг, '''GDA'''-файлы вручную редактировались в тулсете. Если же вы взглянете на '''ID'''-номера сейчас, то увидите, что они правильные.

{{TutorialRef|Compiling 2DAs|GDA}}

== Создание plot-файла для предыстории ==
'''Plot'''-файл предыстории используется для отслеживания выбранной игроком предыстории и позволяет менять диалоги в зависимости от выбора.
Оригинальная кампания для отслеживания выбранной предыстории использует '''plot'''-файл под названием '''gen00pt_backgrounds'''. Вы можете найти его в папке '''\_Global\Generic''' в разделе '''“Plots”'''. Мы создадим похожий файл для наших предысторий. Создайте новый '''plot''' и назовите его '''bdm_000pt_backgrounds''' (я использую три нуля для обозначения файлов, не привязанных к конкретной локации, вы можете использовать собственное обозначение, только не забудьте о нем в процессе прохождения туториала). Добавьте главные '''plot'''-флаги, как это изображено на скриншоте.

[[Image:Back_tut_bg_plot.png]]

Вы также можете добавить определенные флаги. Они используются для создания комбинации главных флагов(таких как '''TRAVELLER'''(путешественник)) или для добавления составных условий, таких как '''FEMALE_APPRENTICE'''(женщина-ученица) или '''ELVEN_APPRENTICE'''(эльф-ученик). Определенный флаги, тем не менее, не входят в рамки данного туториала.

{{TutorialRef|Designer Resources|Plot}}

== Написание скриптов ==
Мы не будем редактировать скрипты оригинальной кампании, мы добавим свои. Для лучшего понимания того, что мы будем делать, вы можете ознакомиться со скриптами оригинала, но ни в коем случае не редактируйте их. Используя в своем модуле измененные скрипты оригинала, вы делаете ваш модуль несовместимым с возможными будущими патчами.
Начнем с написания скрипта, обрабатывающего события генерации персонажа. Обычно, этот скрипт назначается модуль-скриптом. Создайте новый скрипт и назовите его '''bdm_module_core'''. Вы должны решить, какубю структуру папок использовать для распределения ваших скриптов. Советую помещать их в папке с названием модуля: это позволит отделить их от скриптов оригинала. Если вам нравится оригинальная структура, вы сможете воссоздать ее в папке скриптов вашего модуля.
Модуль-скрипт оригинальной кампании называется '''module_core''' и лежит в папке '''\_Core Scripts'''.
А наш модуль-скрипт под названием bdm_module_core мы положим в папку '''\Backgrounds demo\_Core Scripts''' (знак нижнего подчеркивания вынесет вашу папку в самый верх списка. Похоже, '''Bioware''' случайно создали одну папку без знака подчеркивания. Думаю, '''_Core''' и '''Core''' - одна и та же дирректория). Структуризация скриптов подобным образом упростит вашу работу.

Откройте ваш bdm_module_core и напишите в нем следующее:

<dascript>
#include "global_objects_h"
void main(){
event ev = GetCurrentEvent();
int nEvent = GetEventType(ev); //extract event type from current event
int nEventHandled = FALSE; //keep track of whether the event has been handled
switch(nEvent){
case EVENT_TYPE_MODULE_START:{
// -----------------------------------------------------------------
// Initiate character generation.
// -----------------------------------------------------------------
PreloadCharGen(); //preloads resources for character generation
StartCharGen(GetHero(),0,TRUE); //initiates character generation
break;
}
default:
{
// -----------------------------------------------------------------
// Handle character generation events sent by the engine.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END)
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"bdm_sys_chargen.ncs");
nEventHandled = TRUE;
}
break;
}

}
if (!nEventHandled) { //If this event wasn't handled by this script, let the core script try
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);
}
}
</dascript>

Теперь жмите '''File -> Manage modules ->''' кнопка '''Properties'''. Установите только что написанный скрипт в качестве модуль-скрипта('''module script''')
Теперь наш новый скрипт выполняет функцию модуль-скрипта.
Посла обработки события, наш модуль-скрипт решает, нужно ли отправлять событие в '''module_core''' для дальнейшей обработки.
Первое описанное нами событие носит название '''EVENT_TYPE_MODULE_START''' и отвечает за начало процесса генерации персонажа. В этом случае после начала генерации, событие передается в '''module_core''', где собственно и происходит сам процесс генерации.

'''ПРИМЕЧАНИЕ:''' ''код из других секций скрипта не нуждается в редактировании. Вообще не понятно, за что он отвечает.''

Дальше мы займемся целой группой событий. Если вы заглянете в нижнюю часть '''module_core'''-скрипта, то увидите, что часть написанного там за исключением некоторых деталей совпадает с нашим кодом, отвечающим за обработку событий. Вместо того, чтобы пропустить наши события, генерирующие персонажа через sys_chargen.nc, мы пропустим их через наш собственный скрипт под названием bdm_sys_chargen.ncs, который мы вскоре напишем.
Если нам попадется одно из событий, генерирующих персонажа, мы должны обработать его сами и освободить от этого core-скрипт, поэтому мы установим флагу '''nEventHandled''' значение '''TRUE'''(истина): '''nEventHandled = TRUE;'''
Заметьте, что все другие события обрабатываться нашим модуль-скриптом не будут, они сразу же направятся к core-скрипту.
Перед созданием bdm_sys_chargen скрипта нам понадобятся несколько новых констант. В папке '''\Backgrounds demo\_Core Includes''' создайте новый скрипт с названием '''bdm_2da_constants_h'''.
Откройте его и напишите внутри следующее:

<dascript>
// -----------------------------------------------------------------------------
// Backgrounds - rules/backgrounds.xls
// -----------------------------------------------------------------------------
const int BACKGROUND_SERVANT = 1;
const int BACKGROUND_APPRENTICE = 2;
const int BACKGROUND_TRAVELLER = 3;
</dascript>

Три константные переменные позволяют нам сослаться на второстепенные параметры персонажа, которые мы указали в '''2DA'''-файлах, без использования их '''ID'''-номеров. Подобные константы также делаю ваш код более читабельным. Если во время редактирования вам нужно добавить новые параметры в '''2D'''A-файлы, вы можете также создать для них переменные в этом скрипте('''bdm_2da_constants_h'''). С этого момента, вместо оригинальных констант(которые вы можете увидеть в скрипте под названием '''2da_constants_h''') мы будем использовать собственные. Это значит, что мы должны найти все участки, где используются эти оригинальные переменные и заменить их своими.
В папке '''\Backgrounds demo\_Systems''' создайте новый скрипт с названием '''bdm_sys_chargen''' и напишите в нем:

<dascript>
#include "bdm_sys_chargen_h"
#include "log_h"

const int CHARGEN_QUICKSTART_QUICK = 0;
const int CHARGEN_QUICKSTART_NORMAL = 1;
const int CHARGEN_QUICKSTART_ADVANCED = 2;

void _RunChargen(int nRace, int nClass, object oChar, int nBackground)
{

Chargen_InitializeCharacter(oChar);
Chargen_SelectGender(oChar,GENDER_MALE);
Chargen_SelectRace(oChar,nRace);
Chargen_SelectCoreClass(oChar,nClass);
Chargen_SelectBackground(oChar, nBackground,FALSE);

int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);

}

void main(){
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
object oChar = GetEventObject(ev,0);

int nMode;
int nInt0 = GetEventInteger(ev,0);
int nInt1 = GetEventInteger(ev,1);
// -------------------------------------------------------------------------
// Debug Data.
// -------------------------------------------------------------------------
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType)
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);

int nEventHandled = FALSE;

switch (nEventType)
{
// ----------------------------------------------------------------------
// This fires when the player selects the icon corresponding to any of
// the available backgrounds
//
// nInt0 - Constant BACKGROUND_* integer
// ----------------------------------------------------------------------
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {
int nBackground = nInt0;
// -----------------------------------------------------------------
// Set the background on the player and reinitialize plot flags
// for the background
// -----------------------------------------------------------------
Chargen_InitializeCharacter(oChar,TRUE);
Chargen_SelectGender(oChar,GetCreatureGender(oChar));
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));

bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);
bdm_Chargen_SetupPlotFlags(oChar);

// -----------------------------------------------------------------
// Generate the index into the equipment template 2da and
// then load the starting equipment based on the data returned.
// -----------------------------------------------------------------
int nClass = GetCreatureCoreClass(oChar);
int nRace = GetCreatureRacialType(oChar);
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);
Chargen_InitInventory(oChar,0,nEquipIdx);
nEventHandled = TRUE;
break;
}
case EVENT_TYPE_CHARGEN_END: {
nMode = nInt0;
int nQuickStart = nInt1;
// 0 - quickstart
// 1 - normal \
// 2 - advanced / treat as the same
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode)
+ ", Quick Start: " + IntToString(nQuickStart));
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Setting default values for player character");

int nRandClass = abs((GetLowResTimer()%3)+1);

if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );

WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);
}
else // mage
{
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);
}
Chargen_SetNumTactics(oChar);
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));
SendEventModuleChargenDone("", "");
nEventHandled = TRUE;
}
break;
}
} //end switch

if (!nEventHandled){
HandleEvent(ev, R"sys_chargen.ncs");
}

}
</dascript>

</dascript></nowiki>

В оригинальном '''sys_chargen''' скрипте есть два события, связанные с генерацией персонажа. Мы должны их отредактировать. Первое называется '''EVENT_TYPE_CHARGEN_SELECT_BACKGROUND''', второе - '''EVENT_TYPE_CHARGEN_END'''.
Во втором событии мы должны изменить только случай, в котором персонаж был создан в '''Режиме быстрой загрузки'''. Нашей целью является изменение всего, что надо и передача всех оставшихся событий в оригинальный sys_chargen скрипт. Сравните '''sys_chargen''' от '''Bioware''' с тем, что вы только что создали.

Вы заметите, что мы подключили скрипт с названием '''bdm_sys_chargen_h''' и использовали функции с префиксом '''bdm_'''. Эти функции будут содержаться в скрипте, который мы сейчас напишем.
По сути, они являются усовершенствованными аналогами функций с инклуд-файла под названием '''sys_chargen_h'''.
В папке '''\Backgrounds demo\_Systems\Includes''' создайте новый скрипт и назовите его '''bdm_sys_chargen_h'''.
Внутри напишите это:

<dascript>
#include "sys_chargen_h"
#include "bdm_2da_constants_h"
#include "wrappers_h"
#include "plt_bdm_000pt_backgrounds"

void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)
{
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);
// -------------------------------------------------------------------------
// 1. Set the background variable
// - Create creature property (or check what we used so far
// - We don't set backgrounds on non player generated chars.
// -------------------------------------------------------------------------
if (bUnApply)
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);
}
else
{
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);
}
// -------------------------------------------------------------------------
// 2. Give one skill
// - retrieve the skill that is granted by the background from backgrounds.xls
// - give it to the player.
// -------------------------------------------------------------------------
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);
if (nAbility)
{
_AddAbility (oChar, nAbility, bUnApply);
}
}

void bdm_Chargen_SetupPlotFlags(object oChar)
{
int nRace = GetCreatureRacialType(oChar);
int nBackground = GetPlayerBackground(oChar);

Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Setting plot flags, race: "
+ IntToString(nRace) + ", background: " + IntToString(nBackground));

// First, init all flags (debug setup)
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);

switch (nBackground)
{
case BACKGROUND_SERVANT:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;
break;
}
case BACKGROUND_APPRENTICE:
{
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;
break;
}
case BACKGROUND_TRAVELLER:
{
switch(nRace)
{
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;
}
break;
}
}
}
</dascript>

Давайте рассмотрим эти две функции. Для начала сравните их с оригинальными. Наша функция '''bdm_Chargen_SelectBackground''' является более универсальной и может работать с любыми предысториями. Мы убрали сложные значения, определяющие начальные возможности для персонажа каждой предыстории и теперь используем функцию '''ChargenGetBackgroundSkill()''', которая берет возможности с '''2DA'''-файла предыстории, который мы отредактировали раньше (вспомните три последние столбца, определяющих начальные способности в зависимости от расы и предыстории).
Если этот способ вам не подходит, и вам нужна более сложная логика распределения возможностей (как в предыстории аристократа), вы всегда можете вернуться к методу кодирования, как это сделали '''Bioware'''.
Вторая функция называется '''bdm_Chargen_SetupPlotFlags()'''. Что она делает, можно понять из названия. Помните '''plot'''-файл, созданный нами ранее? Здесь мы устанавливаем нужный нам флаг в зависимости от выбранной расы и предыстории.

{{TutorialRef|Script}}

== Проверка работоспособности ==

Теперь скомпилируйте ваши скрипты и экспортируйте их в модуль. Также убедитесь, что вы экспортировали вашу '''string'''-таблицу.

'''ВАЖНО!''' ''После экспорта всегда проверяйте, есть ли что-то в папке '''\Dragon Age\packages\core\override'''. Наличие каких-либо файлов может привести к багу и повредить оригинальную кампанию.''

Теперь вы можете запустить игру и увидеть созданные вами предыстории. Если вы хотите проверить, правильно ли установлены '''plot'''-флаги, добавьте в стартовую локацию непися, создайте для него диалоги, в котором каждая строчка будет выводиться в зависимости от расы\класса\предыстории\пола героя. Также стоит убедиться, что герой получает возможности, указанные в '''2DA'''-файлах.

'''NOTE''' ''Кажется, изменить сообщение, которое выводится в начале генерации персонажа невозможно.''

{{TutorialRef|Exporting a module}}

== Опциональные расширения ==
У Bioware есть парочка других скриптов, которые имеют отношение к константам предысторий. Их можно не менять, так как они нигде не используются. Скрипт из туториала по генерации использует проверку предыстории, но вам она не нужна, разве что вы хотите использовать свой модуль для написания туториала. Также есть, по крайней мере, один отладочный скрипт, который использует предыстории из оригинала (чтобы гарантировано установить нужный '''plot'''-флаг). Если вы хотите, чтобы ваши предыстории обрабатывались подобным образом, вы должны написать для себя схожий скрипт.

== Описания расы и пола ==
Если действие вашего модуля происходит не в Ферелдене, вы, возможно, пожелаете изменить описания расы и пола, которое появляется во время генерации персонажа. Описание расы содержится в столбце '''“Description”'''(описание) в документе '''RACE_base 2DA'''. Вам просто надо изменить строчки, указанные там. Используйте значения '''ID'''-номеров в районе '''100000000'''. К сожалению, описание пола сложно закодировано в '''string'''-переменной с '''ID'''-номером '''377283'''. К счастью, вы можете сделать локальную версию этой строчки. Они будет применяться исключительно для вашей кампании.
Или же, если вы опытный пользователь и знакомы с '''UI''' туториалом, то нужная нам строчка содержится в файле '''Localization.as''' в виде переменной '''LOC_GENDER_DESCRIPTION = 377283''', которая позже используется в файле '''RaceGenderScene.as'''. После редактирования файла '''Localization.as''' вы должны скомпилировать его и внедрить в соответствующие '''.gfx'''-файлы.

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

[[Category:Character generation]]
[[Category:Tutorials]]