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

[Kirgudu 966]

@monk, @Chriotmao прав, группировки прописываются в all.spawn. Если предпочитаешь править блокнотом, а не с помощью СДК, вот так выглядит, например, секция группировки «Бандиты»:

[...]

; cse_abstract properties
section_name = sim_faction
name = gar_sim_faction_bandit
position = -77.6989212036133, 0.972092986106873, 4.18724822998047
direction = 0, 0, 0
id = 65535
version = 124
script_version = 8
spawn_id = 5821

; cse_alife_object properties
game_vertex_id = 302
distance = 10.5
level_vertex_id = 113761
object_flags = 0xffffff3e
custom_data = <<END
[faction]
name = bandit
base_smart = gar_smart_terrain_3_5
settings = misc\faction_bandit.ltx
END

; cse_shape properties
shapes = 1
shape_0:type = sphere
shape_0:offset = 0,0,0
shape_0:radius = 1

; cse_alife_space_restrictor properties
restrictor_type = 3

; se_sim_faction properties
last_spawn_time = 255
squad_target_cache = 
random_tasks = 
current_attack_quantity = 
squads = 0

 

Изменено 15 Июня 2015 пользователем Kirgudu

[Kirgudu 966]

@monk, покажи, что именно делал. @Charsi описал достаточное решение, именно из actor_hides берётся список укрытий для актора.

[Kirgudu 966]

@alex5773, модуль inventory_upgrades.script, функция can_repair_item(...).

Должна вернуть true, если ремонт возможен, иначе false.

Также обрати внимание на функцию precondition_functor_a(...) - здесь можно настроить модернизацию в дополнение к ремонту.

[Kirgudu 966]

@Возрождённый,

1. mar_intro_zone.ltx, секция [sr_idle@scene_2_end].

2. Диалог Тропника со всеми вариантами переходов в зависимости от условий: mar_csky_guide_at_base_dialog в dialogs_marsh.xml.

[Kirgudu 966]

@Helgi, если правильно помню, все файлы squad_descr*.ltx

Только в ЧН кол-во НПС не числом задаётся, а для каждого отряда в ключе "npc = " указывается список профилей. Сколько поставишь, столько и будет.

Если помню неправильно - придёт @warwer и меня поправит.

Изменено 11 Августа 2016 пользователем Kirgudu

[Kirgudu 966]

@Helgi, отредактировать под свои нужды файл configs\scripts\marsh\mar_intro_zone.ltx, не забыв выдать все пропущенные при вырезании катсцены инфопорции.

[Kirgudu 966]

@Дизель думаю, это "yan_smart_terrain_for_squad_levsha" или какая-то из зависимых сущностей.

[Kirgudu 966]

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

Оставь последнюю строчку как в оригинале, а переменную reason выведи в лог дополнительно, вставив соотв. код до последней строки функции.

Изменено 21 Июня 2019 пользователем Kirgudu

[Kirgudu 966]

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

Тебе просто надо перед последней строкой (которая log(...)) вставить ещё одну. Какую?

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

local console = get_console()

console:execute("load ~~~ "..reason)

 

[Kirgudu 966]

@Inverter смотри в следующих файлах логики:
gamedata\configs\scripts\marsh\mar_intro_camera.ltx - движение камеры

gamedata\configs\scripts\marsh\mar_intro_zone.ltx - спавн Шрама, Лебедева и Каланчи, блокировка интерфейса и т. д.

В обоих файлах запуск катсцены осуществляется по событию {+mar_intro_start} (выдача одноимённой инфопорции при окончании стартового видео).

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

[logic]
active = nil

а во втором файле придётся пропустить несколько секций, передав управление сразу на ту, что идёт после катсцены, и при этом выдать то, что выдавалось во время катсцены при штатном течении событий:

; здесь переход на специальную добавленную секцию
[logic]
active = sr_idle@nointro

; а это сама новая секция, в которой мы делаем всё пропущенное и переходим на стадию после катсцены
[sr_idle@nointro]
on_info = sr_idle@scene_3_barman_wait_1 %+mar_intro_scene_1_end =stop_cam_effector(1) =stop_cam_effector(2) =stop_cam_effector(3) =stop_cam_effector(4) =update_weather(true) =enable_ui =give_inited_task(storyline:mar_story_talk_with_barman:csky)%

Здесь показаны только изменения, остальное содержимое остаётся как есть.

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

 

@imcrazyhoudini не то чтобы не будут существовать - не вызывают тревогу. Только там, емнип, квадрат расстояния, то есть для твоего примера это будет не 20 метров, а примерно 4 с половиной.

combat_ignore_cond = {=check_fighting(26) =enemy_gulag(yan_zombied:yan_zombied_attack)}

Тут 2 условия должны совпасть: враг со story_id = 26 должен находиться в одном из смартов yan_zombied или yan_zombied_attack. Очевидно, что-то не выполняется.

Изменено 20 Апреля 2023 пользователем Kirgudu

[Kirgudu 966]

@imcrazyhoudini в смысле чтобы требовалось выполнение любого из двух условий, но не обязательно двух сразу? Тогда логику надо переписать примерно так:

