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

[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. И помните: «Правильно заданный вопрос – половина ответа».

 

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

 

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

 

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

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

---

[Zander_driver 10 343]

@vampirnik77, А что именно не провернуть?

Насколько я могу судить по справочнику, часть методов CUIWindow заменена на другие, часть методов класса CUIStatic вынесена в отдельный класс CUILines.
Методы имеют другие названия и расположены в других классах, но возможности вроде все на месте?
 

[Anonim 680]

Есть способ сделать опции зависимыми друг от друга, я давно интересовался данной информацией http://www.amk-team.ru/forum/topic/6185-skriptovanie/?p=921900

 

Но что если я хочу сделать один ComboBox зависимым от другого? Все попытки что-либо подглядеть в lua_help тщетны. Короче, помогите 

handler.m_preconditions[ctl]		= function()
	local opt1 = self:GetCheckButton("option1")
	ctrl:Enable( opt1:GetCheck() )
end

Как мне кажется весь прикол в этой функции, а именно GetCheckButton/GetCheck

Изменено 7 Апреля 2016 пользователем Anonim

[Zander_driver 10 343]

Здесь CheckButton а ты говоришь что тебе нужен ComboBox.

Чего же ты на самом деле хочешь?

[Romz 142]

Недавно я тут выкладывал адаптацию авторазряжалки для ТЧ. В общем и целом, всё работает. Но вылезает периодически баг.

Суть его вот в чём.

ТЧ при переходе на другую локу сперва делает автосохранение, а потом прибивает актора (пишу как сам понял на основе проведённых экспериментов).

Так вот, похоже, что уничтожение инвентаря воспринимается движком как выкидывание всего из него. Сделал такой вывод на основе того, что вызывается метод "actor_binder:on_item_drop". А увидел я это потому, что из этого метода происходит вызов скрипта авторазряжания. О чём он и сообщает в логе, и сообщениями на экране, т.к. пытается разряжать всё, что есть в инвентаре с патронами, кроме стволов в слотах. А на следующей локе, после спавна актора, его состояние, и, в частности, содержимое инвентаря, грузится из автосохранения, поэтому патроны не размножаются.

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

 

вылет с логом

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
E:\stalker\sources\trunk\xr_3da\xrGame\script_engine.cpp
CScriptEngine::lua_error
LUA error: %s
c:\gam\ogse20\gamedata\scripts\se_respawn.script:1059: attempt to index local 'sitem' (a nil value)
info-called from CPP

Хочу заметить, что se_respawn.create_ammo в ОГСЕ отличается от такового в чистой ТЧ 1.0006

Для сравнения: это из чистого ТЧ

function create_ammo(section, position, lvi, gvi, pid, num)
	local ini = system_ini()

	local num_in_box = ini:r_u32(section, "box_size")

	while num > num_in_box do
		alife():create_ammo(section, position, lvi,	gvi, pid, num_in_box)
		num = num - num_in_box
	end
	alife():create_ammo(section, position, lvi,	gvi, pid, num)
end

и из ОГСЕ 2.08

function create_ammo(section, position, lvi, gvi, pid, num)
	local ini = system_ini()

	local num_in_box = ini:r_u32(section, "box_size")

	while num > num_in_box do
		local sitem = alife():create_ammo(section, position, lvi, gvi, pid, num_in_box)
		local sammo = alife():object(sitem.id)
		sammo:use_ai_locations(false)
		num = num - num_in_box
	end
	local sitem = alife():create_ammo(section, position, lvi, gvi, pid, num)
	local sammo = alife():object(sitem.id)--   <---- СТРОКА 1059
	sammo:use_ai_locations(false)
end

Есть ли какой-то способ в ТЧ отследить начало перехода на другую локу? Желательно - до автосейва.

Я пробовал в скрипты подставлять конструкцию

if(device().precache_frame > 1) then return end

Не срабатывает. Проверка на существование актора, типа

if db.actor then чтото делаем end

тоже не прокатывает.

Бъюсь уже второй день...

Изменено 7 Апреля 2016 пользователем Romz

[Anonim 680]

@Zander_driver, Я и говорю что мне нужно

 

GetCheckButton/GetCheck

 

эти заменить на другие для ComboBox'а, но я немогу понять на какие.

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

[Romz 142]

К моему посту выше: http://www.amk-team.ru/forum/topic/6185-skriptovanie/?p=1005130

В качестве временной затычки добавил в se_respawn от ОГСЕ функцию se_respawn.create_ammo от оригинала, но под другим именем. И для работы скрипта авторазряжания вызываю её. В этом случае вылет не происходит, хотя actor_binder:on_item_drop продолжает вызываться при переходе. И, судя по логам, при завершении игры. Т.е. при любом развоплощении актора.

Добавление se_respawn.create_ammo от ТЧ в сам скрипт ts_mod_soc.script результата не принёс, игра начала просто валиться с FATAL ERROR, без указания на причину подобного.

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

Изменено 7 Апреля 2016 пользователем Romz

[naxac 2 477]

@Romz, при перезагрузке содержимое инвентаря актера уничтожается, как и сам актер. Поставь в начале скрипта проверку на наличие серверного объекта разряжаемой пушки:

if alife():object(item:id()) == nil then return end

[Romz 142]

 

 

при перезагрузке содержимое инвентаря актера уничтожается, как и сам актер

Это то понятно. Просто в ТЧ оно как-то очень медленно уничтожается. В ЗП с этим скриптом таких проблем не было. Он даже не пытался на переходе сработать.

 

if alife():object(item:id()) == nil then return end

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

Надо отследить событие перехода и при его начале обрубать on_item_drop и on_item_take заодно.

[=VENOM= 50]

Попробуй сделать так - в биндере актёра в колбэке on_item_drop огородить вызов "авторазряжалки":

if level.present() then
--ваша авторазряжалка
end

[Kirgudu 1 264]

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

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

[Zander_driver 10 343]

@Romz, Я в давние времена с подобной бякой сталкивался, при смене локации происходит куча срабатываний on_item_drop и on_item_take, на все имущество ГГ, и конечно если не принять меры то это кучу нежелательных последствий вызывает.

Как я это решил: в файле биндера объявил переменную, в которую записываю текущую локацию актора. Есть у меня апдейты работающие с пониженными частотами - раз в 100мс, раз в секунду, раз в 5 сек. Вот в пятисекундном апдейте вот эта переменная сравнивается с текущей, если не совпадает - в переменную записывается новое значение.

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

Ну и получается. Пошел у нас колбек итем_дроп - проверяем, совпадает ли текущая локация где себя позиционирует актор, с той что записана в переменной. Если нет - это переход. Точто так же и с item_take при входе на новую локу. в переменной-то все еще старое значение хранится.
Единственный возможный минус такой реализации - если в первые 5 секунд после нетспавна на новой локе актор кинется что-то подбирать или выбрасывать по-настоящему, эти колбеки будут восприняты как происходящие при переходе. Но на самом деле весь или почти весь этот отрезок времени происходит еще в то время когда у игрока написано "Клиент: синхронизация". так что такой вариант практически нереален.
Использую такой механизм уже много лет, сбоев при переходах не заметил.

[Kirgudu 1 264]

Имхо, поскольку смена локации происходит одновременно с сохранением/загрузкой, достаточно сохранить параметры текущей локации всего один раз, скажем в actor_binder:__init. Делать это пусть даже на медленном апдейте избыточно.

[Romz 142]

 

 

if level.present() then

Не проканало.

 

при переходе на другую локацию перед сохранением актору прописывается новая позиция

Возможно и так, но actor_binder:on_item_drop, похоже, срабатывает раньше.

Вот, для примера, две позиции актора: первая - это ГГ стоит возле перехода на Кордоне, а вторая - ГГ шагнул в переход, согласился, что он будет переходить, и игра вылетела

 

position [ x = 14.738349914551, y = 16.390243530273, z = 680.48516845703]
 level_vertex_id [290085]
 game_vertex_id [207]

position [ x = 15.06812286377, y = 16.482328414917, z = 684.87188720703]
 level_vertex_id [290880]
 game_vertex_id [207]

 

 

[Kirgudu 1 264]

@Romz, позицию берёшь, надеюсь, серверного объекта?

[Romz 142]

@Kirgudu, Вот в этом месте я не уверен. Позицию в лог выдаёт такая конструкция

npc=db.actor -- это так и у Tonny 
ts_log("spawn_ammo_in_inv","sect ["..tostring(section).."] npc ["..npc:name().."]" .."\n".."position [ x = "..tostring(npc:position().x)..", y = "..tostring(npc:position().y)..", z = "..tostring(npc:position().z).."]".."\n".." level_vertex_id ["..tostring(npc:level_vertex_id()).."]" .."\n".." game_vertex_id ["..tostring(npc:game_vertex_id()).."]" .."\n".." npc ID ["..tostring(npc:id()).."]" .."\n".." number ["..tostring(num_ammo).."]")

 

 

в файле биндера объявил переменную

Дык, при переходе же переменные обнуляются? Я с этим ещё в ЗП столкнулся. Из-за чего и пришлось городить весь огород с se_stor.

Хотя, она может и не успеть обнулиться к моменту начала переноса

@Zander_driver, У скрипта есть вызов в _g.start_game_callback. Можно внутри этого вызова сохранить текущую локу.

[Zander_driver 10 343]

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

 

 

достаточно сохранить параметры текущей локации всего один раз, скажем в actor_binder:__init

А вот это как раз слишком рано. Задумайтесь, как могут срабатывать колбеки до того, как инициализирован сам объект биндера? Это же его методы. Конечно они после __init будут срабатывать.

[Romz 142]

@Kirgudu, @Zander_driver, Засунул сохранение локи в actor_binder:__init. Лока успешно сохранилась

 

function ts_on_init()
	level_name = level.name()
	ts_log("ts_on_init\t\t","level_name = "..tostring(level_name))
end

 

Но при переходе в нужном месте лока не сменилась

 

function ts_on_item_drop(obj)
local lname = level.name()
ts_log("ts_on_item_drop\t\t","level_name = "..tostring(level_name))
ts_log("ts_on_item_drop\t\t","lname = "..tostring(lname))
if lname == level_name then

 

 

Лог происходящего при переходе

 

(908792.6875) = ts_on_init		 => level_name = l01_escape 
(908803.1875) = ts_on_item_drop		 => level_name = l01_escape 
(908803.1875) = ts_on_item_drop		 => lname = l01_escape 
...
овердофига строк
...
(908960.8125) = ts_on_item_drop		 => ... 
(908960.8125) = ts_on_item_drop		 => level_name = l01_escape 
(908960.8125) = ts_on_item_drop		 => lname = l01_escape 
(908960.8125) = ts_on_item_drop		 => ... 
(908960.8125) = ts_ammo_discharge		 => wpn_swd_svd20_grip_pso148402 ammo_count = 20 ammo_type = 1 
(908960.8125) = ts_ammo_discharge		 =>  Боеприпас 7,62х54 мм 7H14 (20 шт.) 
(908960.8125) = spawn_ammo_in_inv => sect [ammo_7.62x54_7h14] npc [single_player]
position [ x = 15.305265426636, y = 16.479644775391, z = 684.7421875]
 level_vertex_id [290880]
 game_vertex_id [207]
 npc ID [0]
 number [20] 
(908960.8125) = ts_on_item_drop		 => level_name = l01_escape 
(908960.8125) = ts_on_item_drop		 => lname = l01_escape 
(908960.8125) = ts_on_item_drop		 => ... 
...
ещёмногострок
...
(908960.8125) = ts_on_item_drop		 => level_name = l01_escape 
(908960.8125) = ts_on_item_drop		 => lname = l01_escape 
(908960.8125) = ts_on_item_drop		 => ... 
(908960.8125) = ts_on_init		 => level_name = l02_garbage 

 

Или я как-то не так это делаю?

Попробовал определить локу вот так

 

local sim = alife() -- получаем сам объект класса alife_simulator
local sactor = sim:actor() -- получаем серверный объект для актора
local lid = sim:level_id() -- если подставить sactor, то ругается, что у него нет level_id и вылетает
local lname = sim:level_name(lid)

 

Тоже с вышеприведённым результатом

[abramcumner 1 181]

@Romz, можно попробовать в on_item_drop добавлять предметы в таблицу. А разряжать в апдейте все, что в таблице накопилось.

[vampirnik77 121]

@abramcumner, Насколько я вник в проблему, это не поможет. Трабла в том что при переходе on_item_drop срабатывает, значит и разрядка срабатывает(что не нужно), а если собирать все в таблицу, то по сути ничего не измениться. Но конечно же я могу глубоко ошибаться.

[UnLoaded 313]

 

 

Трабла в том что при переходе on_item_drop срабатывает

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