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

[Dennis_Chikin 3 664]

А это типа отключение выброса на АЭС от какого-то древнего nlc3.

Оттуда же сохранение каких-то странных телепортов в нетпакет пда - не до конца вычистил.

Изменено 30 Июля 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 664]

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

 

1. У бтр вроде-ж и так списки исключений были, или это я уже запутался в версиях ?

 

По _G namespace, действительно, не пора уже составить список рудиментов/дополнений, и договориться ориентироваться на него ?

Воистину, достал уже этот db.actor и эти "ammo".

[Dennis_Chikin 3 664]

(для поиска: Управление инициализацией модулей и апдейтом, плавный апдейт.)

 

Вообще-то не совсем в сюда, но пока пусть будет.

 

Об чем это и зачем:

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

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

Наконец, меня утомило набивать во все мыслимые и немыслимые места проверки типа if db.actor then ..., хотя я точно знаю, что до появления оного актора этот модуль не нужен от слова "совсем".

 

Поэтому, делаем следующий трюк:

-- "ручная" инициализация модулей, для контроля корректности
-- и обеспечения порядка инициализации для зависимых модулей

function log( ... ) _util.log( "_init", ... ) end
function abort( ... ) _util.abort( "_init", ... ) end


local t = {	-- последовательность важна !

["start"] = {	-- инициализация глобальных таблиц и менеджеров
	"_util",		-- служебные функции
	"_tbl_npc",		-- разные забавные особенности неписей
	"_tbl_protected",	-- защищенные предметы
	"_tbl_global",		-- соответствия классов и типов
	"_tbl_outfits",		-- костюмы
	"_tbl_levels",		-- уровни
	"_tbl_treasures",	-- тайники
	"_tbl_deathmgr",	-- лут
	"_tbl_sounds",		-- звуки
	"sound_theme",
	-- не требуется -- "amk_netpk",		-- работа с нетпакетом
	"xl_imgr",		-- кэши параметров предметов
	"amk"			-- управляющий скрипт амк (помойка на самом деле)
	},

["amk"] = {},	-- дополнения amk

["actor"] = {	-- скрипты, требующие актора
	"actor_data",		-- данные актора, нужны для всего онлайнового
	"ui_amk_options",	-- опции солянки
	"fix_it",		-- правки глюков allspawn 2010.14.08
	"amk_timers",		-- таймеры (сохраняются в pstor)
	"xr_sound",		-- звук
	"news_manager",		-- типсы, init не нужен, но пусть будет
	"sr_psy_antenna",	-- пси-излучение, самоинициализируется, но для контроля вставим
	"bind_restrictor",	-- обновление рестрикторов (в основном всякие "разрывающиеся рюкзаки" и прочая ересь
	"amk_spawn",		-- спавн amk
	"inv_manager",		-- инвентарь актора
	"arc_containers",	-- контейнеры для артов
	"dialogs",		-- функции для диалогов
	"xl_offline",		-- состояние объектов в офлайне (требует level)
	"amk_anoms",		-- аномалии
	"bind_art",		-- арты, для детектора, и будет еще для "контейнеров"
	"death_manager",	-- лут
	"xl_online",		-- состояние объектов в онлайне
	"xr_box",		-- лут из ящиков
	-- не включать - init() дергается из конфигов -- "bind_physic_object"	-- всякая всячина, от ящиков до БТР
	"news_data",		-- тексты новостей
	"news_main",		-- новости
	"level_weathers",	-- смена погоды
	"ui_rad",		-- шкала радиации
	"actor_effects",	-- эффекты актора

	"treasure_manager",	-- тайники
	"task_manager",		-- квесты
	"dialog_manager",	-- диалоги
	"sr_territory",		-- стрельба на особых территориях, инициализация не нужна, но пусть будет
	"xl_relations",		-- сообщества и отношения
	"bind_heli",		-- вертолет
	"mob_combat",		-- схемы монстров, не нужно, но чтобы было, для контроля
	"mob_death", "mob_panic", "mob_trade", "mob_trader",
	"arc_diary",		-- дневники контролеров
	"bind_monster",		-- онлайн-монстры
	"watcher_act",		-- сбор лута, лечение, оттаскивание трупов
	"xr_wounded",		-- ранения, чтобы было
	"xr_motivator",		-- онлайн-неписи

	"sak",			-- функции сюжета и диалогов Сяка
	-- "amk_offline_alife",	-- офлайн, устарело
----	"tag_spb",		-- превращение трупов в зомби при выбросе
	"amk_mod"		-- большая помойка от АМК
	},

["np_pda"] = {	-- требуют netpacket_pda в онлайне
	"spawn_level_changer",	-- телепорты и принудительные смены уровня
	"bind_mteleport",	-- внутриуровневые телепорты, создание/удаление здесь же
----	"flamethrower",		-- огнемет
----	"repair_check",		-- ремонт и апгрейд
----	"aem_manager",		-- арена
	"storyline",		-- сюжет
	"escape_dialog",
----	"braad_test",		-- функции сюжета, прибито гвоздями к all.spawn
	"kostya_dialog",	-- функции сюжета и диалогов
----	"new_dialog",		-- функции сюжета и диалогов
----	"wawka_dialog",		-- функции сюжета и диалогов
--	"arhara_dialog",	-- функции для диалогов Архары
	"actor_devices",	-- функции шмоток актора
--	-- "amk_artmod",	-- варка артов
--	-- "ui_pda_art_mod",	-- какой-то девайс для варки артов, устарело
	"biodetector",		-- детектор монстров (раньше не нужен)
	"repbox",		-- ремящик 
	"sleep_manager"		-- сон
} }


local m_name = false


function check( blk )
	local f, pt1
	local tt = t[blk]
	local pt2 = profile_timer()
	pt2:start()
	for i = 1, #tt do
		if m_name then abort( "error in module [%s]", m_name ) end
		m_name = tt[i]
		f = _G[m_name].init
		if f then
			pt1 = profile_timer()
			pt1:start()
			if f() then
				pt1:stop()
				log( "init", "init %s [%s], ok (%s)", m_name, blk, pt1:time() )
			else
				pt1:stop()
				log( "warning", "init %s [%s], !true (%s)", m_name, blk, pt1:time() )
			end
			m_name = false
		else abort( "init, no %s.init() [%s]", m_name, blk )
	end	end
	pt2:stop()
	log( "init", "profile time: %s", pt2:time() )
end

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

 

Теперь в соответствующие скрипты добавляем вызов с именем таблицы, по которой производим инициализацию. В данном случае, это _g.start_game_callback(), bind_stalker.netspawn() и вход в онлайн некоего предмета. То есть, например

function start_game_callback()

...

_init.check( "start" )

в _g.script

 

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

Например, в

local t50, t200, t1000, t5000 = {}, {}, {}, {}		-- группы { строка для wathdog, функция }
local t50n, t200n, t1000n, t5000n = 0, 0, 0, 0		-- функций в группе
local t50i, t200i, t1000i, t5000i = 1, 1, 1, 1		-- текущая функция в группе
local t50t, t200t, t1000t, t5000t = 0, 0, 0, 0		-- время следующего обновления
local t50q, t200q, t1000q, t5000q = 50, 200, 1000, 5000	-- через сколько обновлять


function task_add( tname, tgroup, f )
	if ( tgroup or 200 ) == 200 then t200n = t200n + 1; table_insert( t200, { f, tname } )
	elseif tgroup == 1000 then t1000n = t1000n + 1; table_insert( t1000, { f, tname } )
	elseif tgroup == 5000 then t5000n = t5000n + 1; table_insert( t5000, { f, tname } )
	elseif tgroup == 50 then t50n = t50n + 1; table_insert( t50, { f, tname } )
	end
end

function task_del( tname, tgroup )
	-- log( "info", "task_delete, task: [%s], gp: %s", tname, ( tgroup or "any" ) )
	if tgroup or 200 == 200 then
		for i = 1, t200n do
			if t200[i][2] == tname then
				t200n = t200n - 1; table_remove( t200, i ); return
	end	end	end
	if tgroup or 1000 == 1000 then
		for i = 1, t1000n do
			if t1000[i][2] == tname then
				t1000n = t1000n - 1; table_remove( t1000, i ); return
	end	end	end
	if tgroup or 5000 == 5000 then
		for i = 1, t5000n do
			if t5000[i][2] == tname then
				t5000n = t5000n - 1; table_remove( t5000, i ); return
	end	end	end
	for i = 1, t50n do
		if t50[i][2] == tname then t50n = t50n - 1; table_remove( t50, i ) end
	end
end

и в function actor_binder:update( delta ) вместо развесистой икебаны что-то типа:
if t5000i == 0 then	-- ни чем не заняты ?
	if global_time_ms >= t5000t then t5000t, t5000i = global_time_ms + t5000q, 1
		-- kostri_update()	-- используем этот цикл под что-нибудь полезное
	end
else
	gp_fn =  t5000[t5000i]	-- выполняем последовательно что там еще есть
	if gp_fn then t5000i, amk.oau_watchdog = t5000i + 1, gp_fn[2]; gp_fn[1]()
	else t5000i = 0		-- и здесь же используем остаток
end	end
-- для каждой из 4-х групп

 

 

Собственно, обнаруживаем, что лучше всего именно сюда только и стоит добавлять ЛЮБЫЕ апдейты, то есть вообще любые.

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

 

Почему именно 4 группы ? По тому что чисто эмпирически выяснено, что именно такая частота апдейтов наиболее подходит для разных задач: 50ms, 200ms, 1000ms и 5000. Ну и соответственно, лишние вызовы, которые ничего не делают, но каждый раз проверяют прошедшее время - не нужны.

 

 

Дальше, как я уже показывал, например, для "таймеров" имеем в соответствующем модуле примерно следующее:

function init()
	local t = actor_data.get_pstor()	-- хранилище данных актора
	if t.timers then
		for k, v in pairs( t.timers ) do
			timer_n = timer_n + 1
			timer_t[timer_n] = { k, v[1], v[2] }
	end	end
	timer_sort = true

	for k, v in pairs( {
	--["blowout"]		= amk_mod.Blowout_pp,
	--["test"]		= amk_mod.Run_Blowout_pp,
	--["blowout_ss"]	= amk_mod.blowout_scary_sounds,
	--["blow_shift"]	= amk_mod.Run_Blowout_pp,

	--["item_transform"]	= amk_mod.item_transform,
	["timer_test"]	= timer_test }
	) do timer_f[k] = v end

	bind_stalker.task_add( "amk_timers.check_timers", 200, check_timers )
	bind_stalker.add_on_save( on_save )
	timer_start( "timer_test", 1 )
	return true
end

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

local t_outfit_cnd

function set_item_condition( t )
	local t, n = {}, 0
	local item
	for i, v in pairs( t_outfit_cnd ) do
		item = lobj_by_id( v[1] )
		if item then item:set_condition( v[2] / 100 )
		else n = n + 1; t[n] = v
	end	end
	if n ~= 0 then t_outfit_cnd = t
	else
		t_outfit_cnd = false
		bind_stalker.task_del( "death_manager.set_item_condition", 1000 )
	end
end

function on_death( npc, t_wpn )
...
obj = create_items( npc, sect, 1 )
if obj then
	if t_outfit_cnd then
		t_outfit_cnd[#t_outfit_cnd + 1] =
			{ obj.id, math_random( cnd_min, cnd_max ) }
	else
		t_outfit_cnd =
			{ { obj.id, math_random( cnd_min, cnd_max ) } }
			bind_stalker.task_add( "death_manager.set_item_condition", 1000, 	set_item_condition )
end	end

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

 

 

Вот такой вот лисапет. Как обычно, без супернаворотов, ни какого новомодного ООП и других страшных слов, но свою задачу выполняет.

 

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

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

Ну и, наконец, контроль делаемого головой - ни какой противоестественный недоинтеллект все равно не заменит, а следовательно - и не нужен. Например, апдейт на 50ms должен выполнять все добавленное не последовательно, а за раз, по тому как более чем на 2 фазы растащить не удастся. Равно как 200ms - это не более десятка функций (а более, в общем-то, и не нужно; если же их получилось больше - скорее всего, у вас что-то дублируется).

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

[Dennis_Chikin 3 664]

"Попутно вопросец... кто-нибудь занимался рефакторингом smart_terrain.script в человекочитаемый вид?"

 

А вот догадайся !

http://www.amk-team.ru/forum/index.php?showtopic=8830&p=902212

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

 

Но вот кстати npc_info - да, это ужасно, и вот до нее руки так и не дошли - отложил "на потом".

Там надо сделать ОДНО заполнение. А еще - подключить заполнение классов через class_registrator.

Касательно id, squad и group: id - нужен для функций во всяких gulag_траляля.script - ну, то есть, как минимум, теоретически может понадобиться.

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

[Dennis_Chikin 3 664]

Полагаю, что автор вопроса и ответ тоже поймет.

 

Для просто интересующихся, я не телепат, и по этому не знаю, кто и в каком моде в какие именно работы вставит проверку, использующую этот самый npc_info.id, или, скажем сквад.

Ну, может быть он захочет game_object непися получить...

 

Или где-то болтается рудимент, определяющий по team, кого непись должен атаковать: врагов, или актора.

Поиском по файлам это не берется. Просматривать руками весь all.spawn - тут уж кому интересно, тот пусть и просматривает.

 

 

2 Карлан: по поводу человекочитаемости smart_terrain ты однако чрезмерно оптимистичен. Да, что делает в отдельности каждая функция - в принципе понятно. Но вот то, что они там весьма рекурсивны, а вызовы идут, традиционно, через 20 скриптов - в голове такое удержать физиологически невозможно.

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

[Dennis_Chikin 3 664]

Я предпочел развернуть. Оно и пошустрее, кстати, будет.

[Dennis_Chikin 3 664]

Так посмотри уже по ссылке. Глядишь - полегчает.

 

А что касается type, то оно, как те брюки, почти превратилось в имя. Так что запятые там точно - не.

 

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

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

[Dennis_Chikin 3 664]

а все остальные gulag_XXX.script выбросил на помойку.

Вообще-то "все остальные" - имеют смысл с точки зрения размера файла и, соответственно, удобства редактирования.

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

 

посоветую порядок

Я ничего не понял. smart_terrain - практический такой же (почти) объект, как непись, монстр или буханка хлеба.

Соответственно, когда при загрузке сэйва доходит до него, он инитится, и потом апдейтится.

Для se_respawn он нужен только в смысле чтения конфига( ну вот так вот эти самые конфиги организованы, per rectum) и для проверки: есть ли место свежезаспавненному монстру.

 

xr_sound не нужен точно.

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

 

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

 

gulag_general/что_попало - опять же, как бы, разделили.

 

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

 

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

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

[Dennis_Chikin 3 664]

Из всего перечисленного, движок имеет отношение ТОЛЬКО к smart_terrain и к se_respawn. Как дергающий иниты и апдейты объектов соответствующих классов.

[Dennis_Chikin 3 664]

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

 

Как бы, все. Остальное пока оставить схемам, благо, они и без смартов отлично работают.

эволюцию логики от кордона до чаэс

Чем дальше - тем страшнее ?

[Dennis_Chikin 3 664]

Что-то я подзабыл. напомни?

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

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

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

[Dennis_Chikin 3 664]

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

[Dennis_Chikin 3 664]

Как бы, может тогда просто стоит вывести в лог имена и id дублей ?

[Dennis_Chikin 3 664]

с чем связано зависание логики?

С любой некорректной операцией/аргументом операции. То есть, это надо просто тупо падать, и все.

Впрочем, скриптово ловится, если amk-шную собаку поменять наоборот: проверка не в биндере монстра/непися, а в акторе.

[Dennis_Chikin 3 664]

(для поиска: se_respawn, респавн)

 

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

У меня вот, однако, все таки не без него. Хотя руки чешутся, да.

Хотя 4 года назад таки, действительно исправил. И получил таки образом очередной Код Шредингера , который традиционно работает на одной единственной сборке, существующей в одном единственном экземпляре.

 

Но тем не менее несколько слов хочу сказать. Во-первых, почему НЕ НУЖЕН.

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

Причем, спавн был определенных врагов в определенных местах, и шли они тоже в определенные места. За пределами "троп миграций" их встретить было нереально.

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

 

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

 

Вот только вопрос: а зачем она ТАК идет ?

Если у нас, неведомо от игрока, кто-то там чего-то создает, кто-то убивает, а в результате игрок может опять же на тех тропах миграции кого-то встретить (но - ре-едко, я бы даже сказал - очень-очень иногда, сразу после дождичка в четверг при юпитере в созвездии белой обезьяны, в полнолуние, когда рак взбирается на гору и дает там три зеленых свистка вверх), так вот не проще всю эту живность там же, в оффлайне, ПРОСТО сразу гонять между лагерями ?

Не создали-дошла-забили, а просто взяли, и погнали из одного лагеря - в соседний ?

А если вдруг нехватка образовалась, то проверить вот эти самые лагеря на пустоту, и сразу там же и дополнить ?

 

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

 

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

Изменено 6 Ноября 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 664]

2 abramcumner: Воистину так ! ВРЕМЯ НЕ ПРИШЛО. И еще не скоро. Вообще, каждое знаньице - оно должно вылежаться, лет, этак, 50, не менее, прежде чем в дело пускать. Да и то - с оглядкой. Ибо как бы чего не вышло. Враги кругом, а еще - злобные читеры, которые только и ждут выхода мода без мгновенного респавна 30-контролеров верхом на химерах.

 

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

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

 

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

 

Ну, во-первых, по тому, что в смартах есть параметры, отвечающие за прием этого самого свежезаспавненного мяса. И вот крутить надо ИХ.

Во-вторых, что касается самого респавна, то там, с оригинала, есть 4 основных параметра: минимальное количество чего-то, максимальное количество, количество для этого респавнера, и время респавна. А именно, если не переделывать синтаксис, это будут min_count =, max_count =, max_spawn =, и spawn_idle = 2 цифры или слова через запятую.

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

Изменено 6 Ноября 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 664]