combat_ignore_cond = {=check_fighting(26)} true, {=enemy_gulag(yan_zombied:yan_zombied_attack)} true

 

[Kirgudu 966]

@imcrazyhoudini тогда, возможно, так:

; игнор, если враг имеет story_id = 26 и он не находится в двух смартах
combat_ignore_cond = {=check_fighting(26) !enemy_gulag(yan_zombied:yan_zombied_attack)}

 

[Kirgudu 966]

@!Stars! есть штатная для ЧН функция установки отношения группировки к игроку, вызывается из кучи мест в логике, например:

%=set_faction_community_to_actor(stalker:enemy)%

Разумеется, никто не запрещает при необходимости вызвать её и из скрипта:

xr_effects.set_faction_community_to_actor(nil, nil, { "stalker", "enemy" })

 

[Kirgudu 966]

@!Stars! выглядит избыточно сложно - с одной стороны. А с другой - цели в секциях expansion конфигов группировок (из первого вопроса было непонятно, что речь идёт именно о них, есть ведь и оторванные от войны группировок задания на захват смартов) выдаются автоматически симуляцией, и врезаться в них не так просто. Да, можно попробовать сделать именно так, только подумать, что именно прописать в логике смарта, какую проверку сделать до того, как запустить функцию.
Более короткая альтернатива - врезаться с условием куда-нибудь в sim_faction_brain_human.faction_brain_human:init_player_task и сделать всё на скриптовом уровне. Но тут уровень владения скриптами в целом и скриптами/логикой симуляции ВГ в частности потребуется изрядный. Войну группировок легко поломать.
Так да, всё вполне возможно.

Изменено 28 Января пользователем Kirgudu

[Kirgudu 966]

@!Stars! не могу сказать точно. С Faction Commander никогда не то что не работал, но и не использовал в игре, не хотелось и вряд ли захочется.
Проблему такую в ОГСМ, честно говоря, не особо помню, хотя в последней версии (1.8 CE) лично исправлял много ошибок симуляции. Разве что вспоминается, что для монстров, в отличие от полноценных группировок, получение и возврат секции спавна был необязателен - и то, что я сейчас вижу (но не могу с ходу объяснить), это вроде бы подтверждает...
Если всё так, достаточно в скрипте sim_faction.script в местах, предшествующих указанному вылету (там их несколько похожих), добавить проверку на то, что расчёт делается не для монстров.
См. строку 299 этого скрипта из мода ОГСМ и похожие выше, при сравнении со скриптом из оригинала (if not self.player_name == "monster" and ...).
Но я не поручусь, что данное изменение - единственное требующееся, слишком давно вносил эти правки. Надо пробовать.

[Kirgudu 966]

@!Stars! Я таких не знаю. Специалистов по ЧН мало, регулярно заходящих на форум ещё меньше, а тех, кто захочет или сможет поделиться знаниями, раз, два и обчёлся.

От меня ответа ждать не стоит, всегда интересовался больше технической стороной дела - читай, скриптами - в конфиги же предпочитаю не лезть, хоть и могу. Но если вдруг у меня возникло бы такое желание, то пошёл изучать то, что сделано до меня, в том числе и в оригинале. Поверь, инфы там вполне достаточно.
https://stalkerin.gameru.net/wiki/ - здесь ещё можно поискать, хотя почти уверен, что по ЧН мало что найдётся.

[Kirgudu 966]

50 минут назад, Купер сказал:

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

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

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

 

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

[Kirgudu 966]

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

примерами из xr_conditions и xr_effects

Ну тогда далеко ходить не надо, есть и обратный пример: cм. функцию death_manager.keep_item, вызываемую из iterate_inventory, и в ней alife():release().
Я подумал, есть запреты, связанные с высвобождением ресурсов на уровне движка, но пока это не подтверждается. Потом при случае пороюсь в плюсах.

[Kirgudu 966]

@Купер, есть штатный модуль обработки кат-сцен sr_cutscene.script, можно отредактировать в нём под свои нужды класс action_cutscene. Например, прямо туда добавить поиск нужного статика на худе, или сделать на апдейте вызов кастомного события через xr_s, а там, где статик, собственно, добавляется, подписаться на это событие - и так далее.
Но вообще это зависит от целей и сложности задачи, может пары строчек с флагом на месте вполне достаточно в конкретном случае.

[Kirgudu 966]

@Купер ничего, кроме проверки на апдейте, в голову не приходит.
При загрузке составить реестр переходов - для этого можно использовать функцию lchanger_binder:net_spawn(sobject) в bind_level_changer.script, она будет работать только для тех переходов, которые находятся на той же локации, что и герой. А дальше любым способом периодически проверять расстояние между героем и всеми зарегистрированными переходами, если какое-нибудь из них будет меньше порога - условие выполнилось.
Если интересно, можно заглянуть в fsm_anomaly.script в известном тебе моде - я в нём несколько лет назад извращался над такой проверкой с целью минимизации затрат на апдейте. Но там, конечно, избыточная сложность из-за специфической задачи.

А если речь о самом событии перехода, тогда actor_binder:save --> гейм вертекс героя --> локация по геймвертексу, которая в этом случае не равна текущей локации.