[CoP] Ковыряемся в файлах

[Kirgudu 1 336]

@Grif_on, не исключено, что ты используешь не то свойство. Попробуй назначить не строковый story_id в кастомдате, а числовой story_id, прописанный в свойствах объекта.
Примерно так:

[10997]
; cse_abstract properties
section_name = level_changer
name = val_to_desc_1
position = -44.5999984741211,1.79999995231628,-547.499877929688
direction = 0,0,0

; cse_alife_object properties
game_vertex_id = 1823
distance = 4.90000009536743
level_vertex_id = 119640
object_flags = 0xffffff3e

story_id = 11111 ;<--/ тут указать нужный уникальный номер

; cse_shape properties
shapes = shape0
shape0:type = box
shape0:axis_x = 12.9620018005371,0,0
shape0:axis_y = 0,5.50719976425171,0
shape0:axis_z = 0,0,4.48839998245239
shape0:offset = 0,0,0

; cse_alife_space_restrictor properties
restrictor_type = 3

; cse_alife_level_changer properties
dest_game_vertex_id = 3763
dest_level_vertex_id = 47755
dest_position = -404.020355224609,1.17996001243591,624.253295898438
dest_direction = 0.00435000006109476,-2.5,0.00658199982717633
dest_level_name = darkscape
dest_graph_point = desc_graph_point_actor_spawn_3
silent_mode = 1

; se_level_changer properties

 

[10998]
; cse_abstract properties
section_name = space_restrictor
name = close_level_changer
position = 140.048614501953,-1.00104403495789,48.9994010925293
direction = 0,0,0
; cse_alife_object properties
game_vertex_id = 1677
distance = 0
level_vertex_id = 309793
object_flags = 0xffffff3e
custom_data = <<END
 
[logic]
active = sr_idle@start
[sr_idle@start]
on_info = sr_idle@close1 %=disable_level_changer(11111)% ;<--/ числовой story_id объекта

[sr_idle@close1]
on_info = {+svoboda_leader_task_complete} sr_idle@end %=enable_level_changer(11111)% ;<--/ аналогично

[sr_idle@end]
END

; cse_shape properties
shapes = shape0
shape0:type = sphere
shape0:offset = 0,0,0
shape0:radius = 2.5191171169281

; cse_alife_space_restrictor properties
restrictor_type = 3

 

 

Изменено 1 Сентября 2014 пользователем Kirgudu

[Kirgudu 1 336]

Думаю это как подобие оператора 'или'

Это именно «или». Каждый следующий блок условий, отделённый запятой, проверяется тогда, когда предыдущий блок вернул результат «false».

Понятно, что такая цепочка может быть сколь угодно длинной.

[Kirgudu 1 336]

@Капитан Кузьмичёв, изучил-то, может, и полностью, однако сделал в корне неверное предположение, которое в дальнейшем может только тебя запутать.

 

 

on_info = {-jup_b204_actor_observed =see_actor =dist_to_actor_le(50)} %+jup_b204_actor_observed =make_actor_visible_to_squad(jup_b204_squad)%

...

Знак "равно" в скобках {} - похоже, союз И.

Союз "И" в твоей расшифровке - это каждый пробел, разделяющий разные условия внутри одной пары скобок. А вот знак "=" перед условием означает, что это условие должно вернуть "true" ("истина") в качестве результата (в противоположность знаку "!" - "ложь").

[Kirgudu 1 336]

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

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

Если считаешь это неправильным и хочешь сделать по-другому - на то тебе и руки даны, никто не мешает убрать лишнее, по твоему мнению, условие.

[Kirgudu 1 336]

@Serge!, http://www.amk-team.ru/forum/index.php?showtopic=13216

[Kirgudu 1 336]

@Romz, боюсь, это движковое. В скриптах расчёта времени, проведённого в Зоне, нет.

[Kirgudu 1 336]

@Romz, в ЗП есть метод level.change_game_time(d,h,m) - используется для перевода часов во время сна. Не исключено, что он может принимать и правильно обрабатывать отрицательные аргументы (знатокам движка тут виднее).

Если так уж смущает ушедшая вперёд во время экспериментов дата, можешь попробовать отмотать её обратно на нужную величину путём однократного применения этого метода.

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

[Kirgudu 1 336]

@Forestskif, в качестве наводки для самостоятельного изменения (если никто не поможет конкретным скриптом).

Спавн в инвентарь и спавн по координатам отличаются всего одним аргументом - наличием или отсутствием id контейнера.

Спавн по координатам актора:

alife():create(section, db.actor:position(), db.actor:level_vertex_id(), db.actor:game_vertex_id())

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

