Скриптование

[Svoboда 3]

Тема для обсуждения скриптов всего и всех в серии игр STALKER.

Задавая вопрос (!):
1. Внимательно изучите суть вопроса. Вопрос должен соответствовать выбранной Вами темы. Это поможет сохранить порядок и читабельность темы, а также облегчит поиск и понимание сего;
2. Изучите то, что уже есть в теме (пролистайте "руками", воспользуйтесь поиском на форуме);
3. Изучите информацию которая может вам помочь:

  Информация (Показать)

  Общая (Показать)

Stalkerin. Там есть много хороших статей касательно данной темы.
Уроки по модостроению. Есть рабочие примеры готовых скриптов различного назначения.

  Скрипты (Показать)

Справочное руководство по языку Lua 5.1
https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual/ru
Справочник по функциям и классам. Собрано много информации по функциям и классам, не всем, но по основные сведения предоставлены.

  Логика (Показать)

Логика со вступлением и четырьмя частями:

  Просмотр (Показать)

Вступление
Часть первая
Часть вторая
Часть третья
Часть четвертая.

Smart_terrain (в простонароде - гулаг)
Интересный способ настроики логики для гулагов
Скриптовая часть игровой логики

4. Дабы не превращать обсуждение в "кашу" разной информативной направленности, задавайте несколько вопросов по порядку (в разных постах) после того, как получите ответ на предыдущий вопрос;
5. "Спасибо" и тому подобное - будьте так любезны в ПМ. Если не любите писать в ПМ, в конце вопроса напишите фразу: "Заранее спасибо!" - или что-то в этом духе;
6. ПОЖАЛУЙСТА! Указывайте, для какой игры Вам необходима информация (ТЧ, ЧН, ЗП), если стоит мод - укажите название мода;
7. Если Вы что-то сделали и результат не такой, какой Вами задумывался, то, пожалуйста, приводите коды которые Вы изменяли/писали целиком! Это поможет другим правильно ответить на Ваш вопрос, а также оградит Вас от лишней писанины.
8. Оформляйте сообщение. Пользуйтесь тегами для того, чтобы отделить код от текста. Пишите грамотно - ПОЛЬЗУЙТЕСЬ ЗНАКАМИ ПРЕПИНАНИЯ.
9. И помните: «Правильно заданный вопрос – половина ответа».

 

Какие вопросы следует задавать, а какие нет...

  Читать рекомендуется. (Показать)

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

 

Вопросы которые будут удалятся, следовательно их задавать не нужно:
-- Где находится та или иная функция?
Для ответа используем поиск по словам среди файлов оригинальной игры или мода, если объект поиска относится к нему, при помощью программы, которая Вам наиболее симпатизирует;
-- Как сделать что-то/то-то?
С подобными вопросами, либо в "ковырялки", где Вам вероятнее всего так же не ответят, либо выдвигаем мысли, подкреплённые теорией, практикой (идеальный вариант) и здравым рассудком;
-- Вопросы со смыслом: "сделайте", "совместите" и подобными глаголами повелительного наклонения.
-- К тому же удалению будут подвергаться вопросы, в которых масштабно не используются теги, для отделения кода и цитат от основного текста, а также не вписан в спойлер код размером превышающие семь строк.
Ответ на возможно возникший вопрос: В какую тему можно обратиться по поводу логики и спавна объектов?
В тему "ковырялок" соответствующей версии игры, для которой Вы задаёте вопрос.

И последнее: очень рекомендовано к прочтению Правила форума
 

---

[Viнt@rь 50]

*Shoker*, ты хотел сохранять в файл(текстовый и тп) свои переменные, и делать название файла таким же, как и название сейва?

Если я правильно тебя понял, то не лучше ли сохранить в пстор актора переменную с названием файла(в который сохранили свои переменные), а при загрузке, по этой переменной, можно загрузить все значения(содержимое) файла с твоими переменными, если ты боишься, что переменные из пстора актора можно читать только со спавна актора, то ты ошибаешься, можно читать и из метода load, в тот момент и можно получить название файла и его содержимое

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

Изменено 13 Ноября 2012 пользователем Viнt@rь

