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

[dsh 3 820]

@Romann, что бы не городить таблицы и использовать конфиги, см. пост 7341.

[Sla-Sla 43]

Никто не знает как сделать физический объект юзабельным? Например, чтобы можно было использовать костёр на локации, и после использования открывалось GUI окно.

[vampirnik77 121]

@Sla-Sla, Могу предположить что через биндер.

[aromatizer 4 278]

Например, чтобы можно было использовать костёр на локации

Возможно, тебе пригодится вот это:https://yadi.sk/d/vut19xuZrgzNB

Чье, откуда и как- не помню. Случайно наткнулся у себя на винте и вспомнил твой пост. 

Изменено 13 Мая 2016 пользователем aromatizer

[Zander_driver 10 166]

P.S. А вот под сами таблицы отдельный файл выделить, чтобы перестать уже адову акробатику с script1.var1 = script2.var1 script2.var1 = script1.var1 и вариантами оной о 100500 перекрестных ссылок.

Между прочим отличная идея. Сам давно собирался вынести основные таблицы (не все) отдельно, лень мешала реализовать.

 

 

как использовать этот способ? Как я понял

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

 

 

см. пост 7341.

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

local R = {
    -- тут хранятся под-таблицы, а в них еще, и еще, и... вобщем структурированно как-то, все табличные данные со всех скриптов.
    -- чтоб акробатикой не заниматься.
}

local gr = {
    [1] = function(k1) return R[k1] end,
    [2] = function(k1,k2) return R[k1][k2] end,
   * * *
    [10] = function(k1,k2,k3,k4,k5,k6,k7,k8,k9,k10) return R[k1][k2][k3][k4][k5][k6][k7][k8][k9][k10] end
}

function get(...)
    local ks = {...}
    local kc = #ks
    return gr[kc](...)
end

И получение любых данных какого-угодно назначения из любого скрипта выглядит так:

rr.get(какоето, количество, какихто, ключей, определяющих, гдележит, точенамнадо)

или так

rr.get(какойто, ключик)[еще-какой-то-ключ][и-еще][и-еще-ключ]

причем последовательность ключей в любом случае одна и та же

в принципе это очень удобно должно быть.

 

 

Изменено 13 Мая 2016 пользователем Zander_driver

[Dennis_Chikin 3 658]

Много хорошо - тоже плохо.

 

Скорее стоит завести как таблицы, так и функции разной степени подробности.

Избыток - это все-таки замедление работы и возможность самому запутаться.

 

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

 

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

function get_c_all() return cls_ids end -- все cls_id

 

function get_clsid( cls_type ) return cls_types[cls_type] end -- получить cl_sid для типа

 

function get_c_xl() return cls_xl end -- cls_id, нужные для x-life

function get_cinv() return cls_inv end -- cls_id берущегося в инвентарь

function get_c_ai() return cls_ai end -- cls_id для монстров и неписей

function get_cw_a() return cls_w_all end -- cls_id для "вообще" оружия

 

function get_sect( stype ) return sect_by_type[stype] end -- секции для типа

function get_sect_by_num( stype ) return sect_by_num[stype] end -- секции по приоритету

 

function get_xltypes() return xl_types end -- типы, использующиеся в x-life

function get_i_types() return inv_types end -- типы, берущиеся в инвентарь

function get_xlsect() return sect_by_type end -- секции по типам (для разбора misc, если надо)

function get_s_types() return s_types end -- секции, берущиеся в инвентарь

В скриптике, где учитывается "кто есть кто",

 

и

function get_t_aprm() return t_aprm end

function get_t_mprm() return t_mprm end

function get_t_oprm() return t_oprm end

function get_t_wprm() return t_wprm end

function get_t_arts() return t_arts end

- в скриптике для чтения/хранения конфигов. ammo/misc/outfits/weapons/arts.

Изменено 13 Мая 2016 пользователем Dennis_Chikin

[Zander_driver 10 166]

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

На самом деле конечно, конечная реализация зависит еще от целей, для какого проекта это делается.

Я для своего скорее всего сделаю именно так, как показано под спойлером в моем посте выше, наиболее хорошо подходит под мои цели.

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

Изменено 14 Мая 2016 пользователем Zander_driver

[Dennis_Chikin 3 658]

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

 

Но даже там в разных кусках - разные таблицы. Путаться особо не в чем.

 

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