alife():create(section, db.actor:position(), db.actor:level_vertex_id(), db.actor:game_vertex_id(), db.actor:id())
-- или даже
alife():create(section, vector(), 0, 0, db.actor:id())
-- так как при спавне в инвентарь координаты игнорируются, их можно не вычислять.

Вот и вся разница. Изменено 13 Мая 2017 пользователем Kirgudu

[Kirgudu 1 336]

@WinCap, судя по скриптам, так оно и в оригинале.
Смотрим xr_walker.script:
action_walker_activity:activate_scheme(loading, npc) --> action_walker_activity:reset_scheme(loading, npc) --> self.move_mgr:reset(...)
Далее в move_mgr.script:

move_mgr:reset(...) --> сброс self.current_point_index = nil (плюс self.can_use_get_current_point_index = false до окончания экстраполяции в extrapolate_callback) --> move_mgr:setup_movement_by_patrol_path()

где видим такую развилочку:

if self.current_point_index then
	self.object:set_start_point(self.current_point_index)
	self.object:set_patrol_path(self.path_walk, patrol.next,    patrol.continue, true)
else -- наш случай
	self.object:set_patrol_path(self.path_walk, patrol.nearest, patrol.continue, true)
end

 

[Kirgudu 1 336]

26 минут назад, WinCap сказал:

находясь в середине пути NPC, после save/load’а, продолжил путь с ближайшей точки

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

[Kirgudu 1 336]

@SWEAW просто мало активных специалистов по ЗП осталось, вот сюда никто и не заглядывает, а кто заглядывает - мало пишет.

Попробую сузить тебе задачу вдвое. trade_manager вообще не обновляет список продаваемых товаров. Всё, что он делает - это раз в какое-то время вычитывает из конфигурации текущий тип списка товаров, примерно такого вида: current_buy_supplies = supplies_generic, а потом методом npc:buy_supplies() передаёт его движку. Внутри движка и происходит взвешивание вероятностей появления того или иного объекта в продаже и составление конечного списка.

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

Что же касается вывода в лог, добавь себе в _g.script в самом его конце что-то такое:

local console
to_log = function(fmt,...)
	if not console then console = get_console() end
	console:execute("load ~:"..string.format(fmt,...))
end

-- пример записи (в любом скрипте)
local st = "test"
to_log("Message: %s", st) -- где %s - место подстановки значения твоей строковой (числовой, булевой) переменной

Пример использования также приведён.

После чего смотри, чему у тебя при торговле становятся равны всякие tt.update_time, tt.resuply_time и иже с ними и думай, почему не срабатывает то, что ты делаешь.

Да, и соглашусь с @abramcumner, без логов сразу понять, что происходит, можно только в редких случаях. Поэтому прежде чем что-то под себя править, научись логировать.

[Kirgudu 1 336]

@SWEAW, пример приведён верно, но это, конечно, только один из возможных вариантов. Обычно, если хотят посмотреть, что происходит с переменной, то смотрят её значение (читай логируют) непосредственно до изменения и сразу после, перед сравнением (if) с другой переменной и перед любым использованием. Это если брать по максимуму. Естественно, если такое логирование будет в update функции, файл лога забьётся однотипными строками, но это не страшно.

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

[Kirgudu 1 336]

2 часа назад, WinCap сказал:

И, может быть, его активация вызовет ещё какие-нибудь ошибки.

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

--'	if trade_manager[npc:id()] == nil then
		-- trade_manager[npc:id()] = {} -- вместо этой строки пишем нижеследующую
		trade_manager[npc:id()] = trade_manager[npc:id()] and { update_time = trade_manager[npc:id()].update_time, resuply_time = trade_manager[npc:id()].resuply_time } or {}
--'	end

 

[Kirgudu 1 336]

@Erty123 один из самых простых скриптовых способов - дописать нужную проверку и действия в функцию actor_binder:info_callback(npc, info_id) модуля bind_stalker.script, например:

function actor_binder:info_callback(npc, info_id)
	-- ...все предыдущие строки...
	if has_alife_info(info_id) then -- проверяем, что выдана нужная нам инфопорция
		alife():create("item_section", position, lvid, gvid)
	end
end

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

[Kirgudu 1 336]

43 минуты назад, Erty123 сказал:

что куда именно нужно вставлять

position - координаты в виде объекта с типом vector, можно подставить как vector():set(x, y, z), где x, y, я - соотв. координаты по каждой из осей

lvid - id level вертекса. Например, для текущего положения героя вычисляется функцией db.actor:level_vertex_id()

gvid - id game вертекса. Например, для текущего положения героя вычисляется функцией db.actor:game_vertex_id()

Конкретные значения? Откуда я знаю, это уже определять самостоятельно, смотря куда что должно заспавниться.

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