ОГСЕ ?

В общем-то, чего-то ТАКОГО нехватающего - именно там - не обнаружил. Возможно, этому чему-то там и не вполне место ?

 

Имеет место быть древний баг с запихиванием в storage имеющегося врага, а потом попыткой что-то с ним сделать в xr_conditions, независимо от того, существует ли еще оный враг хотя-бы в онлайне, не говоря уж как серверный, но это как бы именно проблема conditions и самой системы логики, для которой условие "не стрелять" требует, чтобы сначала БЫЛО в кого стрелять.

 

P.S. Потрошение респавна чуток задерживается.

Изменено 8 Ноября 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 664]

Для поиска: xr_gulag, team, squad, group

Немножко свежих новостей:

 

Возможно, по одному вопиющему факту писать рано, но тем не менее. Многим, наверное, памятны ВНЕЗАПНЫЕ атаки на "Деревню Новичков" со стороны блокпоста. Объяснялись они разными доброжелателями по-разному: от "надо вовремя убивать кабанов", до "несертифицированного железа" и "нелицензионного виндовса".

 

Из всех этих 1001 причин, кабаны, действительно, бывают очень даже причем, ибо радиус брожения завышен (ага, это вы еще ролики Неназываемой Игры плохо смотрели), а функция в gulag_escape.script гонит БП в атаку не разбираясь, кто там и зачем на дорогу вылез полежать.

 

