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

[Dennis_Chikin 3 658]

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

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

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

[Desertir 202]

Черные и белые списки используются в своих конкретных случаях. Не стОит принижать их значимость относительно друг друга. Такая проблема состряпать скрипт для обоих случаев? А там что хотят - пусть используют.

А на счет нечести, может создать категорию monsters. Написали её в логике, значит в скриптах это будут все монстры. Очень сомневаюсь, что такое невозможно. Конечно и к этому придумать всякие исключения, например смысл БТР стрелять по тушканам/крысам? Опять же если их не сотни.

Квест. Да - надумано, но ведь квест.

Добавлена группировка "Человеки". За пределами Кордона стоит военный БТР и не пускает человеков в Зону. Есть военные, возможно крысы/кошки/собаки/птички - мирные ко всем, просто дикие, Зона же дальше. ГГ и его команде из 2-х человеков надо попасть в Зону, желательно незаметно, настоятельно без потерь. А и еще, во время вылазки ГГ из Зоны идет отряд долговцев, т.к. их аванпосту недалеко в Зоне надо пополнить запасы скажем еды. Долг же в основном военный, так что будем считать, что они дружат с местными вояками. Это момент для ГГ чтобы проскочить под шумок, не знаю почему, но экипаж БТР тоже отвлекается на время, уж не придумал. Итак имеем человеков, военных, долг + возможная живность. Какой список будет короче, черный или белый?

 

[Карлан 1 049]

Такая проблема состряпать скрипт для обоих случаев?

 

Проблем никаких, только зачем они нужны? Смотри мой вариант, там можно указать и enemy, и monster, и human, и btr_enemy, и heli_enemy. Никаких проблем. Можно сделать на уровне логики, можно сделать на уровне функции, можно сделать на уровне схемы, кому как угодно. Все зависит от целей и личных предпочтений в оформлении, за все что угодно это надо взывать только к тем кто пилит какие-то платформы и иже с ними, те кто делают под свои нужды я думаю в таких советах не нуждаются. В копирайт не смог, он меня сломал.

[Desertir 202]

Ну так круто же, если все канает, в чем проблемы?

[Forser 47]

@_Val_, а вот допустим, представь обратную ситуацию. Турельку поставить, чтоб только по долгу палиЛа. В общем, самый выгодный вариант - группировка. Ну либо делать две схемы поведения. Изменено 30 Августа 2015 пользователем Forser

[Карлан 1 049]

@Desertir, так вроде про проблемы и слова не сказали, просто обсуждаем как будет лучше. Я в принципе уже наметил план действий, но по плану до этой схемы мне еще долговасто.

 

@Forser, ты тоже мой пост пропустил? Таки там можно не только enemy писать, но и группировки в отдельности, тоже никаких проблем, две схемы ради этого - нонсенс. Ты пишешь шаблонный кондлист, это все парсится в удобный массив, если он для тебя не удобный, пишешь свой синтаксис и свой парсер, делаешь как нужно, настраиваешь как нужно, далее уже пишешь поведение, но это уже степ два.

 

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

[Forser 47]

Forser, ты тоже мой пост пропустил?

 

Я сейчас залипаю по жёсткому, чтоб адекватно отвечать на всё и понимать о чём сейчас речь. Изменено 30 Августа 2015 пользователем Forser

[Dennis_Chikin 3 658]

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

 

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

 

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

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

[Карлан 1 049]

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

 

А тем временем я снова обновил.

[_Val_ 2 225]

 

 

представь обратную ситуацию. Турельку поставить, чтоб только по долгу палиЛа.

Представил...Долгу у нас враждебна Свобода и Монолит. Про Монолит обсуждать не будем...Поговорим про Свободу. Где-то у них стоит турелька - в список исключения которой прописаны ГГ, свободовцы и обычные сталкеры, которые могут теоретически посещать базу Свободы. По всем остальным она дубасит - в чем проблема?

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

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

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

И да - не вижу пока ситуаций, в которых белый список может оказаться уж слишком обширным. По крайней мере - имеется возможность его расширять)) А в другом варианте логики пока только одна цель, хоть тресни...

[Forser 47]

@_Val_, признаю свою ошибку, убедил. 

[Полтергейст 37]

Можно сделать постоянный вызов функции проверки на враждебность (типа enemy_callback) и сделать в ней проверку на combat_ignore (читать combat_ignore_cond из активной секции и секции логики) - так просто привычнее. Дополнительно к этому указывать группировку-владелец.

[Zander_driver 10 333]

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

Короч, есть такие объекты, смарт_террейны называются. Пачка методов к ним описана в smart_terrain.script.

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

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

