Перейти к контенту

Прозекторская


Рекомендуемые сообщения

"История одной пессимизации", смею напомнить, да... Всего-то 2 минуты вместо 40 секунд оригинала и 5 секунд для сделанного по-человечески.

 

Это к тому, что не все ltxы надо пихать во все подряд, и не все, что можно запихнуть в ltxы - нужно запихивать в ltxы.

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

Поделиться этим сообщением


Ссылка на сообщение

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

Смысл же дублировать ? Сам же знаешь, что все равно ни кто читать не будет, зато будет очередная пачка Униженных и Оскорбленных.

Помнится, когда в тот раз выкладывалось, нашлось сразу с десяток этих самых униженных и оскорбленных тем, что я указал на БТР, у которого из двигателя звуки балалайки доносятся. Вот мне уже 4 года это напоминать не устают - как я Унизил И Оскорбил Очень Уважаемых Людей, а также грубо нарушил ихние аффтырьские права.

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

 

Суть кактуса описана здесь:

http://www.amk-team.ru/forum/topic/8830-narodnaia-2010-razrabotka/page-34#entry763618ну и далее, вот по сюда: http://www.amk-team.ru/forum/topic/8830-narodnaia-2010-razrabotka/page-39#entry794407

  • Нравится 1

Поделиться этим сообщением


Ссылка на сообщение

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

 

Именно так. По-этому, перекладываем одинаковые звуки по соответствующему пути, и прописываем им тип 2 или 3. В результате - одинаковые звуки читаются один раз.

 

