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

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

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

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

smart_terrain я пытался переписывать.

Многократное заполнение npc_info, малопонятные алгоритмы распределения работ и сохранение работ не там, где надо - это только то, что на поверхности. Если копать глубже, там целый ворох проблем, связанных с особенностями передвижения NPC. Там и move_mgr придётся сильно дописывать, и xr_logic править, и много что ещё. Для полной синхронизации онлайн/оффлайн надо вообще в движок лезть.

 

И по-хорошему, надо читать параметр type как несколько разделённых запятыми строк, а не как одну. Чтобы, как и задумывалось изначально, можно было не плодить дубли смартов (на подобии esc_fabrika_bandit и esc2_st_fabric), а просто при выдаче infoportion перейти от одного типа к другому. Это намного удобнее, чем все эти номерные состояния, работающие черте как.

 

Ко всему прочему, для улучшения производительности при загрузке игры надо переписывать файлы gulag_***.script и делать склейку строк через table.concat. 

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

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

Там большая часть с оригинала, соответственно, многие глюкобаги остались.

Smart_terrain создавался для двух целей:

• во-первых, для назначения логики всем приходящим NPC
• во-вторых, для того, чтобы работало передвижение в оффлайне в соответствии с этой логикой. Без smart_terrain в оригинальном движке оно не работает совсем, а с ним - только частично (к первой точке пути).

В оригинальном варианте, с одной стороны, много всего лишнего, а с другой - нет того, чего надо. Лишнее - это добавление рангов за посещение smart_terrain, обращения к sim_statistics при вызове (un)register_npc, чтение capacity из custom_data, сохранение npc_info, эксклюзивности и работ в самих объектах smart_terrain, всякий хлам вроде idle_after_death вместо нормального освобождения работ при вызове серверного колбека on_death.

Тормозной алгоритм назначения смартов для эксклюзивных npc вместо обработки в функциях se_stalker/se_monster:update списка смартов, прописанных в customdata в секции smart_terrains. Какой-то совершенно непонятный критерий выбора смартов неэксклюзивными NPC, потенциально способный привести к слишком частой смене смартов.

 

Не хватает изменяемого type (через запятую список секций, затем в каждой секции параметр-condlist), динамического списка разрешенных группировок (который можно реализовать через смену type), Также не помешало бы изменить способ хранения работ и соответствющих им объектов в таблице Job. Вместо Job[number] могло бы быть что-то вроде Job[section][number].

Изменено 8 Октября 2015 пользователем Полтергейст

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

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

Как мне кажется, просто сами себя переиграли. Вынесли class "gulag" отдельно, чтобы в него написать всё, что необходимо для работы одного type. Предполагалось, что smart_terrain : gulag - это один ко многим. Зачем-то стали писать алгоритмы распределения работ в этот самый xr_gulag.gulag (хотя надо было в сам smart_terrain), и в итоге намудрили так, что не осилили свою же начальную идею "многогулаговости".

 

Вероятно, планировалось как-то так:

 

 

[smart_terrain]

type = gulag1, gulag2, gulag3

;capacity = 12

 

[gulag1]

;Эта секция кое-где ещё осталась в all.spawn

communities = stalker, dolg

cond = {+info1}

squad = ...

group = ...

 

[gulag2]

communities = bandit, monolith

cond = {-info1}

squad = ...

group = ...

 

 

но получилось то, что получилось.

Изменено 8 Октября 2015 пользователем Полтергейст

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

 

 

имя гулага. то самое, что gulag.name. И оно как бы, для каждого гулага уникально как мы знаем.

Я бы проверил на предмет того, откуда берётся gulag.name. Если НЕ из strn:name() (где strn - объект smart_terrain), то тогда всё понятно. Вероятно, туда каким-то образом попадает type вместо name.

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

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

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

Я делаю так - в биндере на этапе reinit принудительно очищаю все запомненные объекты через enable_memory_object, и отключаю неписям зрения (enable_vision). Включаю обратно только после того, как игра загрузилась полностью (т.е. игрок уже не видит экран загрузки). Помимо этого прописал в enemy_callback и схеме xr_danger игнорирование всех врагов и опасностей до того, как игра загрузится. Частично это помогло. Во всяком случае почти исчезли ситуации, когда никем не обнаруженный игрок сохранился где-то спрятавшись за углом, а потом загрузился и все сразу его заметили.

Насколько это влияет на это "дальновидение" - не знаю, специально не проверял, т.к. принудительный оффлайн намертво отключил. Можно ещё попробовать вызвать skip_transfer_enemy(true), но вроде бы это только для зверей...

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

Касательно допиливания smart_terrain'ов напильником. Я так думаю, лучше все работы завернуть в класс с соответствующими методами. Т.е. чтобы каждая работа была не табличкой, а объектом класса. Для объединения работ с одним "gulag type" создать ещё один класс, в который засунуть проверку условий приёма NPC и всякие атавизмы типа номерных состояний.

 

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

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

При правильном подходе толк будет.

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

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

 

