RayTwitty

При наличии SetSelectedItem (в оригинале ТЧ нет, но есть в ХЕ и вроде бы в ЗП), можно и навигацию стрелками по элементам списка сделать. Я у себя в исходниках еще давно убрал это все под капот (со всеми проверками на вшивость), сделав два метода - выбрать следующий и предыдущий элемент списка. Помимо выбора возвращает успешность попытки (если например дошли до конца, то делать ничего не надо). -- навигация по списку с клавиатуры if keyboard_action == ui_events.WINDOW_KEY_PRESSED then local list = self:GetListWnd("list_window") if dik == DIK_keys.DIK_UP then if list:SelectLastItem() then self:OnListItemClicked() end elseif dik == DIK_keys.DIK_DOWN then if list:SelectNextItem() then self:OnListItemClicked() end elseif dik == DIK_keys.DIK_DELETE then self:OnButton_del_clicked() elseif dik == DIK_keys.DIK_RETURN then self:OnButton_load_clicked() end end Теперь подумываю изменить (добавить перегрузку, чтобы сохранить обратную совместимость) метод GetItem, чтобы без аргументов он сразу возвращал выбранный элемент списка (если есть). Тогда не придется городить эти все if index ~= -1 then return end и прочие: сразу local item = list:GetItem() if item then ... end P.S. Для ванильного (и ХЕ) движка давно юзаю обертку: function _G.validate_list(list) if list:GetSize() ~= 0 then local index = list:GetSelectedItem() return index ~= -1 and list:GetItem(index) end end Юзается так: self:AddCallback("list", ui_events.LIST_ITEM_CLICKED, self.on_list_item_clicked, self) function CUIMyWnd:on_list_item_clicked() if validate_list(self.list) then -- тут 100% есть выбранный item local item = self.list:GetItem(self.list:GetSelectedItem()) end end

@WinCap скорее всего некорректное название. GetSelectedIndex правильнее было бы. А вот GetItem уже возвращает юзердату. Можно там конечно дописать что-то типа if not list:GetItem(index) then return end, но это будет затычка. Мне кажется там проблема в чем-то другом. Скрипт кстати правленный, -1 заменено на 4294967295 как минимум, скорее всего оно было написано для другого движка. Как я уже писал выше, надо дебажить.

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

@Капрал Хикс что в таком случае ты хочешь удалить?

@Капрал Хикс при этом какая-нибудь строчка выделена? (закрашен элемент списка полоской на фоне)

@Капрал Хикс тогда надо дебажить, выводить в лог индекс который выдает GetSelectedItem, смотреть, почему с ним не работает GetItem (получение элемента списка по его номеру) и т.д. Да и вообще, в целом не ясно "если курсор не стоит на строке сохранения" - курсор это что? Фокус мыши не наведен на элемента списка? Или элемент списка не выделен? Просто в каком-то ориг скрипте был момент (наверно save dialog), что вместо GetSelectedItem использовался GetFocusedItem, и там как раз тоже был косяк с тем, что при подвязке хоткеев мышь могла не быть над элементом списка в момент действия. Но тут такого я не вижу.

@Капрал Хикс попробуй все строчки вида if index == 4294967295 then return end заменить на if index == 4294967295 or index == -1 then return end Возможно скрипт написан под обновленный lua.

Что-то туплю видимо, давно lua не ковырял Есть локальная функция в модуле: local function myfunc() print("myfunc !!!") end Нужно вызвать ее по имени. Но, имя генерируется в другом месте. Первая мысль была сделать просто ["myfunc"](), но не сработало, как и this["myfunc"]() Так, как сделать? Через loadstring что ли? loadstring(script_name()..".myfunc()")() выглядит как дичь же (но работает, правда не с локальными функциями, что логично)

Требуется мнение. Навело на мысль обсуждение из соседней темы по Enhanced Edition. В нем также как и в кастомных движках обновили библиотеку lua, из-за чего кое-какие места в скриптах перестали нормально работать (ТЧ). В частности task_manager.script, функция CRandomTask:load. Если я все правильно помню, то local selected_target = p:r_u32() в оригинальном движке при передаче туда u32(-1) возвращал 0, а теперь возвращает 4294967295, из-за чего ломалась вся дальнейшая логика. И я, и новоПЫС придумали затычку, на скрине (мое снизу). По своей затычке могу объяснить логику - коль уж в оригинальном движке у нас selected_target получал 0 при передаче туда u32(-1), тогда если случается local defend_object = alife():object(4294967295), что результате всегда дает nil, то мы просто присваиваем переменной серверный объект актора. То есть, поведение оригинала 1.0006 не меняется. А вот у новоПЫС получается так - self.task_info[id].selected_target и self.task_info[id].defend_target просто не заполняются. Какие от этого могут быть последствия я даже не знаю. Так в чем вопрос - кто тут прав? И почему вообще r_u32() стало по-другому работать? Из-за обновленного lua ли? Или может из-за другого компилятора и пр.?

Мы не про 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 попробуй их.

В 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.