[Kirgudu 1 274]

Viнt@rь, там проблема не с сохранением и последующим чтением имени доп. файла, а с тем, как определить это имя. Есть 2 категории сэйвов, для которых сделать это затруднительно - квиксэйвы пользователя и автосэйвы, которые происходят при переходе на другую локацию (после диалога "вы уверены, что хотите перейти?..").

[Artos 99]

Kirgudu, нет никакой проблемы, если, как и говорит Viнt@rь, при создании сохранения запоминать эксклюзивное имя для "своего" доп.файла и, при загрузке считывать это имя, и соответственно из него все необходимое.

Однако, пора прекращать мусолить эту тему, тем более сам автор вопроса уже пошел по правильному пути (ИМХО), т.е. избрав путь хранить все в одном файле - самом сэйве игры.

[Kirgudu 1 274]

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

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

[Artos 99]

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

 

P.S.

Учитывая, что все же для некоторых вопрос остался открытым, о чем говорят слова из ЛС:

  Kirgudu писал(а):

...никто так и не привёл в теме ни одного примера, как можно отделить друг от друга всего два из общего количества типов сэйвов: квик по клавише F6 и автосэйв после отрабатывания диалога смены локации (в отличие от любого другого автосэйва, он так же, как и квиксэйв, не запускается из доступных скриптов консольной командой. ... Только общие слова. Тоже своего рода шоры, только с другой стороны, не находишь? А в результате обменялись в теме недоказанными мнениями.

Попробуем все же досказать недосказанное или недочитанное ;-)

  Пояснения по сэйвам: (Показать)

Имеется три основных момента:

1. Метод вызова: Все(!) сэйвы могут быть следующих типов:

1) Квик-сэйв (quicksave) - сохранение, которое создается при нажатии горячей кнопки, забинденной на это действие (обычно <F6>).

2. Штатный сэйв (nameFile.sav) - сохранение, которое создается через вызов меню и задания желаемого игроком имени.

3) Штатный авто-сэйв (autosave) - сохранение, которое создается при переходе актора на другую локацию.

При чем, это может быть как после "диалога смены локации", т.е. согласия игрока на переход, так и без оного, т.е. если переход имеет своим свойством silent_mode = 1 (без подтверждения).

 

Особняком стоят еще два типа:

4) Движковый авто-сэйв (autosave) - сэйв, который создается автоматически через определенное время непрерывной игры, что задается параметром autosave_interval.

5) Ручной сэйв - сэйв, который можно создать в любое время, открыв игровую консоль и отдав команду типа:

"save my_save.sav".

 

2. Движковый, скриптовой или консольный:

Легко увидеть, что вышеназванные 1) и 4) имеют движковую природу вызова, 5) - консольную, остальные - вызываются скриптами.

Т.о. для любого скриптового вызова можно однозначно узнать имя создаваемого сэйва.

Для штатных авто-сэйвов легко определить в методе биндера актора то, что актор собрался переходить на другую локацию и это и будет однозначным фактом того, что создается именно autosave.sav. Вот тут как раз и надеты шоры у Kirgudu..

 

3. Сохранение с прерыванием игры или без:

Сохранения могут создаваться с продолжением игры, т.е. без ее прерывания и при выходе из игры.

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

 

Итого в свете вопроса и недопоняток из цитаты выше - можно дать некоторые пояснения:

1. Типы сэйвов 2) и 3) не вызывают никаких неразрешимых затруднений по однозначной идентификации имени создаваемого сэйва в момент его создания, что может быть флагом для создания доп.файла иль чего иного.

2. Квик-сэйв и движковый авто-сэйв отлавливаются тоже достаточно однозначно.

Во-первых, это отсутствие имени в диалоговых (скриптовых) методах создания сэйвов.

И далее, критериями тут являются а) продолженная игра и б) открытый основной игровой экран, т.е. нет никаких иных окон или открытой консоли, что не так уж и сложно определять скриптами.

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

quicksave_2012_11_14__18_50.sav и quicksave_mod_2012_11_14__18_50.sav.

Уж как получить желаемый суффикс по дате и времени, определять дату и переименовывать созданные файлы наверное не стОит тут специально расписывать.

