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

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


Halford

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

@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

 

Изменено пользователем Kirgudu
  • Спасибо 1

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


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

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

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

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

  • Спасибо 1

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


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

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

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

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

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


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

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

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

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

Изменено пользователем Kirgudu
  • Спасибо 1
  • Согласен 1

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


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

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


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

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

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

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

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


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

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

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

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

local console = get_console()

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

 

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


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

@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. Очевидно, что-то не выполняется.

Изменено пользователем Kirgudu
  • Спасибо 2
  • Полезно 1

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


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

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

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

 

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


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

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

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

 

  • Спасибо 1

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


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

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

%=set_faction_community_to_actor(stalker:enemy)%

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

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

 

  • Нравится 3

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


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

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

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

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


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

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

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


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

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

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

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


Ссылка на сообщение
50 минут назад, Купер сказал:

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

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

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

 

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

  • Спасибо 1

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


Ссылка на сообщение
6 минут назад, WinCap сказал:

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

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

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


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

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

  • Спасибо 1
  • Полезно 1

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


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

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

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

  • Полезно 1

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


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

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