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

[Artos 99]

Gektor

Не стОит задавать вопросы, которые по сути требуют в ответе приводить многостраничную статью разъясняющую все и вся. Мало найдется тех, кто готов давать пространные ответы и единицы, кто готов писать статьи. Надеяться на их ответ ...?

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

 

 

 

Кратко пока можно дать наводки на самостоятельное изучение вопроса:

1. Помимо собственно конфига по апгрейдам (misc/stalkers_upgrade_info), основные функции размещены в 'inventory_upgrades.script'.

2. В отличии от ТЧ (SHoC) в ЗП (SCoP) движек считывает как основную секцию оружия, так и дополнительную апгрейдную, если таковая была 'выдана' механиком, т.е. уже прописана конкретному стволу (installed_upgrades).

Например, параметры того же винтореза считываются из общей (корневой) секции [wpn_vintorez] (см файл 'w_vintorez.ltx').

В этих парамерах имеется 'upgrades', в котором перечислены возможные секции апгрейдов, а также 'installed_upgrades' - уже установленные секции апгрейдов.

Если же доступна какая-либо секция апгрейда для него - дополнительно считывается секция [up_sect_ХХХ_vintorez] (см. файл 'w_vintorez_up.ltx') и параметры из нее замещают ранее прочитанные.

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

 

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

Изменено 6 Сентября 2011 пользователем Artos

[Artos 99]

Gektor

В 'природе' (в кодах оригинальной игры) нет 'таковых способов'.

Без вмещительства в скрипты, т.е. написания своих скриптов/функций тебе не обойтись.

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

[Artos 99]

Gektor

Запуская в игре диалог с механиком/ремонтником скрипты по твоей указке(!) определяют какое у тебя оружие/костюм и выдают список доступпных модификаций для тобою(!) выбранного предмета. Из этого списка апгрейдов ты уже сам(!) выбираешь какой применять.

Т.о. без твоей головы - ни что в игре не происходит 'заранее'.

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

 

Уровень накопившейся радиации у ГГ можно определить так: db.actor.radiation

0 - нет накопленной радиации (0%)

1 - максимальный уровень заражения (100%)

 

Примечание: Нужно читать ФАКи, дабы не дублировать десятки раз задававшиеся вопросы!

Изменено 6 Сентября 2011 пользователем Artos

[Artos 99]

Gektor

Исходя из твоих вопросов и умозаключений могу сказать (не желая обидеть или 'дать по рукам'):

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

2. Дело/задачу нужно выбирать себе 'по плечу', а не по похотелке. Иначе это или потерянное время тобою и другими или ты хочешь - другие делают.

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

 

Хотя раздел и называется "Школа модинга", но тут нет штатных учителей и врядли кто возьмется тебя обучать с азов.

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

[Artos 99]

karavan

Дополню ответ KD87: ... или задавать 'story_id' скриптами, используя нет-пакеты, при спавне (если сам спавнишь) или по необходимости в процессе игры.

Изменено 17 Сентября 2011 пользователем Artos

[Artos 99]

karavan

Все методы/функции из 'xr_effects.script' могут быть прописаны и в соответствующие параметры секций в конфиг-файлах логики (штатные вызовы) и вызываться из других скриптов (при правильном задании входных аргументов!).

 

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

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

'Появление' иль 'исчезновение' - каждый трактует на свой лад и конечно единой (легкой) функции нет.

Ту же бочку можно переместить куда-нибудь в ящик на время. Иль удалить на время, чтобы потом вновь заспавнить на прежнем месте. И т.п.

 

Для подобных вопросов существует топик "Скриптование ..." и требуется конкретика, дабы не заниматься погадалками о том, чего тебе захотелось.

Изменено 17 Сентября 2011 пользователем Artos

[Artos 99]

Wookie

При прицеливании изменяется значение 'fov'. Отследив это - можно выпонять требуемое. См. как убирается/показывается при прицеливании или использовании бинокля интерактивный худ 'противогазов' в том же АМК-моде.

 

Ну и ... странная трактовка 'выстрела' -> бросок болта. :-) Если на одну и ту же кнопку забиндены и выстрел и бросок иль еще чего - таки и следует говорить не о выстреле, а о 'нажатии ЛКМ'.

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

Wookie

Ты попробуй сам обдумать, что советуешь Tris'у ... Ставить выдачу кучки одних и тех же инфопоршней в апдейте актора? Это каждые ~20ms выдавать одну и ту же пачку на протяжении всей игры ... Мда-а-а.

Ставить нужно в метод 'net_spawn', дабы один раз при запуске игры:

function actor_binder:net_spawn(data)
  --/ ... прежний код
  if level.name() == "pripyat" and not has_alife_info("pri_a16_stalker_guide_met") then
    local oActor = db.actor
    oActor:give_info_portion("zat_b215_cut_guide_to_jupiter")
    oActor:give_info_portion("jup_first_meet_made") 
    oActor:give_info_portion("jup_b217_welcome_faded") 
    oActor:give_info_portion("jup_b217_welcome_guide_talked") 
    oActor:give_info_portion("jup_b217_pp_end_in_scene") 
    oActor:give_info_portion("jup_b217_welcome_tech_talked") 
    oActor:give_info_portion("jup_b217_guide_welcome_end") 
    oActor:give_info_portion("jup_b217_tech_welcome_end") 
    oActor:give_info_portion("jup_b217_tech_instruments_start") 
    oActor:give_info_portion("jup_b217_stalker_tech_met")
    oActor:give_info_portion("pri_a16_stalker_guide_met")
  end
  return true
end

 

P.S. Исправил ошибку с пропущенным 'return true' в конце.

Изменено 19 Сентября 2011 пользователем Artos

[Artos 99]

Tris

Не после, а перед заключительным 'end'. Еще точнее - перед 'return true', который я пропустил. Сорри.

[Artos 99]

SibireaStalker

По вылету "[error][ 183] : Невозможно создать файл, так как он уже существует." - или некорректный вывод в лог-файл или ищи коды стороннего мода, который пытается работать после (или в моменты) удаления объектов из игры при переходах/выходах.

Особенно грешат моды непрекращающейся обработкой коллбэков на дром предметов ...

 

Добавлено через 5 мин.:

shurik

Удалить функцию? В принципе можно.

Но зачем сложности? Или не вноси ее в коды или не вызывай ее. Какова цель удаления?

 

Приостановить функцию можно, если она является частью подпрограммы. См. метод 'coroutine' в теме "Справочник по классам и функциям".

 

Деактивировать функцию? А енто что за зверь такой? Поясни, плз.

[Artos 99]

shurik

Тебе функцию НЕ останавливать, а НЕ вызывать нужно.

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

Коды твоего вызова никто за тебя же не вырежет.

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

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

Изменено 21 Сентября 2011 пользователем Artos

[Artos 99]

Полтергейст

1. В вопросе говорится - в моменты переходов на локации или при вызоде из игры. В эти моменты лог из буфера пишется в лог-файл.

2. Не известно каким способом реализован вывод в лог у каждого модмейкера. Если с 'get_console():execute("flush")' - то вылет неизбежен сразу.

3. С фактом наиличия какого-то уже файла или правами доступа эта запись не связана. Это (ИМХО) всего лишь сообщение-заглушка движка на неидентифицированные ошибки.

 

Добавлено через 16 мин.:

abramcumner: Чем бы мне помог вотчдог в моем случае? он даже не определил бы, что вылет при выходе НПЦ в онлайн.

1. Если вспомнить - динамические аномалии пошли именно из АМК. Допущенная тобою ошибка в их кодах была бы невозможна, т.к. имеется все, чтобы чистить "аномальные" рестрикторы при уходе в оффлайн.

2. Ими (АМК) расставлены в их скрипте спавна и обработки динамический аномалий точки ватчдога.

3. Расставленные точки ватчдока позволили бы определить место сбоя.

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

(дальше уже оффтопик ...)

Изменено 22 Сентября 2011 пользователем Artos

[Artos 99]

malandrinus, спасибо за формулирование именно того, что ранее пытался высказать.

 

Предложение модераторам:

Создать тему (общую) типа: "Методы поиска ошибок в игре/модах".

Подобных тем немало, это и "Безлоговые вылеты" и темы по ошибкам в конкретных модах ...

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

 

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

Многие не подозревают о вариантах использования методов 'watchdog' (АМК) или того же Lua-перехватчика (by aplet) ...

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

В общей теме можно было бы и рассказывать об общих методах поиска ошибок и об их устранении.

Изменено 22 Сентября 2011 пользователем Artos

[Artos 99]

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

Я очень негативно отношусь ко многим статьям, которые дают зачастую только однобокое толкование в достаточно узком/частном случае.

Для поиска ошибок невозможно (ИМХО) написать статью, т.к. она либо будет куцей и оставит еще больше вопросов, либо будет частной, годящейся для конкретной реализации кодов.

Да и наличие "учебников" не делает ненужным общение как с "учителями", так и с себе подобными ...

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

Ну и неактивность - не смертельный недостаток. Не будет востребована - уйдет в отвал как немало уже ушло иных ... или уйдет (см. "[soC] Вылеты без лога, Некоторые соображения").

[Artos 99]

karavan: ... как сделать что бы НПС в скваде не переходил в оффлайн?

KD87: ... переводите непись в оффлайн, переписываете ему нет-пакет, заменяя object_flags. Из object_flags убираете флаг flCanSwitchOffline.