(2 минуты и 40 секунд - это несколько про другое. Здесь - скорее про лаги уже по ходу игры. Впрочем, некоторая разница, в районе десятка секунд при загрузке, скажем, в "деревне новичков" и тем более, центре бара - будет.

 

 

Плюс к тому уникальные звуки надо вынести по уникальным путям, и грузить вообще не через themes. Ибо если включить лог, и посмотреть, кому что читается - это - страшно.

  • Согласен 1

Поделиться этим сообщением


Ссылка на сообщение

Ну вот например звуки бормотания зомбей и раненых по psy_health.

Почему-то читаются очень долго. Дублированы для ВСЕХ профилей.

 

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

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

 

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

 

Что это даст: отсутствие лага при входе в онлайн непися с новым профилем. Сокращение времени загрузки в местах с толпами неписей.

 

А сахаров не нужен ни кому, кроме собственно сахарова. Это даст как сокращение лагов, так и собственно загрузки.

Поделиться этим сообщением


Ссылка на сообщение

"ты прости, работу этого файла проверял? игру с ним запускал?

Я между прочим знаю что нет. Не проверял, не тестировал, не запускал."

 

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

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

 

В чем проблема с обратиться к функции, описанной до обращения - ВАЩЕ ни панимаю.

Судя по тому, что ты используешь printf, который У ТЕБЯ работает - это какие-то проблемы с особенностями твоего компилятора.

 

P.S. И, да, опечатки в именах переменных - это вечная проблема языков без нормального декларирования оных переменных. Хорошо, когда переменная нигде больше не определена, и получаем вылет. Если, как у меня, определена в global_space - ну не выловить ни какими тестами. 8(

Хоть тресни, но работает, пока кто-нибудь не займется переносом.

Изменено пользователем Dennis_Chikin

Поделиться этим сообщением


Ссылка на сообщение

Если их выкладывать "в таком виде" - а это как ? Опять передавать в xr_logic непися с гулагом, чтобы он там благополучно повис, хотя достаточно простого разбора в таблицу простой строки ?

 

Угадать, какое оружие используется у этого "не-скриптера", и магическим образом сделать так, чтобы он скачивал файл с индивидуально заполненной под него табличкой ? Или опять откатиться до  if object_type(obj) == "item", и получить роскошный висяк, если item почему-то оказался ни разу не оружием ?

 

Опять везде вернуть чертово if db.actor then db.actor:чегототам(), которое ни от чего не спасает, но само по себе раздолье для вот таких вот опечаток с переставленными буквами ?

 

Я просто не понимаю: ну ВОТ КАК ??? Кроме того, что все описано в комментариях непосредственно в начале файла.

Опиши, если не сильно затрудняет.

 

P.S.

function test_jit() return true end

if test_jit() then log( "info", "test_jit ok" ) end
! Cannot find saved game ~info~ [cheat] test_jit ok

 

ЧТО Я ДЕЛАЮ НЕ ТАК ???

Изменено пользователем Dennis_Chikin

Поделиться этим сообщением


Ссылка на сообщение

Смысл этих шаманских плясок ? Я реально не понимаю, что у тебя за компилятор такой, который компилирует/запускает не построчно.

Поделиться этим сообщением


Ссылка на сообщение

Повторюсь:

 

function test_jit() return true end

if test_jit() then log( "info", "test_jit ok" ) end
! Cannot find saved game ~info~ [cheat] test_jit ok

 

ЧТО Я ДЕЛАЮ НЕ ТАК ???

Изменено пользователем Dennis_Chikin

Поделиться этим сообщением


Ссылка на сообщение

function test_jit() return true end

 

local var = test_jit()

if var then log( "info", "test_jit ok" ) end

 

Внезапно, опять таки все работает. ЧТО Я ДЕЛАЮ НЕ ТАК ?

Извините, но printf() в стандартном сталкере не работает. Так что именно printf()ом проверить не могу.

Поделиться этим сообщением


Ссылка на сообщение

Если "после - глухо" - это чего-то повисло.

 

Что здесь может быть - это обращение к несуществующей у тебя функции или переменной. То есть, я не все скопировал в скрипт. 8(

 

Тогда надо бы найти, чего там не хватает.

 

У меня контроль целостности и порядок инициализации осуществляется дерганием за init() - если вернулся true - скрипт благополучно откомпилился и все выполнил.

 

 

А, блин, еще одна опечатка: string_fing = string.fing

То же самое - не вылавливается, если объявлено раньше. Вылазит у тех, у кого нету в _g.script

 

Перезалил.

Изменено пользователем Dennis_Chikin

Поделиться этим сообщением


Ссылка на сообщение

Сдается мне, что в данном конкретном случае беда с самой идеей, а не с реализацией.

Оно делает вообще непонятно что, хотя в одном случае надо всего-лишь проверить живость снайпера (по sid), во втором - численность неписей в смарте.

А кто кого убил - вообще значения не имеет.

Поделиться этим сообщением


Ссылка на сообщение

К величайшему сожалению всей прогрессивной общественности "Я НИУМИРЛА" ©, и теперь хочу поговорить про sr_psy_antenna.script

 

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

 

Итак, что такое эта самая "антенна", и как оно работает ? ("- Как работает трансформатор ? - Ж-жжжжжж !")

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

 

А что же у нее внутри ? Внутри у ей неонка. А если точнее, то так называемая "схема", во-первых, а во-вторых - всем нам знакомый "псевдообект", для которого до настоящего времени других, более адекватных, слов не найдено, не считая матерных.

Кто и зачем так сделал - науке неизвестно, но скорее всего это был очередной курсовик по ООП очередного скубента.

 

Сначала разберемся со "схемой". Чем она отличается от привычного нам сталкеровского объекта, game* или там какого-то из серверных, их "биндеров", или еще какой нечисти ? Тем, что конструкция создается на пустом месте, и может быть прицеплена к чему попало, а также управляться посредством всеми нами любимой "логики" - то есть тех самых странных буковок и черточек, которые так замечательно набивать в надцати мегабайтах олспавна. То есть, в соответствии с модным лозунгом про "атомизацию, инкапсуляцию, и прочий код-реюзинг", а также много других страшных слов, на практике не имея ко всему этому ни малейшего отношения.

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

 

Итак, игра загружается, загружается, создается пространство game, пространство level, происходит еще много разного и загадочного, грузятся серверные объекты, на их основе создаются game-объекты (первым из которых, традиционно, актор), и в том числе эти самые рестрикторы.

 

У созданного рестриктора дергается net_spawn() и он заносит сам себя в табличку (обычно в bind_restrictor.script, если вы не переделали его на что-то иное). И на этом, внезапно, все.

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

На первом переборе вызывается xr_logic.initialize_obj(), делающая много чего, в том числе - читающая ini рестриктора (или еще откуда) секции [logic], активную секцию, и тому подобную лабуду, а также дергающая за xr_logic.activate_by_section(), куда передается та самая секция, по которой надо activate.

Из имени секции выделяется то, что идет до символа @, и проверяется на наличие в _G.schemes[], куда ранее попадает из modules.script

 

 

Если оно таки занесено, такой файл существует, и в нем имеется функция set_scheme() - дергается эта самая set_scheme(), создающая, внезапно, схему. ;)

 

Кстати, к аналогичному результату мы можем прийти не только отправившись в путешествие из xr_logic.initialize_obj(), но и вовсе, например, из xr_logic.try_switch_to_another_section(), однако об этом - позже.

 

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

 

function log( ... ) _util.log( "sr_idle", ... ) end

local dbst = db.storage
local actor = db.actor

local try_switch = xr_logic.try_switch_to_another_section
local subscribe_action = xr_logic.subscribe_action_for_events
local assign_storage = xr_logic.assign_storage_and_bind
local get_sw_cond = xr_logic.cfg_get_switch_conditions


class "action_idle"

function action_idle:__init( sr, st )
	self.object = sr
	self.st = st			-- сторейж схемы
	self.sr_st = dbst[sr:id()]	-- сторейж рестриктора
end


function action_idle:reset_scheme()
	self.st.signals = {}
end


function action_idle:update()
	if try_switch( self.object, self.st, actor ) then
		local sect = self.sr_st.active_section
		if sect and sect ~= "sr_idle@nil" then	-- продолжаем
			-- log( "info", "(%s):update, %s", self.object:name(), tostring( sect ) )
		else
			-- log( "info", "(%s):update, disable, %s", self.object:name(), tostring( sect ) )
			bind_restrictor.disable_update( self.object:id() )
		end
	end
end


function add_to_binder( npc, ini, scheme, sect, st )
	local new_action = action_idle( npc, st )
	subscribe_action( npc, st, new_action )
end


function set_scheme( npc, ini, scheme, sect )
	-- log( "info", "set_scheme, %s: %s", npc:name(), tostring( sect ) )
	local st = assign_storage( npc, ini, scheme, sect )
	st.logic = get_sw_cond( ini, sect, npc )
end


function init() return true end

log( "module", "ok" )

, которое тоже - "схема". Да, строчке bind_restrictor.disable_update( self.object:id() ), которой нет в оригинале, не пугайтесь: это просто небольшое дополнение, призванное прекратить перебор бессмысленный и беспощадный для тех рестрикторов, которые не делают ВООБЩЕ ничего.

Так вот, у очень некоторых из оных рестрикторов может быть вместо этого самого sr_idle@чего_то_там быть наша "пси-антенна", и тогда будет активирована она.

 

На этом сделаем паузу, чтобы автообъединение не склеило эту многобуквенную телегу с той, в которой начнутся УЖАСАЮЩИЕ подробности про собственно "антенну".

Изменено пользователем Dennis_Chikin
  • Нравится 3

Поделиться этим сообщением


Ссылка на сообщение

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

А контролер исполнял некую странную анимацию, и при этом - висел.

 

С удалением же рестриктора замечательно вылетали крысы при выбросе...

 

Впрочем, это уже про отношения с оными рестрикторами всякой живности и прочих сахаровых.

А я тут про псиантенну. Итак, обещанные УЖАСАЮЩИЕ подробности про рестриктор, у которого в логике имеется секция [sr_psy_antenna@чего_то_там]:

 

При переключении на оную секцию дергается sr_psy_antenna.set_scheme()

 

Оттуда, первым делом, обратно же вызывают xr_logic.assign_storage_and_bind(), тот создает пустую табличку, и отправляет ее в sr_psy_antenna.add_to_binder(). Отныне это будет сторейж схемы, который не следует путать со сторейжем непися, ну или, в данном случае, рестриктора, который все это действо начал.

 

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

 

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

Самое смешное, что все это кладется в xr_logic.assign_storage_and_bind() и в новосозданную передаваемую табличку. На всякий случай.

Но зато в set_scheme мы туда положить ничег своего еще не успели, и все чтения настроек будут ПОЗЖЕ ! Кто это забыл - имеет получить в самые неожиданные моменты самые познавательные вылеты. Пройдя, скажем, пару-тройку локаций...

 

А что мы в этот момент можем сделать полезного ?

В общем-то, дернуть за создание класса

class "action_psy_antenna"

function action_psy_antenna:__init( sr, st ) ... end

передать туда объект (непися или рестриктор, или еще какой вертолет), и сторэйж схемы.

А обратно получаем ссылку на новосозданную "акцию", которую осталось зарегистрировать через xr_logic.subscribe_action_for_events()

Вот как-то так (см. нижние 2 строчки):

 

function add_to_binder( sr, ini, scheme, sect, st )	-- вызывается через xr_logic.assign_storage...
	if not psy_antenna then
		psy_antenna = PsyAntenna()
		psy_antenna:construct()
		bind_stalker.task_add( "sr_psy_antenna.update", 200, update )
	end
	local a = action_psy_antenna( sr, st )
	subscribe_action( sr, st, a )

	log( "info", "add_to_binder, ok: %s, %s", sect, sr:name() )
end

Зачем здесь фрагмент if not psy_antenna then ... end ? А это специальное очень сильное колдунство, специально для того, чтоб об него все сломали себе сначала мозг, а потом и свой мод. Мы до него еще дойдем, но случится это очень сильно потом.

Пока же достаточно знать, что вернувшись отсюда, продолжит выполнение наше:

 

function set_scheme( npc, ini, scheme, sect )
	local st = assign_storage( npc, ini, scheme, sect )

	st.logic = get_sw_cond( ini, sect, npc )
	
	if sect and ini:section_exist( sect ) then
		local p = ( ini:line_exist( sect, "eff_intensity" ) and ini:r_float( sect, "eff_intensity" ) )
			or abort( "set_scheme, invalid entry [eff_intensity], sect: [%s] (%s)", sect, to_str( npc ) )
		st.intensity = p * 0.01
	else abort( "set_scheme, invalid sect: [%s] (%s)", sect, to_str( npc ) )
	end

	st.postprocess	 = ( ini:line_exist( sect, "postprocess" ) and ini:r_string( sect, "postprocess" ) )
		or "psy_antenna.ppe"

	local p = ( ini:line_exist( sect, "hit_intensity" ) and ini:r_float( sect, "hit_intensity" ) )
		or abort( "set_scheme, invalid entry [hit_intensity], sect: [%s] (%s)", sect, to_str( npc ) )
	st.hit_intensity = p * 0.01
	local p = ini:line_exist( sect, "phantom_prob" ) and ini:r_float( sect, "phantom_prob" )
	if p then st.phantom_prob  = p * 0.01
	else st.phantom_prob = 0
	end

	st.mute_sound_threshold = ( ini:line_exist( sect, "mute_sound_threshold" )
		and ini:r_float( sect, "mute_sound_threshold" ) ) or 0
	log( "info", "set_scheme, ok: %s, %s", sect, npc:name() )
end

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

И вот теперь, когда при апдейте РЕСТРИКТОРА будет дергаться xr_logic.issue_event( sr, st[st.active_scheme], "update", delta ) - это будет означать вызов action_psy_antenna:update(), прописанного в нашем sr_psy_antenna.script - каждого со своим уникальным содержимым в self и self.st

 

то есть, их может быть столько же, сколько рестрикторов на локации переключились в какой-нибудь sr_psy_antenna@

 

Умом все вот это вот понять, конечно, невозможно, и надо просто верить в ПЫС (читайте известную зарисовку про 2-х метровый фрагмент бетонного забора с выбоинами от голов, установленный посреди степи).

 

Продолжение следует.

Изменено пользователем Dennis_Chikin
  • Спасибо 1
  • Нравится 1

Поделиться этим сообщением


Ссылка на сообщение

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

 

Впрочем, согласен, что всем пофиг, и вот такое вот чудо:

function restrictor_binder:actor_update(delta)
	local st = self.st
	local zone = self.object
	if not self.initialized and db.actor then
		self.initialized = true
		xr_logic.initialize_obj(zone, st, self.loaded, db.actor, modules.stype_restrictor)
	end
	if st.active_section == "sr_idle@nil" then
		updatable_binders[zone:id()] = nil
	elseif st.active_section ~= nil then
		xr_logic.issue_event(zone, st[st.active_scheme], "update", delta)
		if sr_psy_antenna.psy_antenna then
			sr_psy_antenna.psy_antenna:update(delta)
		end
	end
end

под видом "ревизии и модернизации" мы увидим еще неоднократно.

"Пусть вылетает !" ©

  • Нравится 1

Поделиться этим сообщением


Ссылка на сообщение

Ну, во-первых, про апдейт рестрикторов вообще я писал, и измененные файлы выкладывал, просто в более другой теме, ибо могу говорить за АМК и "солянкоклоны", но не за все моды.

И, знаете, вынести несколько ДЕСЯТКОВ рестрикторов (от 30 до 80 в зависимости от локации и фанатизма мододела) из лютого, бешеного апдейта во всю мощь процессора  - на сколько способен - все в туда и ухнет - смысл вполне имеет. http://www.amk-team.ru/forum/topic/8830-narodnaia-2010-razrabotka/?p=1021981

Как говорится, включите лог, и проникнитесь.

 

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

 

И, да, сорри, за то, что начав разговор, пропал в самом интересном месте, но обещаю исправиться.

 

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

Поделиться этим сообщением


Ссылка на сообщение

Что-то у меня на счет "ниумерла" как-то двойственно выходит, так что вот вам сразу файлик, а по мере сил начну разбор. https://dl.dropboxusercontent.com/u/27871782/sr_psy_antenna.script

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

 

Соглашения обычные: актор живет в _G, там же происходят все манипуляции со временем, и туда же кладутся результаты, в частности в game_time_ms - время от старта игры. В апдейт по времени что-либо добавляется через bind_stalker.task_add(), логи выводит каждый кому как нравится.

Обращения к внешним функциям на 100500 символов длиной заменены на короткие.

 

С другой стороны, все имена переменных и вызовы, доступные извне, сохранены на случай, что мало ли у кого что к чему привязано. Это пусть любители "защит от читеров" все перименовывают в 100 других скриптах, и все true на false везде меняют. Авось им и получится в очередной раз оттянуть выход какого мода из "подполья" еще на пару-тройку лет.

 

А остановились мы в прошлый раз на "акции", которая создается по переключению рестритора на нужную секцию и апдейтится оттуда же. Поехали, по кусочкам - что и зачем:

 

 

local dbst = db.storage
...
 
local state_outside = 0    -- актер снаружи
local state_inside = 1    -- актер внутри
local state_void = 2    -- неизвестный статус

class "action_psy_antenna"

function action_psy_antenna:__init( sr, st )
    self.object = sr
    self.st     = st
    self.name = sr:name()
    log( "info", "(%s)action_psy_antenna:__init...", self.name )
    local pstor = dbst[sr:id()].pstor
    self.pstor = pstor
    if loaded and pstor.inside then
        self.state = state_inside
        log( "info", "in zone" )
    else self.state  = state_void    -- еще не ясно, в зоне он, или нет
    end
end

 

 

Получили ссылку на объект рестриктора и ссылку на сторэйж схемы, и у себя их сохранили.

А вот дальше сразу, внимание, начинаются изменения. У рестриктора, как, в принципе, и любого другого "честного" объекта, есть pstor. Это такая табличка, которая сохраняется при сохранении игры, и загружается при загрузке, как ни странно. Хотя у тех объектов, которые могут перeключаться on/offline, это скорее не работает, чем работает, остаются как раз актор, то, что у него в инвентаре, и - рестрикторы.

В общем, не вижу смысла тут что-либо менять, зато есть прямой смысл это использовать.

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

 

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

Так что когда после создания схемы у нее вызывается

function action_psy_antenna:reset_scheme()
    if self.state == state_inside then self:zone_leave() end
end

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

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

 

Ну и, наконец, апдейт:

 

function action_psy_antenna:switch_state()
    if self.state ~= state_inside then
        if self.object:inside( actor:position() ) then
            log( "info", "(%s):switch_state, enter", self.name )
            self:zone_enter()
            return
        end
    elseif not self.object:inside( actor:position() ) then
        log( "info", "(%s):switch_state, leave", self.name )
        self:zone_leave()
    end
end

function action_psy_antenna:update()
    if try_switch( self.object, self.st, actor ) then return end
    self:switch_state()
end

 

 

xr_logic.xr_logic.try_switch_to_another_section() здесь, как и везде, проверяет: не настало ли время переключиться на что-нибудь более другое, и если да, что что-либо делать здесь более не имеет смысла. switch_state спрашивает у рестриктора посредством self.object:inside( actor:position() ) - внутри ли актор, и в зависимости от результата посредством zone_enter() или zone_leave() во-первых, передает странному и загадочному class "PsyAntenna", который, ВНИМАНИЕ, создается только ОДИН раз и сохраняется в sr_psy_antenna.psy_antenna тоже только ОДИН раз. То есть, рестрикторов много, мест, где создаются схемы - много, и существовать они могут одновременно, а вот этот - ОДИН.

 

Из оставшихся тонких мест - манипуляции с постэффектами.

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

Поэтому, при первой отработке zone_enter() проверяется, имели ли мы уже дело с таким эффектом, и если да, то от нас требуется лишь передать в куда-то его "силу", которую мы сейчас хотим:

    local pname = st.postprocess
    local p = psy_antenna.postprocess[pname]
    if p then
        p.intensity_base = p.intensity_base + st.intensity
        return
    end

а вот если нет, тогда добавляем psy_antenna.postprocess[pname] = {табличка с его свойствами}, включаем сам эффект, и устанавливаем на некий минимум.

 

При выходе же возвращаем взад все наши "интенсивности", но не трогаем действующие постэффекты.

 

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

Вот здесь важно то, чтобы эта наша бурная фантазия не решила сохранять текущую громкость звука и количество фантомов, имеющих отношение к ОДНОМУ актору, в каждый из тех нескольких сотен рестрикторов, которые ранее сами наплодили на локации( а если их  плодили не мы, а ПЫС - тем более).

 

окончание следует.
 

Изменено пользователем Dennis_Chikin

Поделиться этим сообщением


Ссылка на сообщение

Так, по антенну я что-то опять забыл (а что - у меня-то все работает, сэйвы не бьются, если, скажем, на янтаре н территории завода до получения шлема сохраниться/загрузиться, или на радаре непосредственно на антеннах, вечная желтизна при каждом s/l там же не настает...) Виноват, исправлюсь. А сейчас хочу поделиться более другим:

 

xr_combat_ignore, в некоторых модах, не будем показывать пальцем, выглядит как-то так:

function set_combat_ignore_checker( npc, ini, scheme, section )
	local st = xr_logic.assign_storage_and_bind( npc, ini, scheme, section )
	st.enabled = true
--	npc:set_enemy_callback( blowout_scheme.enemy_callback, nil )
	-- Подписываемся на hit callback-и:
	xr_logic.subscribe_action_for_events( npc, st, st.action )
end
А потом мы удивляемся, что оно не работает.

В то время как в оригинале имеет место быть совершенно логичный npc:set_enemy_callback( st.action.enemy_callback, st.action )

 

Гуманности ли ради ? ©

Изменено пользователем Dennis_Chikin

Поделиться этим сообщением


Ссылка на сообщение

Ну, тут некоторые не смогли заставить работать

[myjob_combat_ignore]

dist = 50

...

[mysect]

combat_ignore_cond = 100

 

Ну или {+то_что_есть_всегда} - без разницы.

Поделиться этим сообщением


Ссылка на сообщение

Хочется ругаться матом...

 

В общем, оный blowout_scheme.script скорее работает, чем не работает, но, при этом, воистину, в слове из трех букв - 5 ошибок, а что остальные криворукие граждане вокруг навертели, на форуме про это пункт 2.0 правил рассказывает.

 

В общем, ни проверке условий вступления в бой, ни "обходу аномалий" там не место. Я, конечно, понимаю, что ООП и все такое, но результат: либо reset() либо прерывание execute() с возвратом на исходную позицию и попыткой повтора сначала практически во всем, что на это понавесили.

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

 

Теперь, что касается непосредственно "обхода аномалий":

метод с добавлением restrictions прекрасно работает, и реализуется точно так же, как и у монстров.

Неписи же, которые либо упорно лезут в аномалии, что ты с ними не делай (ну или при попытке сделать в итоге виснут) - все 146% являются задумкой авторов, и, у простого смертного, не владеющего исходниками олспавна, метод борьбы с этим, по сути, остается только один:

1. При НИ удалить таких неписей из игры вместе с логикой, прописанной {здесь было, как мне указали, нечто такое, завуалированное, так что пришлось выпилить. Честное слово, ни одна из известных математических констант не использовалась.} автором.

2. Создать свой смарт (на самом деле скриптовое создание смартов - не так уж сложно) или использовать готовый,  посадить непися под него. Точки работ и расстояние "достижения работы" должно быть в зоне, полностью свободной от аномалий. Между этими свободными областями непись нормально передвигается под движком, с учетом прописанных restrictions.

Изменено пользователем Dennis_Chikin

Поделиться этим сообщением


Ссылка на сообщение
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...