Для реализации поддержки нескольких "gulag type" потребуется как-то объединять работы разных типов. Возможно потребуется делать ещё один класс, хотя можно попробовать обойтись и обычной таблицей. Если бы не было номерных состояний и списка группировок в строке communities, то этого можно было бы вообще не делать.

Изменено 20 Ноября 2015 пользователем Полтергейст

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

 

 

еще одно нагромождение совершенно не нужное, когда надо и так разгружать то что имеется

Это и будет то, что имеется, просто методы будут вызываться не из смарта, а из самой работы. Один раз при загрузке работ преобразовывать их из таблиц в объекты, объединяя при этом работы с одинаковой секцией логики в один объект. Все эти объекты занести в индексированную таблицу (которая self.Job) и в хеш-таблицу, в которой ключом будет имя секции. Вот, собственно, и всё.

 

 

 

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

А что их учитывать? Для каждого типа работ сделать промежуточный объект, в котором будет храниться вся инфа о типе работ (имя ltx и ссылка на него, ссылка на gulag_***.script, текущий state), и пропускать все обращения к gulag_***.script через него.

 

 

если ты сделаешь объединение разных типов работ, от этого резко упадет наглядность

Во избежание путаницы не использовать несколько типов работ и переключение state в одном смарте. От последнего со временем вообще лучше избавиться.

 

 

 

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

Как тогда быть с путями, логикой и именованием этих "укрытий"? Да и рельеф на других уровнях (где игрок не был ещё) вряд ли можно просчитать...

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

Чем вам не угодили стейты, почему от них надо избавляться?

Потому что вместо них можно использовать несколько gulag type. В конфиге это будет выглядеть примерно так:

 

 

[smart_terrain]
type = general_lager, esc_fabrika_bandit_normal, esc_fabrika_bandit_alarm
;больше в этой секции ничего не надо писать

[general_lager]
cond = {+esc_kill_bandits_quest_done}
;Пишем условие не для смарта целиком, а для каждого типа отдельно. Использовать вместо state.

[esc_fabrika_bandit_normal]
cond = {-esc_kill_bandits_quest_done !gulag_has_alarm}
groups = 1,2,3,4 ;это просто для примера
squads = 5,6,7,8 ;это тоже

[esc_fabrika_bandit_alarm]
cond = {-esc_kill_bandits_quest_done =gulag_has_alarm}
groups = 1,2,3,4 ;это просто для примера
squads = 5,6,7,8 ;это тоже

 

Вместо использования состояний, тип esc_fabrika_bandit разделён на esc_fabrika_bandit_normal и esc_fabrika_bandit_alarm. А general_lager здесь для того, чтобы не делать отдельный несюжетный смарт esc2_st_fabric.

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

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

 

 

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

Для отдельных NPC порядок посещения смартов определяется в секции smart_terrains из customdata. На него эти правки вообще не влияют.

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

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

Ага, и упрощение тут где? Ну против например того что я эти смарты буду спавнить тогда когда мне надо, еще до кучи учитывая сценочные уникальные смарты с их заменой на универсальный потом если надо (далеко не всегда).

Упрощение - в наглядности. С номерными state не сразу понятно, что они значат, надо их для каждой работы прописывать, надо искать, где и как они считаются. К тому же все эти 'if type == "gulag_1" then ... elseif type == "gulag_2" then' выглядят не очень красиво.

А так сразу видно, какие работы и при каких условиях доступны, всё собрано в одном конфиге. Нет разделения на несколько смартов.

 

Именно вот в данный конкретный момент для меня, когда я не смогу сидеть и переделывать все что есть под о великое.

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

 

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

Работа смарта - то же, что и раньше. То, что хранится в таблице Jobs.

Тип работы, gulag type - то, что в конфиге пишется в строке type.

 

И вот эта простыня что ниже приведена - это теперь на каждый гулаг вот такое городить?

При правильной организации самой логики (logic@что-то_там) чтобы получить такую простыню, надо очень постараться. Часть условий просто уйдёт внутрь логики. Вместо переключения gulag type будет привычное переключение секций логики персонажей. Сюжетные условия редко включают в себя что-то кроме инфопоршней, и больше двух-трех type вряд ли потребуют для себя. Те единичные случаи, где условия будут выглядеть слишком длинно и непонятно, можно засунуть в функцию в xr_conditions и вызывать оттуда.

 

И вбивать туда условия одни и те же для всех смартов?

Если там условия реально одни и те же, можно через #include ссылаться на типовые конфиги там, где это требуется.

 

писать под каждый смарт простыню конфига, под каждый gulag_type свой gulag_xxx.script

Как раз можно будет избавиться от написания loadStates и уменьшить эти самые файлы.

В принципе, можно и с checkStalker/checkMonster также поступить, но тогда или строка cond разбухнет ещё больше, или потребуется делать ещё один condlist в конфиге. Тут пока ещё есть над чем думать.

 

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

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

Изменено 23 Ноября 2015 пользователем Полтергейст

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

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

Так я об этом и пишу. Если специально не создавать на каждый чих новый gulag type с собственным condlist'ом (вместо использования логики там, где это возможно), то большой простыни из кучи секций и длинных condlist'ов не будет. И как раз получится, что вместо простыней из load_states станет достуен condlist.

 

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

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

