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

[Labus 0]

Здравствуйте. Простите, если помешал. Кто-нибудь может рассказать, как заставить неписей игнорировать очевидный для них денжер?
 
PS: ТЧ 1.0004

Поправить ошибку со storage в xr_danger.script, и прописать соответствующий игнор в логике ? dc

Изменено 17 Октября 2014 пользователем Dennis_Chikin

[Zander_driver 10 331]

local vacant_pos = {1,2,... короче куча цифр}
local ind = math.random(#vacant_pos)
table.remove(vacant_pos,ind)

 

 

Вот такая катавасия творится у меня в цикле, из таблицы удаляются рандомно взятые элементы, до некоторого предела. Все бы хорошо, но исходная таблица vacant_pos бывает разной. И периодически это приводит к вылетам bad argument #1 to 'random' (interval is empty)
При том что заведомо неизвестно какие там вообще элементы в таблице еще остались, как мне проверить что рандом для нее вызывать еще можно, и "интервал" пустым не будет?

[Desertir 202]

@Zander_driver, это прикол?) Проверяй #vacant_pos на 0, если равно, брекай свой цикл - таблица пуста. Смысл в том, что в рандом нельзя передать 0.

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

Изменено 20 Октября 2014 пользователем Desertir

[Карлан 1 049]

while #tbl > 0 do