[Zander_driver 10 166]

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

обфускаторы тут не при чем.

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

 

Если говорить о таблицах которые востребованы в одном-единственном файле - то черт бы с ними, пусть лежат там где лежат.

Изменено 14 Мая 2016 пользователем Zander_driver

[CRAZY_STALKER666 36]

Можно ли получить список всех артефактов на уровне в данный момент времени, и удалить их?

[Wlad777 24]

Можно.

[CRAZY_STALKER666 36]

@Wlad777, каким образом?

[Zander_driver 10 166]

@CRAZY_STALKER666,

способ раз

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

 

способ два. если лень, и хочется тормозов и горбатых реализаций.

перебрать 65к объектов, проверяя что их клсид относится к классам артефактов (всего их в оригинальной игре два). Всех кто окажется артефактом, заносить в отдельную таблицу.

удалять в сталкере только серверный объект можно, так что тут без вариантов.

[UnLoaded 313]

список всех артефактов на уровне в данный момент времени, и удалить их?

 

способ раз...

А тут не будет нюансов с алайф-расстоянием ? Ведь на достаточно протяженной локации, может оказаться, что часть артов будет в он-лайне и соответственно в таблице, а часть в офф-лайне и уже не в таблице. А удалить надо все. Я с этим не разбирался, не знаю - арты переходят он\офф -лайн ?

Изменено 16 Мая 2016 пользователем UnLoaded

[Zander_driver 10 166]

Хм, вообще-то да, вы правы. артефакты в он/офф-лайн переходят.

Можно вспомнить про то что и серверный объект можно забиндить.

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

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

[CRAZY_STALKER666 36]

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

Значит придется ручками спавн чистить..

[Zander_driver 10 166]

Если надо не *на одной этой локации* а на всех сразу, то все просто. перебор - проверка на класс артефакта - удаление.

[Dennis_Chikin 3 658]

Только что выше обсуждали: se_item и иже с ними - при регистрации заносят в таблицу в соответствии с классом. Желательно - СРАЗУ раскладывать и по локациям.

[CRAZY_STALKER666 36]

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

 

Работает она в main_menu:InitControls().

Я задаю флаг

 

local flag = 0 -- оптимизация кода

 

Потом проверяю его равенство 0, выполняю свой код и выставляю его равным 1 для того, чтобы каждый раз при открытии меню не происходила проверка.

Но она происходит. Значит флаг не сохраняеться. Как его сохранить? Через нет-пакет?

 

P.S Изыскания про методы вызова прошу опустить... Потом всё будет переписываться, переноситься...

[Zander_driver 10 166]

В общем напоролся я на чудо-чудное, иначе не скажешь.

 

function start_game_callback()
    printf    ("start_game_callback called")
    * * *   
    if not smart_terrain.check_script() then abort("***") end
  
end

 

 

самая что ни на есть, первая строчка файла

printf("smart_terrain_compilation start")

в самом хвосте:

printf("smart_terrain_compilation end")

function check_script()
    return true
end

 

 

Как уже говорилось, printf и abort в моей сборке исправно работают.

плагин из подписи Charsi, проверив этот самый smart_terrain.script, уверенно заявляет - syntax OK!

* DBG: _g:(1453):start_game_callback called
 
FATAL ERROR
 
[error]Expression    : fatal error
[error]Function      : CScriptEngine::lua_error
[error]File          : E:\stalker\patch_1_0004\xr_3da\xrGame\script_engine.cpp
[error]Line          : 73
[error]Description   : <no expression>
[error]Arguments     : LUA error: ... publishing\s.t.a.l.k.e.r\gamedata\scripts\_g.script:1458: attempt to call field 'check_script' (a nil value)
 

stack trace:

 

 

т.е. колбек старта игры - отработал, и заодно подтвердил в логе работоспособность функции printf.

_g.smart_terrain - вроде бы тоже оказалось не nil.

Но printf из первой строчки скрипта не вызывался, компиляция не выполнялась, и даже не пыталась начаться. Движок просто утверждает что да, есть такой файл, но он абсолютно пуст, ничего в нем нету.

Не считая расширения RvP, движок стандартный ТЧ 4-й патч. Мне просто интересно, что вообще я мог такого сделать, чтобы это происходило. Какая может быть причина... есть у кого нибудь предположения?

Изменено 25 Мая 2016 пользователем Zander_driver