STALKER CS: Final stroke 0.9

[Kirgudu 1 308]

- Как прописать спавн "Ренегатов" и "Компаса" в шахте РЛ, только после посещения ГГ Кровососовки?

 

Пример спавна компаса с учётом условий:

; cse_abstract properties
section_name = af_compass
name = red_af_compass
position = -159.314117431641,3.38507390022278,-30.3501319885254
direction = 0,0,1.99999999495049e-006

; cse_alife_object properties
game_vertex_id = 961
distance = 0
level_vertex_id = 27072
object_flags = 0xffffff0b

;--/ начало вставки
custom_data = <<END
[spawner]
cond = {+red_forester_search_compas_task}
END
;--/ конец вставки

story_id = 517

; cse_visual properties
visual_name = dynamics\artefacts\af_compass

; cse_alife_item properties
condition = 1

upd:num_items = 0

 

 

 

Спасибо! monk

[Kirgudu 1 308]

Можно ли на уровне скриптов вообще ликвидировать возможность ухода денег в минус?

Можно, почти любая передача денег в игре делается с помощью метода dialogs.relocate_money, который несложно поправить, чтобы он не отдавал больше, чем есть.

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

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

По-хорошему, эту проблему надо решать в связке. Поправить dialogs.relocate_money так, чтобы он не уводил наличность в минус, а для каждого места в диалогах, логике, скриптах и т. п., где происходит передача денег от героя к НПС, писать дополнительные методы проверки наличности, которые будут в принципе запрещать дальнейшие действия, если её не хватает.

Изменено 1 Ноября 2013 пользователем Kirgudu

[Kirgudu 1 308]

Да куда вы этот скрипт добавите? В апдейт биндера? Перед апгрейдом? Ещё на какое-нибудь событие?
Да, так уберёте отрицательные величины. Но это не избавит от алогичности того, что герой вообще смог уйти в минус, а значит получил какую-то условно услугу за меньшую стоимость, чем должен был.

Только комплексный подход.

[Kirgudu 1 308]

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

function update()
local actor=db.actor
if (actor) then
local money=actor:money()
if (money<0) then
actor:give_money(-money)
end
end
end

 

 

[Kirgudu 1 308]

Заменить имеющиеся аналогичные функции.

function effect_functor_a( param2, section, loading ) --( string, string, int )
    if loading == 0 then
        local price = char_ini:r_u32(section, "cost")
        local money = db.actor:money()
        if money < price then price = money end
        xr_statistic.inc_spent_money_counter(price)
        db.actor:give_money(price*-1)
    end
end

function effect_repair_item( item_name, item_condition ) --( string, float )
    if mechanic_name ~= "kat_cs_commander" then
        local price = how_much_repair( item_name, item_condition )
        local money = db.actor:money()
        if money < price then price = money end
        xr_statistic.inc_spent_money_counter(price)
        db.actor:give_money(price*-1)
    end
end

 

Возможность обычной починки определяется дополнительно другой функцией, и если у героя меньше денег, чем нужно, починить предмет ему просто не дадут.
А вот в случае починки обновременно с апгрейдом починка в случае недостатка денег обойдётся дешевле (можно считать, что герою дана скидка) или вообще бесплатно, если наличности имеется только на апгрейд. Но в минус деньги не уйдут.
Проверять наличие средств одновременно и для апгрейда и для починки не получится, так как соответствующие функции вызываются движком независимо друг от друга и принимают недостаточные для объединённой проверки аргументы.

 

Попробовал этот вариант - работает. Думаю на этом и остановиться. Большое спасибо за помощь. monk

[Kirgudu 1 308]

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

 

Заменить в файле dialogs.script соответствующие 3 блока по 3 функции с аналогичными именами (начинаются примерно со строки 450):

 

--------------------------------------------------------------------------------
function transfer_any_pistol_from_actor(first_speaker, second_speaker)
	local npc = who_is_npc(first_speaker, second_speaker)
	db.actor.pistol = nil
	db.actor:iterate_inventory(is_pistol, npc)
	if db.actor.pistol ~= nil then
		db.actor:transfer_item(db.actor:object(db.actor.pistol), npc)
		news_manager.relocate_item(db.actor, "out", db.actor.pistol)
		db.actor.pistol = nil
	end