Ну вот мне, наконец, опался устойчивый, воспроизводимый вариант этой самой атаки с БП на бункер сидоровича. Как ожидалось, паленая водка не при чем.

имеются следующие персонажи:

1. agr_soldier_regular39174, team: 7, group 0, squad 0 - сидит на БП, смотрит телевизор

2. resp_esc_bridge129202, team: 7, group 0, squad 0 - стоит под мостом.

 

У остальных, кто в этот момент находится в онлайне, team, group, squad - более другие.

 

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

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

 

Меняем на более другие, чтоб не совпадали - вуаля, телепатия пропала.

 

Кстати, о птичках, многопостовая тема скриптования:

1. http://www.amk-team.ru/forum/index.php?showtopic=6185&p=877660

и там же следующее. Вот вам и "применение в игре".

Просто упомнить - нереально, а искать: надо знать - что.

Изменено 10 Ноября 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 664]

Кажется, даже в АМК случалось. Ну, то есть, как только вот тот мост заселили.

[Dennis_Chikin 3 664]

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

 

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

 

"больше 32 НПЦ попадает" - хе-хе. Толсто.

---

Для поиска, gulag_escape.script:

 

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

А рабочий блокпост при тревоге, видимо, вообще ни кто ни разу никогда не видел. Они как бы должны не на улицу ломиться, и далее через весь Кордон в неведомые дали, а занимать места согласно путям в работах. За ГГ же выламываться только те, кто реально видел, и члены как раз квада.

Изменено 10 Ноября 2015 пользователем Dennis_Chikin