3. Ну и остался по сути последний "ручной" вариант создания сэйва игроком из консоли.

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

 

Иными словами, если хорошенько подумать головою и разложить все по полочкам никаких неоднозначностей с именами сэйвов не остается. Иной вопрос - а накой такие заморочки, если все можно записывать в основной сэйв? Тут уже каждый сам решает о "плюсах и минусах".

 

 

На этом, наверное, можно закрыть эту тему. Если же у кого-то остались конкретные вопросы "а как это сделать?" - то и говорить нужно о конкретном, а не об общем.

Изменено 14 Ноября 2012 пользователем Artos

[Artos 99]

Очередное напоминание очередному 'нечитателю', но "писателю":

  [b (Показать)

Куда задавать вопрос?[/b]":']

1. Поисковиком или иначе ищем - а не задавался ли подобный вопрос и не давался ли уже ответ(ы).

2. Читаем шапки топиков и по рекомендованным ссылкам просматриваем ФАКи, статьи и т.п.

3. Если вопрос по наличию или использованию функций/методов -> "Справочник по функциям и классам" + lua_help.script

4. Если вопрос по типичным функциям Lua -> "Язык Lua. Общие вопросы программирования"

5. Если вопрос типа "а как сделать/что означает/...?" -> "Ковырялка" соответствующей версии игры ТЧ/ЧН/ЗП

6. Если вопрос по конкретным игровым скриптам,алгоритмам или их заготовкам,черновикам, проблемам скриптов - этот топик.

... по тектурам, моделям, перл-скриптам, SDK и т.д. -> тематические топики.

 

Примечание: Адресные или личные вопросы (к конкретным адресатам) и "спасибки" -> ЛС

 

Изменено 15 Ноября 2012 пользователем Artos

[Clayman 104]

Прошу не пинать за нубские вопросы, скриптинг только осваиваю.

Вопрос по level.map_add_object_spot() и level.map_add_object_spot_ser(). Собственно исходя из справочной инфы все понятно, но такие нюансы:

В ЗП для отображения меток на объектах используется именно level.map_add_object_spot в pda.script (функция fill_primary_objects()), которая берет список объектов из таблицы и как я понял, апдейтится постоянно. Собственно почему нельзя было один раз в начале игры проставить все метки level.map_add_object_spot_ser? Это связано с ресурсами и производительностью?

Просто с заполнением новых локаций что будет экономней для ресурсов - проставить те-же 10-20 меток один раз вызвав level.map_add_object_spot_ser() или раздувать таблицу в pda.script?

[Artos 99]

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

  Пояснения: (Показать)

1. В ЗП для установки меток на объекты используется не только указанная тобою функция fill_primary_objects в pda.script.

2. Ты не правильно понял, точнее не дочитал алгоритм, и соответственно сделал неверные выводы о "постоянном апдейте" функции fill_primary_objects.

Эта функция вызывается только один раз, хотя и в методе апдейта биндера актора. Один раз - т.к. используется флаг primary_objects_filled и как только этот флаг на первом же апдейте будет установлен (в true) - все дальнейшие апдейты пропускают вызов функции fill_primary_objects.

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

"Раздувать" ли таблицу в pda.script - решать конечно же тебе, можно сделать и по-своему. Важно учесть момент установки меток, дабы сам объект успел появиться в игре, и первый апдейт актора тут как раз вполне подходит.

 

 

Изменено 20 Ноября 2012 пользователем Artos

[Старлей 88]

Вот кусок кода из ТЧ(1.004)

local ini = system_ini() local weather = level.get_weather() -- тип погоды local weather_sect = ini:r_string("weathers", weather) -- секция погоды, соответствующая типу

local ini = system_ini()

local weather = level.get_weather() -- тип погоды
local weather_sect = ini:r_string("weathers", weather) -- секция погоды, соответствующая типу

В ЧН работать не хочет, вылет...

Попробовал заменить на такой код:

local ini = ini_file("game.ltx") local weather = utils.cfg_get_string(ini, level.name(), "weathers", db.actor, false, "", "[default]") local weather_sect = ini:r_string("weathers", weather) -- секция погоды, соответствующая типу

local ini = ini_file("game.ltx")
local weather = utils.cfg_get_string(ini, level.name(), "weathers", db.actor, false, "", "[default]")
local weather_sect = ini:r_string("weathers", weather) -- секция погоды, соответствующая типу

Тоже будет вылет(через раз), иногда загружается игра.

Вот лог вылета:

  Лог (Показать)

Клиент: Синхронизация...

* phase time: 9 ms

* phase cmem: 221717 K

* [win32]: free[3093848 K], reserved[108356 K], committed[992036 K]

* [ D3D ]: textures[364135 K]

* [x-ray]: crt heap[221717 K], process heap[8541 K], game lua[92729 K], render[185 K]

* [x-ray]: economy: strings[15913 K], smem[1050 K]

! Cannot find saved game ~:ogsm_cleaner_release_wpn_mp51258

* Log file has been saved successfully!

! Can't find texture 'tree\tree_fuflo'

* MEMORY USAGE: 271197 K

* End of synchronization A[1] R[1]

 

FATAL ERROR

 

[error]Expression : fatal error

[error]Function : CInifile::r_section

[error]File : E:\priquel\sources\engine\xrCore\Xr_ini.cpp

[error]Line : 443

[error]Description :

[error]Arguments : Can't open section 'weathers'

 

 

stack trace:

 

 

Так вот вопрос, как заставить его работать в чн?

[Artos 99]

Старлей,

1. В ТЧ нет упомянутых тобою строк, по крайней мере в level_weathers.script, на котором и построен погодный менеджер. Очевидно у тебя некий "погодный" мод под ТЧ и, ты просто напросто пытаешься "сшить" абсолютно несовместимые строки.

2. Строка: local weather = utils.cfg_get_string(ini, level.name(), "weathers", db.actor, false, "", "[default]")

вычитывает из погодных конфигов погодную секцию типа: sect_default_weather (ТЧ) иль sect_marsh (ЧН), т.е. возвращает именно из секции [weathers] запрошенную секцию для конкретного уровня.

Исходя из логики, можно предположить, что эта секция и будет запрашиваемой в 3-ей строке weather_sect.

Твоя же строка: local weather_sect = ini:r_string("weathers", weather). по сути пытается запросить повторно из той же самой секции (weathers) нечто, но уже не по имени уровня, а по ... некоей полученной из игры погоде - результат очевиден.

 

Не буду далее гадать, т.к. нет информации.

Даже если в 3-ей строке простое присвоение: local weather_sect = weather , позволит тебе избавиться от текущего вылета этого куска кода - скорее всего ты далее опять получишь ошибку, но по другой причине/строке.

Тебе требуется разбираться с твоим "погодным" модом и адаптировать его под ЧН, т.к. погодные конфиги ТЧ и ЧН (да и сами менеджеры) все же различны.

Изменено 25 Ноября 2012 пользователем Artos

[SkyLoader 53]

malandrinus, к сожалению, твой способ для сталкеров и мутантов не подойдет, чтобы скрывать кости. При скрытии кости, матрицы полигонов кости будут scale в 0, т.е. все координаты полигонов кости будут иметь нулевое значение, поэтому кажется, что кость пропала, а на самом деле она просто смялась в ничего. Для оружия это срабатывает потому что кости глушителей, прицелов и гранатометов являются отдельными мешами и не соединены с другими мешами. В случае с моделью сталкера кости имеют общий меш, и при скрытии кости, между двумя костями (фэйсы) будут тянуться в нулевые координаты, т.е. между ног будет тянуться вниз такая полоска от парента скрываемой кости. Для реализации этого я могу посоветовать создать новую функцию (вместо set_bone_visible) и после того, как полигоны окажутся нулевых координатах, взять позицию из матрицы парента этой кости и назначить позиции матрицы самой кости. Тогда все выглядит нормально, и дырок никаких не будет.

---

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

Изменено 29 Ноября 2012 пользователем SkyLoader

[Malandrinus 615]

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

 

Мне что-то казалось, что бокс от кости тоже скрывается. Впрочем, я не проверял.

[SkyLoader 53]

malandrinus, я уже пробовал так делать. Если будет мягкая привязка у модели, то все равно будет стяжка фейсов к нулевым координатам. Если же грубая привязка, то будет видна щель между костями. Я много как пробовал, но выход нашел только этот. Хотя он и не до конца хорош, скорее как прототип.

 

LL_SetBoneVisible, к сожалению, действует только на визуальную составляющую, на коллизийный бокс никакого влияния не оказывает.

[Artos 99]

SkyLoader,

  Показать

учитывая, что обсуждение "костей" уже давно оторвалось от сути и цели заданного вопроса (#4809), и никоим образом уже не относится к теме топика, предлагаю дальнейшее вести в более подходящих топиках, например, "Редактирование движка X-Ray" или "X-Ray extensions".

[Старлей 88]

За'use'в поиск в данной теме нашел, что данный вылет:

  Вылет (Показать)

FATAL ERROR

 

[error]Expression : motion_ID.valid()

[error]Function : CKinematicsAnimated::ID_Cycle

[error]File : E:\priquel\sources\engine\Layers\xrRender\SkeletonAnimated.cpp

[error]Line : 208

[error]Description : ! MODEL: can't find cycle:

[error]Arguments : $editor

 

 

stack trace:

 

 

при спавне вертолета, происходит, т.к. " При спавне вертолёта через скрипт, обязательно требуется перепаковка net_packet, с переназначением параметров:"

skeleton_name = idle startup_animation = idle

skeleton_name = idle
startup_animation = idle

 

Для спавна вертолета я использую такую функцию:

  Код (Показать)

function heli(section,posx,posy,posz,lvid,gvid,logic)

local obj = alife():create(section,vector():set(posx,posy,posz),lvid,gvid)

local packet = net_packet()

obj:STATE_Write(packet)

 

-- свойства cse_alife_object

local game_vertex_id = packet:r_u16()

local cse_alife_object__unk1_f32 = packet:r_float()

local cse_alife_object__unk2_s32 = packet:r_s32()

local level_vertex_id = packet:r_s32()

local object_flags = packet:r_s32()

local custom_data = packet:r_stringZ()

local story_id = packet:r_s32()

local cse_alife_object__unk3_s32 = packet:r_s32()

 

-- свойства cse_visual

local visual = packet:r_stringZ()

local cse_visual__unk1_u8 = packet:r_u8()

-- свойства cse_motion

local motion_name = packet:r_stringZ()

 

-- свойства cse_ph_skeleton

local skeleton_name = packet:r_stringZ()

local cse_ph_skeleton__unk1_u8 = packet:r_u8()

local cse_ph_skeleton__unk2_u16 = packet:r_u16()

 

-- свойства cse_alife_helicopter

local cse_alife_helicopter__unk1_sz = packet:r_stringZ()

local engine_sound = packet:r_stringZ()

 

--устанавливаем логику

custom_data = "[logic]\ncfg = scripts\\heli\\"..logic..".ltx"

 

-- теперь заполняем нужные параметры

-- свойства cse_alife_object

packet:w_begin(game_vertex_id)

packet:w_float(cse_alife_object__unk1_f32)

packet:w_s32(cse_alife_object__unk2_s32)

packet:w_s32(level_vertex_id)

object_flags = bit_not(5) -- ~5 = 0xfffffffa

packet:w_s32(object_flags)

packet:w_stringZ(custom_data)

packet:w_s32(-1)

packet:w_s32(cse_alife_object__unk3_s32)

 

-- свойства cse_visual

packet:w_stringZ(visual)

packet:w_u8(cse_visual__unk1_u8)

 

-- свойства cse_motion

packet:w_stringZ(motion_name)

 

-- свойства cse_ph_skeleton

skeleton_name = "idle"

packet:w_stringZ(skeleton_name)

packet:w_u8(cse_ph_skeleton__unk1_u8)

packet:w_u16(cse_ph_skeleton__unk2_u16)

 

-- свойства cse_alife_helicopter

cse_alife_helicopter__unk1_sz = "idle"

engine_sound = "vehicles\\helicopter\\helicopter"

packet:w_stringZ(cse_alife_helicopter__unk1_sz)

packet:w_stringZ(engine_sound)

 

-- считываем скорректированные параметры

packet:r_seek(0)

obj:STATE_Read(packet, packet:w_tell())

 

 

return obj

end

 

 

Так вот подскажите, что сюда добавить, чтобы устанавливолось startup_animation = idle?

[Artos 99]

Старлей, в приведенной тобою функции спавна вертушки function heli(...) уже все есть, т.е. строка

cse_alife_helicopter__unk1_sz = "idle"

cse_alife_helicopter__unk1_sz = "idle"

как раз и задает(изменяет) в нет-пакете значение параметра startup_animation = idle, просто для переменной использовано иное имя, которое ты можешь заменить своим более понятным.

Примечание: При спавне вертолетов желательно объекту задавать и параметр engine_sound (он у тебя также задается), в котором прописан звук двигателей (или '$no_sound'). Путь к звуковому файлу зависит от версии игры (ТЧ или ЧН) или от мода. У тебя прописан "для ЧН".

Изменено 30 Ноября 2012 пользователем Artos

[Полтергейст 38]

  Цитата

и все же твой "баг" скорее всего искусственного происхождения, т.е. именно из-за сторонних вмешательств

Не совсем. С одной стороны, причина была в изменениях, внесенных в скрипт респавнеров. Баг "вылечил" тем, что сделал наличие db.actor обязательным условием, что исключило слишком ранний скриптовый спавн, а именно - ДО той стадии, на которой метод on_register будет вызван для всех обЪектов, загруженных из all.spawn.

С другой стороны, любой скрипт, в котором до этой стадии будет вызван скриптовый спавн какого-либо обЪекта, вернёт проявление бага.

Изменено 7 Декабря 2012 пользователем Полтергейст

[Dennis_Chikin 3 662]

Когда-то давно в НС появился "ПДА" для хранения переменных, не лезущих в pstor актору (netpacket_pda_binder.script)

в числе прочего там есть такое:

  Показать

function init(obj) local new_binder = my_binder(obj) obj:bind_object(new_binder) end class "my_binder" (object_binder) function my_binder:__init(obj) super(obj) end

function init(obj)
   local new_binder = my_binder(obj)
   obj:bind_object(new_binder)
end

class "my_binder" (object_binder)
function my_binder:__init(obj) super(obj)
end

 

При переходе в онлайн этого самого netpacket_pda дергаются последовательно *:__init(), init(), *:reload, ну и далее по тексту.

Но КАК ? В смысле, netpacket_pda_binder.init() кем вызывается вот в таком-то вот порядке ?

[ColR_iT 171]

Dennis_Chikin, объектом к которому "прикручен" биндер. Нет, вызываются методы конечно движком, но, так сказать, виновник этого - объект. В общем вот здесь всё весьма подробно расписано: >>ClicK Me<<.

[Artos 99]

Dennis_Chikin, функция netpacket_pda_binder.init() вызывается в том случае, если в конфиге секции объекта (например для device_pda) будет прописан параметр:

script_binding = netpacket_pda_binder.init

script_binding = netpacket_pda_binder.init

- именно эта строка в конфиге объекта заставляет движок вызывать соотв.функцию при выходе объекта в онлайн, которая и запускает биндер объекта.

Ну а далее, последовательность вызова движком методов самого биндера можно подсмотреть в xr_motivator.script, где сами разрабы оставили нам комменты:

  Цитата

порядок вызова методов биндера:

reload

reinit

load

net_spawn

Примечание: Метод 'load' будет вызываться только для объекта(ов) уже сохранявшегося в игре (если был save), т.е. при первом спавне объекта в игру этот метод не вызывается.

 

Примечание 2: ИМХО, метод с хранением "излишних" данных в КПК или "флешке" устарел и имеет больше недостатков, чем преимуществ по сравнению с уже известным методом хранения в специальном технологическом серверном объекте (se_custom_storage). Подробности такого метода (by malandrinus) и наработки по скриптам были рассмотрены около года назад в теме "Язык Lua. Общие вопросы программирования".

Изменено 13 Декабря 2012 пользователем Artos