end

function is_pistol(npc, item)
	local section = item:section()
	if(section=="wpn_beretta")
	or(section=="wpn_colt1911")
	or(section=="wpn_aps")
	or(section=="wpn_desert_eagle")
	or(section=="wpn_fort")
	or(section=="wpn_hpsa")
	or(section=="wpn_tt33")
	or(section=="wpn_pb")
	or(section=="wpn_pm")
	or(section=="wpn_gsh18")
	or(section=="wpn_usp")
	or(section=="wpn_walther")
	or(section=="wpn_fn57") then
		db.actor.pistol = section
	end
end

function have_actor_any_pistol(first_speaker, second_speaker)
	local npc = who_is_npc(first_speaker, second_speaker)
	db.actor.pistol = nil
	db.actor:iterate_inventory(is_pistol, npc)
	return db.actor.pistol ~= nil
end

--------------------------------------------------------------------------------
function transfer_any_gun_from_actor(first_speaker, second_speaker)
	local npc = who_is_npc(first_speaker, second_speaker)
	db.actor.gun = nil
	db.actor:iterate_inventory(is_gun, npc)
	if db.actor.gun ~= nil then
		db.actor:transfer_item(db.actor:object(db.actor.gun), npc)
		news_manager.relocate_item(db.actor, "out", db.actor.gun)
		db.actor.gun = nil
	end
end

function is_gun(npc, item)
	local section = item:section()
	if(section=="wpn_abakan")
	or(section=="wpn_ak74")
	or(section=="wpn_ak74_priklad")
	or(section=="wpn_ak101")
	or(section=="wpn_ak108")
	or(section=="wpn_akm")
	or(section=="wpn_ak74u")
	or(section=="wpn_groza")
	or(section=="wpn_sig550")
	or(section=="wpn_sig220")
	or(section=="wpn_fn2000")
	or(section=="wpn_g36")
	or(section=="wpn_l85")
	or(section=="wpn_lr300")
	or(section=="wpn_mp5")
	or(section=="wpn_ump45")
	or(section=="wpn_rpk")
	or(section=="wpn_val")
	or(section=="wpn_vihr")
	or(section=="wpn_vintorez") then
		db.actor.gun = section
	end
end

function have_actor_any_gun(first_speaker, second_speaker)
	local npc = who_is_npc(first_speaker, second_speaker)
	db.actor.gun = nil
	db.actor:iterate_inventory(is_gun, npc)
	return db.actor.gun ~= nil
end

--------------------------------------------------------------------------------
function transfer_any_shootgun_from_actor(first_speaker, second_speaker)
	local npc = who_is_npc(first_speaker, second_speaker)
	db.actor.shootgun = nil
	db.actor:iterate_inventory(is_shootgun, npc)
	if db.actor.shootgun ~= nil then
		db.actor:transfer_item(db.actor:object(db.actor.shootgun), npc)
		news_manager.relocate_item(db.actor, "out", db.actor.shootgun)
		db.actor.shootgun = nil
	end
end

function is_shootgun(npc, item)
	local section = item:section()
	if(section=="wpn_bm16")
	or(section=="wpn_bm16_full")
	or(section=="wpn_toz34")
	or(section=="wpn_wincheaster1300")
	or(section=="wpn_spas12")
	or(section=="wpn_saiga") then
		db.actor.shootgun = section
	end
end

function have_actor_any_shootgun(first_speaker, second_speaker)
	local npc = who_is_npc(first_speaker, second_speaker)
	db.actor.shootgun = nil
	db.actor:iterate_inventory(is_shootgun, npc)
	return db.actor.shootgun ~= nil
end

 

 

Заодно рекомендую в функциях is_pistol, is_gun и is_shootgun проверить и при необходимости исправить списки, соответственно, пистолетов, автоматов и ружей, которые могут быть отданы брату Волка.

 

Upd: исправил синтаксическую ошибку в функции is_shootgun.

 

Спасибо, всё работает, как и должно. monk

Изменено 13 Ноября 2013 пользователем monk

[Kirgudu 1 308]

Со своей стороны выкладываю правки ошибок в текстах для сборника фиксов.

 

