RayTwitty
-
Число публикаций
1 241 -
Регистрация
-
Последнее посещение
-
Дней в топе
6 -
AMKoin
2,439 [Подарить AMKoin]
Весь контент пользователя RayTwitty
-
Подумалось, чтобы сократить количество телодвижений при интеграции и установке конвертера. В обычном случае: задать путь до СДК в fsconverter.ltx и поменять (при необходимости) версию спавна декомпилируемого уровня. Хотя, возможно автор изначально при разработке думал о бОльшей автономности проги от СДК. Немного разные подходы. В идеале для дефолтной декомпиляции вообще отказаться от профилей - брать пути из $sdk_root$, а версию спавна задавать отдельным ключом прямо в команде (по дефолту оставить ТЧ, как младшую релизную версию). Там для ЧН\ЗП есть дополнительные настройки по материалам, не получится... Наверно да, не стоит свеч.
-
@WolfHeart я так понял, что ключ (пример) как раз таки задает использование нужного профиля где описаны различные костыли для декомпиляции (замена одних шейдеров на другие и т.п.), чтобы старый уровень нормально отображался в релизном СДК. Вообще, первая мысль была, что для декомпиляции старого уровня, в СДК нужно положить сам уровень, а также его текстуры, шейдеры и прочее. Профили видимо нужны для удобства, чтобы не тащить хлам с разных билдов в директорию СДК. Если ключ (профиль) в команде не задан, то используется default (default = 2947_config). В этой секции указаны только абсолютные пути до ресурсов и версия спавна. P.S. Так как в большинстве случаев конвертер используется просто для ТЧ-ЧН-ЗП СДК, я бы наверное где-то хардкодом прописал, что если для default явно не указаны пути, то использовать путь из $sdk_root$ (из него можно получить $game_data$ и $game_levels$). И получится, что в секции default нужно будет указать только версию спавна (по умолчанию например ТЧ). P.S2. Там есть также секция sdks, назначение которой пока неизвестно.
-
Вопрос по поводу профилей в converter.exe (https://github.com/abramcumner/xray_re-tools и другие форки). Файл converter.ini, в нем куча профилей для различных версий игры включая билды. Для чего нужны эти профили? Отладочная штука? Очень давно, когда настраивал конвертер (еще в 2012 году), менял абсолютные пути в секции 2947_config до СДК-ашных, сейчас задался вопросом - а нужно ли, если мы итак указываем путь $sdk_root$ в fsconverter.ltx? Использую конвертер только для финалки ТЧ (СДК 0.4).
-
Кстати да, у Непряхина довольно годные мануалы, сам смотрел некоторые его ролики, довольно подробно и понятно. Раньше такого даже близко не было, разбирались методом тыка на форуме. Ну а вопрос с ютубом... Половина интернета исписана на эту тему, есть 1001 способ решения. Там я просто батники уже готовые создал на все случаи жизни, в стандартном исполнении был только сам exe-шник. + Сам юзаю. В репаке, кстати нужно бы обновить конвертер, а то там за 2012 год по-моему...
-
@den_z level_prefix по идее никак не может влиять на это. Это просто префикс в названии для удобного поиска объектов, задается в СДК в настройках уровня. Там где не задан - подставляется заглушка "level_prefix_". У двустволки должен быть свой класс. Как в конкретном АСДС обозвали не в курсе, но что-то вроде cse_alife_item_weapon_bm16. У всех этих трех классов разная механика перезарядки и работы. Может быть дело и этом. Вообще, в любой непонятной ситуации, если что-то не получается и не знаешь в чем причина - нужно искать примеры в оригинальной игре, как делали разработчики. Копировать, а потом уже смотреть, что изменить под себя. Там может быть далеко не один флаг. И комментарии в файле должны быть как в конфигах ";", а не в lua-стиле. enum { flUseSwitches = u32(1) << 0, flSwitchOnline = u32(1) << 1, flSwitchOffline = u32(1) << 2, flInteractive = u32(1) << 3, flVisibleForAI = u32(1) << 4, flUsefulForAI = u32(1) << 5, flOfflineNoMove = u32(1) << 6, flUsedAI_Locations = u32(1) << 7, flGroupBehaviour = u32(1) << 8, flCanSave = u32(1) << 9, flVisibleForMap = u32(1) << 10, flUseSmartTerrains = u32(1) << 11, flCheckForSeparator = u32(1) << 12, };
-
Отключить привязку к АИ-сетке - флажок use AI locations в движке\СДК. object_flags = 0xffffff07 Вот тут один из битов. Можно попробовать просто скопировать значение похожих по классу объектов, вроде патронов или гранат. P.S. Вот флажки Грозы в бачке унитаза брейн-лабы: object_flags = 0xffffff0f попробуй их.
-
[SoC] Ковыряемся в файлах
RayTwitty ответил на тему форума автора Halford в Скрипты / конфиги / движок
В lua (в сталкере) в 99% случаев приведение типов работает корректно, поэтому условие сработает как обычное булевое. Ну а чтобы проверить проигрывающий партикл, да, этот метод и ссылка на собственно партикл (а без ссылки его и не будет, сборщик мусора же). Кстати, в приведенном примере по ссылке ситуация странная - код есть в оригинале, но проблем никогда не было. Да и "он выполняется на каждом обновлении биндера", на самом деле нет, там выше стоит флажок, код под ним выполнится только на первом апдейте. Впрочем, от доп. проверки хуже ему не станет. -
Просто для понимания - префиксы - сокращение от типа объекта, для которого работает схема. ph - physic object, sr - space restrictor (не исключены другие типы). Разница в том, что у физ. объекта есть кости, от которых можно играть звук + объект может двигаться. Рестрикторы не имеют шейпа (модели) и они статичны, поэтому звук играет просто на точке спавна. То есть, к субтитрам оно вряд ли имеет отношение. Нужно смотреть то, что играет в голове ГГ.
-
my.script local var_A = 5 -- область видимости: только внутри скрипта var_B = 5 -- область видимости: по имени модуля my.var_B (если нужна пустота по умолчанию, явно указываем var_B = nil, иначе не пройдет по синтаксису) _G.var_C = 5 -- область видимости: везде
-
@den_z телепортация - это всегда метод set_actor_position. Все остальное - дебри конкретной реализации. На Арене насколько я помню был облет камеры. На его окончание обычно вешается телепорт. Скорее всего схема sr_cutscene.
-
@den_z если лога нормального нет, сложно сказать в чем проблема. Я вроде бы тогда мод на 4 патче разрабатывал, адаптацию 6-ки дальше Кордона не тестировал... Но я не помню, чтобы за эти годы (десятилетие!) кто-то жаловался. Еще могу посоветовать перепроверить версию Солянки, а также порядок установки. Адаптация под 1.0006 патч в инсталляторе мода уже включает в себя адаптацию самой Солянки. То есть по итогу у нас не должно быть в папке gamedata почти никаких файлов (кроме, вроде бы пары файлов в конфигах, которые нужны для работы кейлоггера). Та версия, на которой я разрабатывал есть в шапке. Оригинал нужной версии НС, с оригинальными же флешками. Нейминг игровых архивов, в которые запакована Солянка сделан не просто так - он как раз подходит под DMX MOD (его файлы имеют бОльший приоритет). Файлы из папки Опции ставить нельзя, это всё для чистой Солянки.
-
Это неверно, тебе нужен асинхронный вызов с условием появления объекта, @Купер уже все правильно написал. Просто отсрочка по времени может не сработать по тем или иным причинам (например в связи с низкой производительностью), да и задержка в секунду явно много - при открытом инвентаре ты буквально будешь наблюдать самопроизвольный "полет" предмета в слот. Вообще, подобного рода вопросы (действия с объектами при выходе в онлайн) уже баян, причем очень давний.
-
Вопрос не в скорости (сравнение строк всегда медленнее, чем сравнение чисел), а в логике. Если когда-либо добавится новый ящик с другой секцией (vasya_box например), то тебе придется править все скрипты, логика которых завязана на имя секции. Проверка класса этот вопрос закрывает. Впрочем, если и добавляют какие-то спец-ящики, то для технических целей - их нельзя заюзать, соответственно обрабатывать событие нет нужды. Короче говоря, если логика работы позволяет проверить класс объекта, а не секцию, то надо проверять класс.
-
[SoC] Ковыряемся в файлах
RayTwitty ответил на тему форума автора Halford в Скрипты / конфиги / движок
Если кучей что-то спавнится в одной точке, то оно может улететь под террейн. Возможно ЛР-ка в силу своих особенностей и размеров шейпа, физически не вступает в конфликт с другими предметами. Можно попробовать заспавнить все предметы не на землю, а в рюкзак и потом выкинуть вручную: alife():create("flamethrower_bad",pos,lv,gv,0) 0 - айди актора. А вот то, что странно. А точно там еще чего-нибудь не поменялось? Точно ничего не упустили? -
or item:clsid() == c_projector or item:clsid() == clsid.inventory_box then У тебя какие-то правленные скрипты судя по всему. Все зависит от того, есть ли методы проверки артефакта на поясе или колбек на перемещение на пояс\в рюкзак с пояса. В ЗП не помню, что есть, а чего нет. Если этого всего нет, то придется реализовывать руками, примерно как выше сказали. Есть готовые реализации определения предметов на поясе, им уже лет 15. Я бы их немного изменил, добавив запись информации о появлении артефакта на поясе в серверный объект (там же, где реализовано "проявление" артефактов Лунный свет ночью). Проще говоря - если сейчас артефакт на поясе и не заполнено поле в серверном объекте, то это будет маркер появления артефакта на поясе и оно же время. Для всех остальных артефактов поле обнуляем. А уже потом, в нужных местах просто берем текущее время и отнимаем записанное - получаем искомую разницу.
-
Ну так правильно - на предыдущей локации выдаешь инфо, на новой локации проверяешь и удаляешь. Можно еще по идее и в pstor актора сохранить флажок, чтобы с поршенами не возиться.
-
@Баба ЯГА в bind_physic_object.script замени одну строчку if not ini or not ini:section_exist("logic") then -> if (not ini or not ini:section_exist("logic")) and obj:section() ~= "inventory_box" then Если несколько секций ящиков, для которых нужен биндер, то добавляй аналогично: ... and obj:section() ~= "m_inventory_box" P.S. В игре сотни, если не тысячи физ. объектов, если на каждый вешать по биндеру и прочую логику, можно повесить игру. Поэтому сделали ограничение, что биндим только объекты с логикой. Там кстати ниже прожекторы выводят из под этого ограничения, наверно правильнее по классу проверить ящик, чем тут по секциям. if obj:clsid() ~= clsid.projector and obj:clsid() ~= clsid.inventory_box then Хотя работать должно одинаково.
-
Это все дебаговые возможности современных движков, разумеется в моде 2012 года такого еще не могло быть. Как альтернатива первому, возможно адаптировать следующее - https://www.playground.ru/stalker_call_of_pripyat/file/s_t_a_l_k_e_r_call_of_pripyat_polyoty_na_klavishu_v-1644044 Можно оставить как есть или повесить на уже готовый перехватчик клавиш в keylogger.script (function vk86() будет кнопка V и ее нужно прописать в config\keys.cfg по аналогии с остальными).
-
@Norman Eisenherz если важно получить время, то скорее всего без правок движка никак. Или хотя бы расширить кастрированные луашные пространства имен ("лайтовые правки движка") - io, os и т.д. Вроде давно были эти библиотеки внедренные в xrLua.dll или проброшенные туда, без правки основного движка (xrGame.dll, .exe etc). Суть наводки - может быть можно будет получить текущее время системы в мс и уже это ловить на сталкерском апдейте вместо time_global().
-
Сам реализуешь же. На каждом апдейте сдвигаешь скролл на определенный шаг, по сути это и есть скорость. Расстояние - разница между текущим и предыдущим положением, хотя может это вообще не понадобится, зависит от того как напишешь. Единственный тонкий момент, как уже выше писали, учесть FPS. Еще может быть каких-то скриптовых методов не экспортировано, никто же не знает чистый у тебя движок или нет. Если нет, то вообще лучше в движке сразу сделать и не мучаться.
-
@Norman Eisenherz 3 дня выясняли что не так с апдейтом, почему он не работает, даже в игру полез проверять, как оказалось, что все работало, а дело совсем в другом Я же об этом еще в этом посте спрашивал... Значит кури класс CRenderDevice - https://www.amk-team.ru/forum/topic/7450-spravochnik-po-funkcijam-i-klassam/?do=findComment&comment=272244 time_global()\device().time_global() в меню использовать смысла нет, пробуй другие счетчики, например device().frame, а дельта между кадрами device().f_time_delta (у меня тоже нулевая, но я дальше главменю не загружал). Работу всего этого можно тестить с включенным vsync, залочит на 60 кадров, без него будет улетать на сотни-тысячи, разницу в показаниях видно будет сразу, "другой ПК" не нужен. P.S. Вопрос риторический - зачем считать время (его мы не получим), если можно считать скорость и расстояние (скролла)? Единственное, как учесть FPS, но это см. выше.
-
@Norman Eisenherz у меня следующий код работает без проблем в главном меню: function main_menu:Update() CUIScriptWnd.Update(self) log("main_menu:Update") end Как при выгруженной игре, так и при загруженном сейве апдейт не останавливается. Так что все должно быть норм. Подразумевалось, что этот баян (16 летней давности) уже известен и у тебя есть функция на замену для вывода данных (там же комментарий написан). Выводи любым способом, да хоть тем же get_console():execute("load ~~~ ВАШ ТЕКСТ"), как это делали бородатые дядьки АМК)
-
В движке, обычно где-то есть перечисление с этими стейтами. У артов оно в заголовке Artifact.h - enum EAFHudStates В ОГСР в lua_help есть методы доп. веса - get_additional_max_weight/get_additional_max_walk_weight, но они вызываются вроде бы только для костюма. Я посмотрел, я эти методы добавлял еще в самом первом открытом репо по сталкеру Оттуда их видимо и перетащили. Туда конечно потом надо было дописать и обработку артов. Короче говоря, получить доп. вес костюма в слоте можно с помощью этих методов, а по артам - итерация по поясу и сложение параметра доп. веса из конфига. В сумме получится финальный прирост по весу, который уже можно добавлять к actor_max_weight/actor_max_walk_weight и сравнивать это все с get_total_weight. Или можно сразу в ЗП сырцах посмотреть, что нужно для того индикатора веса, чтобы не гадать. Я например не помню, который параметр ему нужен - max_weight или max_walk_weight)) То есть, следующий код выведет строку в лог только один раз? function load_dialog:Update() CUIScriptWnd.Update(self) log("load_dialog:Update") -- функция вывода может отличаться в зависимости от платформы end Если так, то дело может быть в паузе (что если ее выключить?) или искать внешний источник обновления. В движке есть тот же рендер (OnFrame), но доступа из скриптов к нему нет. Эти вещи лучше всего конечно сразу там делать.
-
Ну если load_dialog:Update() вызывается один раз, тогда никакХотя ЕМНИП в главном меню оно работало нормально, можно попробовать оттуда пробросить вызов. Это который на худе типа как в ЗП? Так для него просто нужно получить текущий вес инвентаря и сравнить с db.actor:get_actor_max_weight() или db.actor:get_actor_max_walk_weight(). Зачем второй раз считать всю эту заморочь, если движок уже посчитал?) Возможно стейты (номера) другие, скрипт работает для оружия и гранат/болта. Никогда эту фичу с артом не ковырял, может там другие стейты идут... В методе is_idle_state попробуй замени if self.item:is_weapon() then на if self.item:is_weapon() or self.item:is_artefact() then. У арта айдл вроде тоже нулевой стейт.
-
Так сам апдейт работает нормально? Выясни, проблема в апдейте или в твоем коде счетчика. Потом уже дальше разбираться. Ну так повесь вызов on_ruck на событие on_drop в том же биндере актора, будет при дропе еще уменьшаться вес. Впрочем, я не знаю зачем городить эти огороды, в ОГСР же по-любому должно в движке быть добавлено свойство арта на вес, неужели его там нет? P.S. https://github.com/OGSR/OGSR-Engine/wiki/Подробное-описание-изменений#new-properties-for-artifacts Конечно такого метода нет, разные движки же. В SA xray-extensions. В ОГСР должны быть свои новые методы для этого всего, читай доку по движку. Имя худ секции можно просто из конфига прочитать как строковой параметр, разницы нет.