local t = {

section = "logic@walker_1_logic",

in_restr = "level_prefix_in_restictor1", out_restr = "level_prefix_out_restictor1", 

squad = squad, group = groups[1],

predicate = function(...) return true end,

prior = 5, -- вот это руки чешутся убрать, но пока не знаю, как лучше это сделать

position_threshold = 50, -- от этого со временем тоже надо избавиться

state = {0, 1}  -- оставить обработку стейтов для совместимости, но в описании работ их стараться не использовать

}

 

 

[smart_terrain]

type = general_lager

squad = 0

groups = 1,2,3,4

capacity = 5 -- Не нужно. Ёмкость определяется количеством работ

cond = {+info1}

communities = dolg, freedom, monolith --Можно записать в виде condlist'а

 

 

[smart_terrain]

type = general_lager_normal, general_lager_alarm

 

[general_lager_normal]

squad = 0

groups = 1,2,3,4

cond = {+info1 !gulag_has_alarm}

accept_npc_cond = {=npc_community(dolg:freedom:monolith)} --вместо checkStalker/checkMonster

 

[general_lager_alarm]

squad = 0

groups = 1,2,3,4

cond = {+info1 !gulag_has_alarm}

accept_npc_cond = {=npc_community(dolg:freedom:monolith)}

 

 

Это пока набросок, тут ещё есть куда стремиться и что исправлять. В частности, возможности этих самых condlist'ов используются не оптимально, хотя и лучше, чем было.

 

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

Это подойдёт только туда, где список работ неизменен и заранее известен.

В том же gulag_general подобное не прокатит.

Изменено 24 Ноября 2015 пользователем Полтергейст

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

 

 

Вот что я не понял в звучавших предложениях - это заворачивать КАЖДУЮ работу в "псевдообъект". Подозреваю, что имелось в виду нечто иное.

Не заворачивать, а преобразовывать. Все данные из таблицы работ перекинуть в объект, потом получить имя пути и сам путь, и сохранить в объект.

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

 

 

 

position_threshold - это интересная такая штука... Смысл - надо ли в офлайне бежать к начальной точке пути.

Разве? По-моему смысл другой. В оригинале это расстояние, ближе которого в онлайне персонажу устанавливается логика (setup_logic_что-то-там). Дальше этого расстояния логика не работает. Полезность - сомнительна. Некоторые схемы могут подглючивать, если они активируются далеко от первой точки пути. Но это проблема или реализации этих схем, или криво написанной логики.

То, что отметка о начале работы (beginJob) устанавливается, можно не принимать во внимание. Просто устанавливать её при достижении первой точке пути и не заморачиваться.

 

Запретить NPC идти к месту "работы" можно или установкой object_flags, или вызовом can_choose_alife_tasks(false) (но не абы-как и абы-где), или установкой ему нулевой скорости передвижения в оффлайне. Position_treshold не влияет ни на что из этого.

 

 

 

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

Условия - это predicate что ли? Ну разве что для тех случаев, когда надо вытеснять кого-то из смарта, когда кто-то другой занял работы "с условиями"... но всё равно не вижу в этом смысла. Такой параметр больше подходит для самих работ, чтобы можно было назначить нескольким NPC одну и ту же логику, не создавая для этого несколько работ (это одна из причин для хранения работ в виде объектов, а не таблиц).

 

 

 

Кондлисты - мне не нравятся. Медленные, и читаются плохо. Лучше иметь возможность задавать явно.

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

Задавать явно возможность остаётся - написать {=вызов_функции} и в самой функции уже расписывать все подробности.

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

расстояние, при котором считается, что моб в оффлайне

Не обязательно "в оффлайне". Просто проверяется, дошёл ли. В онлайне это тоже можно наблюдать - сначала идут медленно (работает action_alife_planner), а потом с определённого расстояния немного меняет маршрут и идёт быстрее. Потому что в этот момент задействуется логика, скрипты, состояния в state_mgr.На запрет идти к месту работы в оффлайне параметр job_position_treshold вообще никак не влияет.Насчёт can_choose_alife_tasks надо смотреть исходники движка.

 

в оффлайне про логику и пути понятия не имеют

Тоже не совсем верно. В оригинальном ТЧ идут к первой точке пути, от неё же и считается расстояние, из которого делается вывод - дошёл или не дошёл. Хотя при определённых переделках скрипта можно посылать их не в первую точку, а последовательно в 1, 2, 3 и т.д.

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

@Dennis_Chikin, могу точно сказать, что по smart terrain есть ещё кучка движковых граблей.

Чтобы NPC шёл в смарт, надо чтобы все эти проверки вообще вызывались движком. А это происходит не всегда. ЕМНИП, для NPC должен быть выставлен флаг Interactive, без которого всё это работать не будет. Как минимум, в оффлайне.

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

Например, я таким образом отключал поиск смартов для "эксклюзивных" NPC, чтобы задавать им id смарта в явном виде.

 

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