RayTwitty
-
Число публикаций
1 281 -
Регистрация
-
Последнее посещение
-
Дней в топе
8 -
AMKoin
3,782 [Подарить AMKoin]
Весь контент пользователя RayTwitty
-
Мы не про lua (библиотеку) разговор вели, а про скриптовый API конкретно движка. С lua библиотекой история ожидаемая и вполне понятная. Тоже самое было в кастомных движках, где вроде кроме замены gfind на gmatch и пары подобных штук, особо последствий никаких. Да и тех я не припомню, у себя я поправил только один момент связанный с u32(-1) в таск менеджере. А вот изменение скриптового API движка - это другого уровня переделки. Вот как например гейм граф, упомянутый выше. Наверняка там еще что-то есть... P.S. Кстати, заметили что в ТЧ добавили hit_callback для актора? Сколько в свое время костылей было написано, чтобы сделать такую банальную вещь, как реакцию на хит)) Скорее всего придется (если кто захочет добавлять поддержку ЕЕ) писать в коде инъекции по типу: if get_platform_id then -- get_platform_id() глобальный метод, который есть только в ЕЕ -- код совместимый с ЕЕ else -- старый код end
-
Хех, будет весело если выяснится, что порезали скриптовый API. Это будет означать, что нет обратной совместимости с модами или она будет частичной.
-
Собственно, обновил. X-Ray converter (Repack) https://disk.yandex.ru/d/quAl5SrTNjZEWQ Старая версия на всякий случай тут. Отличия от старой версии: 1) обновлен конвертер, используется последняя версия (0.3.1) отсюда*: https://github.com/abramcumner/xray_re-tools/releases 2) поддержка SDK от ЧН и ЗП (раньше было только под ТЧ) 3) документация теперь в одном файле * Как по мне, наиболее актуальный форк. Есть еще вот это, но я его не тестировал.
-
Сначала это всё вызывало *смех мексиканца*. Теперь это вызывает лишь одно чувство - ненависть. Как вариант, чтобы не костылить автостатики: <texture id="ui_inv_icon_health_restore_speed" x="498" y="110" width="18" height="18" ng_ratio="4" /> -> <texture id="ui_inv_icon_health_restore_speed" x="1992" y="440" width="72" height="72" ng_ratio="1" /> Не проверял, но насколько я понял идею: просто умножить все на 4 и убрать множитель.
-
Оно сделано в движке. По идее там ничего сложного, обычный трекбар. slider_box - тег в инвентаре. Другое дело, а надо ли это брать в таком виде, в каком оно сделано? Как по мне, выглядит по васянски. В оригинале оно кстати было зашито в движок (в кастомных движках отдельно выводили в конфиги).
-
Проблема выделена Не нужно играть в подобные моды новичкам, это мод для "Прошел ТЧ 40 раз перед релизом ЧН в попытках выбить все концовки (действуя наугад, ведь интернета нет), причем 10 раз перепроходил только потому, что слетела Windows XP, а сейвы не забекапил. На 41 раз вижу НПС сквозь геометрию.". Понятно, что это весьма концептуальный мод, но на то он и концептуальный. И по крайней мере он отличается от всего остального. P.S. Насколько я помню, задания можно было записывать в новую эл. книжку, которую надо было раздобыть у Вергаса (?). Там разве что с клавиатуры почему-то писать нельзя было, вроде должны были поправить.
-
Подумалось, чтобы сократить количество телодвижений при интеграции и установке конвертера. В обычном случае: задать путь до СДК в 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 (его файлы имеют бОльший приоритет). Файлы из папки Опции ставить нельзя, это всё для чистой Солянки.
- 1 883 ответа
-
- 1
-
-
- мутанты
- народная солянка
- (и еще 6 )
-
Это неверно, тебе нужен асинхронный вызов с условием появления объекта, @Купер уже все правильно написал. Просто отсрочка по времени может не сработать по тем или иным причинам (например в связи с низкой производительностью), да и задержка в секунду явно много - при открытом инвентаре ты буквально будешь наблюдать самопроизвольный "полет" предмета в слот. Вообще, подобного рода вопросы (действия с объектами при выходе в онлайн) уже баян, причем очень давний.
-
Вопрос не в скорости (сравнение строк всегда медленнее, чем сравнение чисел), а в логике. Если когда-либо добавится новый ящик с другой секцией (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 по аналогии с остальными).
- 1 883 ответа
-
- 1
-
-
- мутанты
- народная солянка
- (и еще 6 )
-
@Norman Eisenherz если важно получить время, то скорее всего без правок движка никак. Или хотя бы расширить кастрированные луашные пространства имен ("лайтовые правки движка") - io, os и т.д. Вроде давно были эти библиотеки внедренные в xrLua.dll или проброшенные туда, без правки основного движка (xrGame.dll, .exe etc). Суть наводки - может быть можно будет получить текущее время системы в мс и уже это ловить на сталкерском апдейте вместо time_global().