* DBG: smart_terrain:         Капитан Орехов [rank: 267] Location: l01_escape
 TABLE:;
   {
   [KEY:  STRING:exclusive] = VALUE:  BOOLEAN:true;
   [KEY:  STRING:community] = VALUE:  STRING:dolg;
   [KEY:  STRING:group] = VALUE:  NUMBER:2;
   [KEY:  STRING:story_id] = VALUE:  NUMBER:12527;
   [KEY:  STRING:o_group] = VALUE:  NUMBER:2;
   [KEY:  STRING:level_vertex] = VALUE:  NUMBER:300835;
   [KEY:  STRING:smart_terrain_id] = VALUE:  NUMBER:1796;
   [KEY:  STRING:squad] = VALUE:  NUMBER:1;
   [KEY:  STRING:stay_end] = VALUE:  USERDATA;
   [KEY:  STRING:o_squad] = VALUE:  NUMBER:1;
   [KEY:  STRING:game_vertex] = VALUE:  NUMBER:208;
   [KEY:  STRING:id] = VALUE:  NUMBER:1797;
   [KEY:  STRING:se_obj] = VALUE:  USERDATA;
   [KEY:  STRING:is_sniper_name] = VALUE:  BOOLEAN:false;
   [KEY:  STRING:section_name] = VALUE:  STRING:stalker;
   [KEY:  STRING:profile_name] = VALUE:  STRING:kordon_orexow;
   [KEY:  STRING:is_sniper] = VALUE:  BOOLEAN:false;
   [KEY:  STRING:name] = VALUE:  STRING:orexow;
   [KEY:  STRING:weapon_rating] = VALUE:  NUMBER:5;
   [KEY:  STRING:team] = VALUE:  NUMBER:10;
   [KEY:  STRING:cond] = VALUE:  TABLE:;
   Table value:
      {
      [KEY:  NUMBER:1] = VALUE:  TABLE:;
      Table value:
         {
         [KEY:  STRING:infop_check] = VALUE:  TABLE:;
         Table value:
            {
            }
         [KEY:  STRING:infop_set] = VALUE:  TABLE:;
         Table value:
            {
            }
         [KEY:  STRING:section] = VALUE:  STRING:true;
         }
      }
   [KEY:  STRING:class_id] = VALUE:  NUMBER:34;
   [KEY:  STRING:rank] = VALUE:  NUMBER:237;
   }

 

 

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

Например - общая таблица npc_info, индексирована как мы помним, id объектов. интересно для чего в таком случае, id также содержится в самой таблице в качестве поля?

И самое интересное. свойства нпс squad и group. Когда-то давно я уже о них спрашивал на страницах форума, ответ дословно не помню, но там было что-то смутно-расплывчатое в духе "это какая-то фигня нужная для работы смартов".

Видимо архи-нужная, раз эти сквад и гроуп записаны в таблицу непися каждый по два раза дублируя друг друга - поля squad и o_squad, group и o_group. Я вывел такую статистику по всем смартам на всех локациях, просмотрел, и... у 99% нпс сквад всегда 0, и группа тоже 0.
у всех остальных, у того самого одного процента, сквад 1, группа 2. и все эти особенные нпс - занимают эксклюзивные работы и имеют собственный стори_ид.

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

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

[Dennis_Chikin 3 658]

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

 

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

 

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

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

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

Наконец, меня утомило набивать во все мыслимые и немыслимые места проверки типа 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 658]

"Попутно вопросец... кто-нибудь занимался рефакторингом 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 - ну, то есть, как минимум, теоретически может понадобиться.

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

[Murarius 10 531]

 

 

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

Ммм... Автор вопроса, полагаю, это понимает. Во всяком случае надеюсь, что понимает. Его интересовало "где и как"? Ты отвечаешь, что "теоретически да".

[Карлан 1 049]

Тимы/сквады/группы - dejure используются, defacto нет, они не доделаны и их можно "опустить", вылились они я уже писал во что, что это такое и как это должно было бы работать описывал и Artos несколько лет назад, и я несколько месяцев назад, и я уверен что еще много кто, я ничего расплывчатого в своих суждениях не увидел. Посмотреть как сделаны эти самые smart_terrain, xr_gulag, gulag_что-то_там и наконец xr_logic у меня получится уже не скоро. Переписывались они кстати говоря по порядку дерганья движком, что помогало прослеживать нити зависимостей в которых тоже много забавного. smart_terrain вполне примитивен, для меня он и в оригинале человекочитаем.

[Dennis_Chikin 3 658]

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

 

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

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

 

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

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

 

 

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

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

[Карлан 1 049]

@Dennis_Chikin, поэтому все пишется от меньшего к большему, по цепочке рекурсии спускаешься на самое дно и начинаешь разбираться. По другому и не выйдет я думаю. Сам smart_terrain это просто скрипт-делегат, для меня он был не сложен наверное потому что я сначала скурил весь xr_gulag. Но честно говоря лучше конечно заняться самому написанием этой эпопеи, другой вопрос есть ли у человека желание.

[Dennis_Chikin 3 658]

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

[Zander_driver 10 333]

Ну да, smart_terrain не является рекордсменом среди нечитаемых скриптов) все более менее сносно, но притом весьма горбато работает. Это вот и раздражает слегка.
Хотя, не настолько чтобы я взялся собственноручно его переписывать. Если постараться - читаемо, да. И в принципе работает. Так что при отсутствии альтернатив пока сойдет и то что есть.