Применять эти правки я всем рекомендую с осторожностью.

Dimus, не сочти за наезд! Подробности личкой.

[Kirgudu 1 308]

Обновил шапку темы. Поправил ссылку на сборник (из-за затесавшихся спец. символов на сборник не вела).

[Kirgudu 1 308]

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

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

[Kirgudu 1 308]

@monk, когда появишься, напомни мне дать тебе правку по голосу убитого Левши.

Или просто в файле yan_sound_play_restr.ltx пропиши это:

[sr_idle@otryad_go_home]
on_info = {+yan_otryad_go_home_cut6 -yan_levsha_dead} sr_idle@stop %=play_sound(yan_squad_assemble:stalker:yan_st_levsha_name)%

а в yan_scene_6_stalker_5.ltx на всякий случай это (хотя такая настройка уже есть для содержащего Левшу сквада):

[logic@levsha]
;...
on_death = death

[death]
on_info = %+yan_levsha_dead%

[Kirgudu 1 308]

Ловите.
https://yadi.sk/d/jsab6xtbXFgfw

База ЧН исключена для всех, кроме проводников ЧН. Только надо проверить.

Upd: файл обновил из-за опечатки.

Изменено 24 Июля 2014 пользователем Kirgudu

[Kirgudu 1 308]

@Dimus, есть подозрение, что игра зависает при выбросе только на Болотах, причём не в самый первый раз у наблюдательной вышки. Это так?

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

[Kirgudu 1 308]

@Dimus, я имел в виду исключительно локацию (Болота в целом) и время (любой выброс, кроме первого в начале игры), конкретное место не имеет значения.

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

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

[Kirgudu 1 308]

Мм... выложу здесь, чтобы в случае работоспособности правки monk смог бы включить её в сборник.

Вот ссылка: https://yadi.sk/d/kpyLrh4mZVc4z

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

И всё-таки проверь заодно выброс не на Болотах и без этой правки.

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

[Kirgudu 1 308]

Дело в том, что таймеры в OGSM (да и во всех остальных модах до какого-то момента) основаны на 32-разрядном счётчике, который может достигать максимального значения 2147483647 миллисекунд или около 25 суток игрового времени. Даже перезапуск таймеров по достижении этого значения не гарантирует того, что всё пойдёт правильно и дальше - это зависит от конкретной скриптовой реализации, а она в OGSM, прямо скажем, неважнецкая. Да-да, это и в мой огород камень, но 2 с лишним года назад у меня не было тех знаний по скриптованию Сталкера, что есть сейчас (да и это не предел).

 

Современное модостроение предполагает использование уже 64-разрядного счётчика, которого хватит на все мыслимые периоды времени. Такой счётчик, в частности, был реализован в HWM, основанном на OGSM. Но там применено решение, которой в вашем случае будет избыточным.

 

Я могу сделать для данного сборника упрощённый вариант таймеров с 64-разрядным счётчиком, но это потребует полного тестирования игры от начала до самого конца и дальше во фриплей, включая все зависимые от таймеров компоненты - сон, голод, радиацию, поедание продуктов и выпивание напитков, выпивание водки с Холодом из диалога в начале игры, периодический выброс, использование аптечек, бинтов, йадулина и антирада, использование музыкальных инструментов, использование рации, автосохранение, респавн монстров (не тех, что в группировке, а специально введённых, типа зомби или, скажем, кровососа у ж/д на Кордоне), обновление редких товаров и новости об обновлении, повреждение брони, снимаемой с трупов при мародёрстве - всё это и, возможно, что-то ещё, что я забыл перечислить, зависит от таймеров, и всё это надо будет проверять.

 

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

 

А с выбросом... Мне кажется, идеальным было бы реализовать не смерть Шрама от выброса, а потерю сознания и телепорт в ближайшую безопасную точку, можно с одновременным уменьшением здоровья, как это сделано в начале игры при первом выбросе на наблюдательной вышке. И не важно, что рядом не будет Лебедева или сотрудников ЧН - спасти Шрама, принести его к людям и затем уйти по своим делам мог кто угодно. Зато слова Каланчи о том, что Шрам устойчив к выбросу (хоть и с постоянной деградацией этого свойства), получили бы также и полное игровое подтверждение. Подумайте об этом.