table.remove(tbl, math.random(#tbl))

end

[Zander_driver 10 331]

@nego, Ну для этого требуется сделать две относительно несложные вещи.

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

2. На апдейте скриптом выяснять, какие артефакты находятся на поясе ГГ, читать их конфиги, и если в них найдется строчка отвечающая за переносимый вес, читать ее значение и с этим значением запускать механизм из пункта 1.

 

Это все как вариант. Безусловно могут быть и другие пути реализации. Задачей "для начинающего" я бы это не назвал.

 

Вопрос к знатокам - что происходит с юзердатой клиентского объекта, при ее длительном хранении в переменной в скрипте? Судя по моим данным, неизменной она не остается, хотя и нельзя однозначно сказать, что с ней происходит. История:

Получаем юзердату методом level.object_by_id(number)

Проверяем что она не равна nil, сохраняем в переменную. Там она лежит энное время, в моем случае - несколько секунд
Затем некий другой скрипт берет эту юзердату, применяет на ней метод obj:section() и пытается читать из полученной секции конфига. пока я не сообразил проверять, чему равна эта секция и существует ли она вообще, в качестве результатов был целый букет явлений. Иногда все работало исправно - читались данные оттуда откуда надо, все норм. Иногда были безфатальные вылеты - как я теперь понимаю, из-за того что секция оказывалась nil. и иногда, происходили вылеты с забавным логом вроде такого

Expression    : fatal error
Function      : CInifile::r_section
File          : E:\stalker\patch_1_0004\xrCore\Xr_ini.cpp
Line          : 342
Description   : <no expression>
Arguments     : Can't open section 'ю«в`яя'

 

 

Изменено 25 Октября 2014 пользователем Zander_driver

[Dennis_Chikin 3 658]

По п1 - не надо ни какого апдейта. Кстати, кто там просил примеров с info и окном диалога - тоже см. сюда.

 

local t_info, t_info_any, t_info_n = {}, {}, 0

function add_on_info( f, nfo )	-- ( функция, инфо ), либо f для любых инфо
	if nfo then
		local t = t_info[nfo]
		if t then table_insert( t, f )
		else t_info[nfo] = { f }
		end
	else t_info_n = t_info_n + 1; t_info_any[t_info_n] = f
	end
end


function actor_binder:info_callback( npc, nfo )
	for i = 1, t_info_n do t_info_any[i]( nfo, npc ) end
	local t = t_info[nfo]
	if t then
		for i = 1, #t do t[i]( nfo, npc ) end
	end

	ltasks_proceed()		-- Сюжет
	ltasks_process_info( nfo )	-- Отметки на карте
end

function init()...
	local add_on_info = bind_stalker.add_on_info
	add_on_info( inv_open, "ui_inventory" )
	add_on_info( inv_open, "ui_trade" )
	add_on_info( inv_open, "ui_car_body" )
	add_on_info( inv_closed, "ui_inventory_hide" )
	add_on_info( inv_closed, "ui_trade_hide" )
	add_on_info( inv_closed, "ui_car_body_hide" )
...
	return true
end


function inv_open()
	actor_data.inv_open = true
end

local on_closed_t = {}
local on_closed_n = #on_closed_t

function add_inv_closed( f )
	on_closed_n = on_closed_n + 1
	on_closed_t[on_closed_n] = f
end


function inv_closed()
	actor_data.inv_open = false
	chk_belt_add()
	for i = 1, on_closed_n do	-- коллбэки всех, кому интересны изменения
		if on_closed_t[i] then on_closed_t[i]() end
	end
end

-- actor_data и chk_belt_add - ваши данные и проверки.

 

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

 

2. пока объект, полученный через level.object_by_id() существует - он существует. А вот если ушел в оффлайн или уничтожен (что, в принципе, одно и тоже), результаты будут забавные, да.

Изменено 25 Октября 2014 пользователем Dennis_Chikin

[Zander_driver 10 331]

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

[Dennis_Chikin 3 658]

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

 

Есть, кстати, замечательный глюк в xr_conditions, где происходит обращение к сохраненной неизвестно когда, кем, и зачем юзердате.

Изменено 25 Октября 2014 пользователем Dennis_Chikin

[Struck 61]

1. Реализовать механизм, позволяющий скриптом влиять на переносимый вес. Напрямую это делать нельзя. Один из обходных вариантов - На каждый комбез сделать серию подвидов, внешне неотличимых, но с разным переносимым весом. И скриптом менять в зависимости от желаемого результата, не забывая озаботиться сохранением состояния комбеза при его замене. 2. На апдейте скриптом выяснять, какие артефакты находятся на поясе ГГ, читать их конфиги, и если в них найдется строчка отвечающая за переносимый вес, читать ее значение и с этим значением запускать механизм из пункта 1.

 

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

 

гораздо удобнее сохранять айди

Самое верное решение.

 

@Dennis_Chikin, а я вообще назначения некоторых функций в xr_conditions не понимаю. Особенно непонятны конструкции:

function rad_pass_time(actor, npc)
    return true
end

Да и в остальном видно что не особо парились при создании логики в игре.

[Zander_driver 10 331]

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

[Dennis_Chikin 3 658]

Ну а что вы хотите от студенческих курсовых ?

 

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

 

Начинать в очередной раз все с нуля - не хочу.

 

Да, модули Артоса на мой взгляд чрезмерно академичны. Этим и не нравятся.

 

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

А если кто хочет помочь - то, кстати, посмотрите смысл job.fill_idle на предмет смысла значений, отличных от -1 и -2 в xr_gulag - где, зачем и для чего в принципе это может использоваться.

 

function rad_pass_time(actor, npc) return true end

Это запчасть от убиения актора, если он сунулся на радар без записки или в неподходящее время.

Изменено 26 Октября 2014 пользователем Dennis_Chikin

[Struck 61]

Начинать в очередной раз все с нуля - не хочу.

И не нужно. Я считаю, что рефакторинг скриптов (тем более полный), будет для всех, и ни для кого. Многие его требуют, но дай его им, они не поймут как им пользоваться, посмотрят, поохают, и положат на полку. Сколько сейчас модов на 4 патче базируются на баг-фиксе, а?

[RayTwitty 492]

сделать серию подвидов, внешне неотличимых, но с разным переносимым весом

какие артефакты находятся на поясе ГГ, читать их конфиги, и если в них найдется строчка отвечающая за переносимый вес

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

На дворе 2014 год, а люди до сих пор подобные вещи делают через "переспавн костюмов" и невидимый "баласт"  

 

X-Ray extensions и методы get_actor_max_weight/set_actor_max_weight, get_actor_max_walk_weight/set_actor_max_walk_weight и get_inventory_weight в помощь.

 

З.Ы. а еще лучше скачать исходники и сделать сразу как надо.

Изменено 26 Октября 2014 пользователем Shadows

[Dennis_Chikin 3 658]

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

[Struck 61]

В любом случае, если по уму делать, то надо брать последнюю ревизию 7 патча (сейчас это 174), и на ее основе уже переписывать коды. Кто тут сильно жаждет, можете начать, сделать обвязку новых методов и свойств с описанием, это, я думаю, будет востребовано. Может кто и подхватит это дело.

 

Лично мое мнение, храй экстеншн морально устарел.

[antihumanist 0]

Всем доброго времени ссуток.

После прохождения SoC(1.0006) мне захотелось сделать некоторые не архисложные модификации игры :

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

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

Теперь внимание вопрос:

Как игра подключает скрипты ? т.е. как заинклюдить свой пользовательский файл со скриптом чтобы он был виден из других скриптов ?

Чтобы вызвать его к примеру из  S.T.A.L.K.E.R - Shadow of Chernobyl\gamedata\scripts\ui_main_menu.script

 

--        if dik == DIK_keys.DIK_S then
--            self:OnButton_load_spawn()
            
--        else
        if dik == DIK_keys.DIK_Q then
            self:OnMessageQuitWin()--после этого
            
        elseif db.actor~=nil and dik==DIK_keys.DIK_F4 then
            add_all_Wpn()--Моя функция которую я хочу иметь в своем скрипте а не дописывать их в конец уже имеющегося игрового скрипта, так как такой способ я считаю неправильным или просто нехорошим

P.S.Я тут новенький так что если что не так то прошу тапками не кидать.Туторы читал и там не нашел такой инфы.

[Dennis_Chikin 3 658]

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

 

Скрипты подключаются "на лету".

Вот есть, допустим, my_kew1.script, а в нем функция my_kew1_function(), то если где-то написать my_kew1.my_kew1_function() - как до нее дойдет, так сразу и подключится.

[stalk9r 135]

Всем Привет!

Задача: спавнить различные наборы предметов

-- спавн каждого набора отделной функцией

function pokup:pokup51()
local object_names = {"bread","vodka","kolbasa"}
local a = vector()
local vid, gvid, i, aid, se_name
a = db.actor:position()
vid = db.actor:level_vertex_id()
gvid = db.actor:game_vertex_id()
aid = db.actor:id()
for i, se_name in ipairs(object_names) do
alife():create(se_name, a, vid, gvid, aid)
end
aem_manager.manage_money(1, "out")
end

 

Требуется: только определять в каждой функции набор, а спавнить отдельной функцией

-- вызов дополнительной функции для спавна
function pokup:pokup51()
self.pokupka({"bread","vodka","kolbasa"})
end

function pokup:pokupka(objects)
local object_names = objects
local a = vector()
local vid, gvid, i, aid, se_name
a = db.actor:position()
vid = db.actor:level_vertex_id()
gvid = db.actor:game_vertex_id()
aid = db.actor:id()
for i, se_name in ipairs(object_names) do
alife():create(se_name, a, vid, gvid, aid)
end
aem_manager.manage_money(1, "out")
end

 

вылет с ошибкой bad argument #1 to 'ipairs' (table expected, got nil)

Подскажите, как правильно передать аргументы?

Изменено 4 Ноября 2014 пользователем stalk9r

[Dennis_Chikin 3 658]

self.pokupka({"bread","vodka","kolbasa"})

 

- а это вообще как ? И зачем ?

 

function pokupka( t )

for i, v in ipairs ( t ) do alife():create( v, vector(), 0, 0, 0 ) end

end

 

Вызывать: pokupka( {"bread","vodka","kolbasa"} )

 

Причем я не понял: зачем вообще делать отдельной функцией ? Дабы сильнее тормозило ?

[Barmolini 1]

@Dennis_Chikin, это как бы класс. В котором есть метод спавна набора объектов. И есть методы в которых задаются разные наборы.

Зачем - это другой вопрос.

Да и работать должно же по идее.

Изменено 4 Ноября 2014 пользователем Barmolini