karavan: Но как это сделать? Я с нет пакетами не работаю вообще. ... объясни пожалуйста, как это можно реализовать?

1. Берешь готовый скрипт/функции для работы с нет-пакетами в SCoP, например, 'm_net_utils.script';

2. Получаешь по какому-либо признаку (ID, story_id, ...) серверный объект своего НПС (soNPC);

3. Считываешь нет-пакет своего объекта (tP);

4. Меняешь в этом пакете значение параметра 'object_flags' на требуемое, т.е. сбросив, как советует KD87 флаг ' flCanSwitchOffline';

5. Перезаписываешь нет-пакет своему НПС;

6. Для подстраховки, переводишь своего NPC в оффлайн и обратно.

Все это конспективно примерно так:

function Set_Always_OnLine(idNPC) --/< на входе игровой ID
  local soNPC = idNPC and alife():object(idNPC) --/ серверный объект НПС
  if soNPC and IsStalker(soNPC) and m_net_utils then --/ проверки готовности/возможности
    local tP = m_net_utils.Get_Data_Stalker(soNPC) --/ читаем нет-пакет
    tP.object_flags --/ меняешь параметр на нужное значение
    m_net_utils.Set_Data_Stalker(tP,soNPC) --/ сохраняем измененный нет-пакет
    if level.object_by_id(id) then --/ если объект в онлайне:
      --/ тут перевод online->offline->online
    end
  end
end

Остается найти требуемые скрипты/функции для нет пакетов и переводов 'офф-он-лайн' и попросить KD87 уточнить в 'object_flags' бит 'flCanSwitchOffline'.

 

 

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

[Artos 99]

PUNK-398

Для игры не важен из какого архива и каким по очереди был загружен тот или иной ресурс. Всегда будет в игре тот, который загружен был ПОСЛЕДНИМ.

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

Порядок же чтения определен движком:

- первыми читаются пак-файлы gamedata.db*. Читаются в том порядке который определяется символом(ами) '*';

- далее читаются файлы из 'распакованной' папки '\gamedata', затирая все те файлы, которые были прочитаны ранее;

- последними читаются файлы из пак-файлов *.xdb* из папки '\mods'. Чтение проихводится также в 'алфавитном' порядке.

 

Т.о. если хочется, чтобы твои ресурсы грузились первыми - упакуй их в gamedata.db0. Но(!) врядли они не будут затерты последующими ...

Если же хочется, чтобы твои ресурсы имели приоритет над всеми ранее загруженными - пакуй в пак-файл типа 'z.xdb' и клади архив в папку '\mods'.

[Artos 99]

PUNK-398

Сорри, что дал ответ по дефолтно сидящему в мозгах SHoC.

Для ЧН/ЗП аналог \mods -> \patches, ну и имена - *.db

 

И не заблуждайся, игра/движек грузит (распаковывыает) все ресурсы игры ДО того, как определяется собственно текущая локация.

Т.е. управлять на стадии загрузки потребными ресурсам не представляется возможным. Только для версий all.spawn'а есть ключики в командной строке запуска.

Изменено 9 Октября 2011 пользователем Artos

[Artos 99]

PUNK-398

Ну ответ то очевиден с учетом ранее изложенного:

Запаковать ресурсы в xpatch_##.db и положить в \patches.

Символы '##' - таковы, чтобы этот файл в 'алфавитном' порядке шел после имеющихсся (например xpatch_09.db, учитывая что имеются только до 02).

Изменено 9 Октября 2011 пользователем Artos

[Artos 99]

PUNK-398

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

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

Сделав нужные батники (под каждый уровень) ты из набора заранее заготовленных xpatch_##.db сможешь выбирать и копировать нужный в данный момент.

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

[Artos 99]

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

Не совсем верно. Во многих модах на базе АМК используются и скрипты из АМК, но более правильно было бы говорить об алгоритме спавна 'динамических' аномалий (по рандомным координатам). Например в OGSE и SIMBION'e схожие алгоритмы, но значительно измененные скрипты.

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

 

Как верно заметили KD87 и Scarabay, обязательности спрашивать разрешения на использование публично опубликованных материалов модов в которых НЕ оговорены условия использования этих модов/материалов, не требуется. Исключение могут составлять коммерческие проекты ...

Упоминание/ссылки в своей работе на авторство использованных материалов - это и соблюдение прав авторства и дань уважения.

 

Forestskif: Предел мечтаний - это аномалии, которые меняют свое положение после каждого выброса и которые видят и обходят НПС

Хотел бы обратить внимание, что в ЗП (SCoP) оригинальные аномалии имеют совершенно иной тип (это в основном поля torrid, а не одиночные как ЧТ).

Так же, для НПС эти аномалии невидимы и не причиняют никакого вреда.

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

Изменено 14 Ноября 2011 пользователем Artos