[Kirgudu 1 308]

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

 

По поводу выброса: тут @warwer в частной беседе высказал мнение, что устойчивость Шрама нивелирует важность выброса в принципе. Можно будет спокойно заниматься своими делами, а потом, очнувшись, пойти дальше. Вот если сделать потери от выброса (любого рода) весьма ощутимыми - тогда да. Но что может сравниться с гибелью и заставить игрока всё-таки искать укрытие, а не покуривать, глядя на надвигающийся апокалипсис? Так что не торопитесь, подумайте ещё, обсудите. Я всего лишь выдал вам предложение, которое пока, получается, не подкреплено существенными доводами.

[Kirgudu 1 308]

@Dimus, таймеры из HWM не подойдут, так как они тесно переплетены с расширенным хранилищем игровых данных в сэйвах, а интегрировать ещё и хранилище не хотелось бы, так как это однозначно приведёт не только к необходимости новой игры, но и к продолжительным тестам с моей стороны, на что я сейчас не способен.

Упрощённый вариант для OGSM выложу чуть позже.

[Kirgudu 1 308]

Разумеется, процентного. Причём можно начать с какой-то величины, скажем 50% шанса, что Шрам выживет при третьем выбросе (если считать за первые два те, что были в начале игры), запоминать её, а с каждым следующим выбросом понижать на 5%, то есть при четвёртом выбросе шанс выживания составит 45%, при пятом - 40%, и так далее. Таким образом получит жизнь ещё одно утверждение Каланчи о том, что с каждым выбросом уникальная особенность Шрама слабеет. Начальный шанс на выживание и его дельту по времени можно подобрать, исходя из игровых предпочтений и средней длительности одной игры (предположим, к моменту прихода на ЧАЭС выброс должен приводить к +-100% смерти).

Плюс, естественно, другие пенальти - здоровье, поломанные вещи и т. д. по списку.

[Kirgudu 1 308]

Держите 64-разрядные таймеры: https://yadi.sk/d/CD3HIfiTZcMZA

Сам проверить не могу вообще никак, надежда на вас. Если будут какие-либо ошибки - сразу лог сюда или мне в личку.

Данный комплект предназначен для последней выложенной версии сборника от 12.07.14, ссылка на которую есть в шапке. Использовать вместе с чистым OGSM крайне не рекомендуется.

Новая игра теоретически не требуется, постарался сделать таким образом, чтобы старые таймеры автоматически преобразовались в новые при загрузке. Однако сохранение должно быть сделано до критического момента, в первые 25 дней игрового времени. Если 32-разрядный счётчик уже был перезапущен один раз, автоматическое преобразование даст неверные настройки 64-разрядных таймеров.

 

 

 

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

Может не хватить денег на починку. И даже если хватит - как потом воевать во время второго выхода, если снарягу не купить?

[Kirgudu 1 308]

@Max Warlock, не нужно изобретать велосипед.

Автосейв давным-давно повешен на таймер, только там стоит не 5-7, а 3 секунды таймаута после захода на локацию. Работы там на 5 секунд - поменять одно число на другое всего в одном месте упомянутого тобой скрипта ogsm.script (480 строка оригинального файла OGSM и 546 строка файла из выложенной мной сегодня правки таймеров).

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

 

===========================

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

Ссылка: https://yadi.sk/d/Ap_Y4FUaZg3Dw

Скрипт совместим с правкой, выложенной мной ранее здесь.

 

Пока сделал по-минимуму. Особенности:

1. Отсчёт начинается с третьего выброса (то есть пропущены 2 сюжетных выброса в начале игры).

2. Начальный шанс выживания Шрама составляет 50%. С каждым следующим выбросом шанс снижается на 10%, то есть при четвёртом выбросе Шрам выживет с 40% вероятностью, при пятом - с 30%, и так далее. Восьмой проведённый вне укрытия выброс однозначно повлечёт за собой смерть протагониста. Такой шаг сделал сейчас специально, чтобы протестировать можно было относительно быстро.

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

4. После выброса, в котором Шраму посчастливилось выжить, задание «укрыться» приобретает статус «провалено».

 

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

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

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