RayTwitty

@den_z если лога нормального нет, сложно сказать в чем проблема. Я вроде бы тогда мод на 4 патче разрабатывал, адаптацию 6-ки дальше Кордона не тестировал... Но я не помню, чтобы за эти годы (десятилетие!) кто-то жаловался. Еще могу посоветовать перепроверить версию Солянки, а также порядок установки. Адаптация под 1.0006 патч в инсталляторе мода уже включает в себя адаптацию самой Солянки. То есть по итогу у нас не должно быть в папке gamedata почти никаких файлов (кроме, вроде бы пары файлов в конфигах, которые нужны для работы кейлоггера). Та версия, на которой я разрабатывал есть в шапке. Оригинал нужной версии НС, с оригинальными же флешками. Нейминг игровых архивов, в которые запакована Солянка сделан не просто так - он как раз подходит под DMX MOD (его файлы имеют бОльший приоритет). Файлы из папки Опции ставить нельзя, это всё для чистой Солянки.

Это неверно, тебе нужен асинхронный вызов с условием появления объекта, @Купер уже все правильно написал. Просто отсрочка по времени может не сработать по тем или иным причинам (например в связи с низкой производительностью), да и задержка в секунду явно много - при открытом инвентаре ты буквально будешь наблюдать самопроизвольный "полет" предмета в слот. Вообще, подобного рода вопросы (действия с объектами при выходе в онлайн) уже баян, причем очень давний.

Вопрос не в скорости (сравнение строк всегда медленнее, чем сравнение чисел), а в логике. Если когда-либо добавится новый ящик с другой секцией (vasya_box например), то тебе придется править все скрипты, логика которых завязана на имя секции. Проверка класса этот вопрос закрывает. Впрочем, если и добавляют какие-то спец-ящики, то для технических целей - их нельзя заюзать, соответственно обрабатывать событие нет нужды. Короче говоря, если логика работы позволяет проверить класс объекта, а не секцию, то надо проверять класс.

Если кучей что-то спавнится в одной точке, то оно может улететь под террейн. Возможно ЛР-ка в силу своих особенностей и размеров шейпа, физически не вступает в конфликт с другими предметами. Можно попробовать заспавнить все предметы не на землю, а в рюкзак и потом выкинуть вручную: 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. В ОГСР должны быть свои новые методы для этого всего, читай доку по движку. Имя худ секции можно просто из конфига прочитать как строковой параметр, разницы нет.

Нужно выводить в лог значение time_global за пределами условия и смотреть, что не так. Там же игра на паузе стоит, я не помню меняется ли time_global в этом случае. Первый раз гарантировано сработает потому что сравнение с нулем.

@Капрал Хикс там просто выбор анимки в зависимости от условия, типа с надетым подстволом одно, у двустволки другое и т.д. -- В той же ветке, после elseif get_clsid(self.item) == clsid.wpn_bm16_s then ... -- впилить elseif self.item:is_artefact() then ... end Кстати, в актуальной версии скрипт посвежее В меню можно же подвязаться на апдейт UI-системы: function Менюшка:Update() CUIScriptWnd.Update(self) ... end

В блок "Новые сообщения\темы" на главной я бы чутка добавил воздуха, так как сейчас он слегка выбивается из общего дизайна: // было #bimProStats .ipsDataItem { padding: 0px var(--sp-2); } // стало #bimProStats .ipsDataItem { padding: 5px var(--sp-2); } Блок немного растянется по высоте, но совсем некритично на мой взгляд. Зато внешний вид станет куда органичнее. P.S. Кстати, пользуясь случаем, могу предложить подумать на счет возвращения "олдовой" фичи форума с кнопками основных разделов, которые размещались справа от логотипа. Оно было достаточно удобно. Посмотреть визуально наверно можно в веб-архиве за 2010 год или примерно в то время. Я даже как-то с помощью скрипта крепил на странице эти иконки: Сами ассеты до сих пор живые:

Не, я же не про тотальную жесть типа какого-нибудь двача или комментов на пикабу. Например, зашел я на рандомную страницу одной из тем ап-про (даже не моей): https://ap-pro.ru/forums/topic/2868-prosto-oruzheynyy-mod-tch/page/6/#comments Ну не вижу я каких-то проблем с потреблением контента на странице. И все нормально общаются даже при отсутствии правил в стиле грамматического нацизма. Понятное дело, где-то кто-то коряво напишет, идеального мира нет, но даже тут надо смотреть - одно дело простыня на страницу без точек и запятых, другое дело 2 строки текста, где итак все понятно, как по мне нужно реагировать по-разному на такое.

Фаллаут и Метро вполне себе уместно. Там ниже написали, что есть раздел "Другие игры", но в том и дело, ты попробуй до него долистай вниз, зайди в него и найди что нужно. Возможно тут уже это обсуждали, я целиком тему не читал конечно. Я кстати не припомню (раз уж тут пример привели), чтобы на ап-про был где-то мат. Или прям какие-то жесткие срачи с оскорблениями. Обычно если такое и бывало раз в год, то это удалялось и все. То же касалось и ГМ - потерли и забыли, некоторые даже бекапы делали для истории) Так вот, вся эта вопиющая ненормативная лексика и вульгарность, которая мешает так жить - она сейчас с нами в одной комнате? Или где ее можно увидеть? Оно конечно, сильно надо))

Тут смешная мысль закралась - создать аналог "Дикой территории" на форуме, куда запустить всех "ГМ-овцев", чтобы они там резвились, устраивали срачи и прочее Ну а если серьезно, то некая "перестройка" (с) необходима, в разумных пределах конечно. Ибо возбуждение от слов "xз" в постах и последующего бана за "мат", ну это чистой воды перебор. Тут кто-то верно заметил - если оно грамотно и по контексту, никому же не помешает, не оскорбит. Понятно, что условные школьники общаются на уровне своего возраста, но а что делать, когда тут реально три пенсионера останутся?.. (рит.в.) Тему пока не дочитал, такие первые мысли после прочтения шапки.

Прям сильно внимательно не слежу, но разве там "вкусовщина" не вырубается либо на этапе препроцессора дефайнами либо в геймдате через конфиг? В секции features или установкой значений по умолчанию по принципу "параметр не прописан - фича не работает".

Так изначально и ХЕ затачивался под этот самый OGSE, тем более что Malandrinus и K.D. оба были в команде OGSE)) И только после того, как в проект начали входить другие люди, в том числе и я, Malandrinus добавил препроцессор для конфигурирования сборок. А я уже настроил сами правки так, что скачав сейчас последнюю версию, мы получаем максимально дефолтную сборку (насколько это возможно) без разных специфических штук, которые работают только на OGSE или где-то еще. Я еще помню, как меня в личке даже обвиняли в ломании обратной совместимости, типа моя деятельность по "унификации" плохо отражается на OGSE-разработке Хотя как показало время, моя тактика была верной, а препроцессор закрыл вопросы с конфигурацией. P.S. Впрочем, я не припомню, чтобы OGSE или правки движка, которые в нем используются были шибко конфигурируемы. Тут уже выше заметили, что статику там вырезали еще до появления исходников) Достаточно бескомпромиссное решение, хотя это был вроде только 2014 год или где-то так.

По-моему изначальная задумка проекта была в том, чтобы перевести один конкретный проект, а именно OGSE/R на исходники вместо движковых правок xray-extensions)) Название движка как бы намекает. А то что со временем он стал конструктором "настрой движок сам" это уже отхождение от изначальной концепции. И то, что они стали еще сильнее отходить уже мало на что влияет. В идеале надо было останавливаться 5 лет назад после переноса последней штуковины из xray-extensions, делать форк и двигаться дальше по принципу "я художник, я так вижу".

Там кстати выше есть мой коммент по поводу вырезания статики) Если кратко - ее очень сложно поддерживать левел дизайнеру, так как процесс настройки освещения там никакой. Плюс у статики как рендера есть целая куча проблем и недоделок еще с оригинала - кривое освещение дин. объектов, воллмарков, травы, воды, тумана и прочее такое. По сути нормально освещается только статическая геометрия статическим же освещением, и то не всегда - тому пример синие кусты на билдолоках. Про кривизну дин. освещения на первом рендере я вообще молчу. Очень много проблем, которые тормозят разработку локаций. Про внутридвижковые проблемы уже сказали в посте на ап про по твоей ссылке. Оставлять первый рендер в 24 году рекомендуется только тем, кто пилит какие-то билдомоды или использует билдовские локации и хочет типа сохранить шарм статики (и при этом знает как со всем этим работать). Во всех остальных случаях - вырезать под корень. Не вижу ничего сложного - git позволяет откатиться на любой коммит и начинать с него. При желании можно сделать форк - как это сделал например я в самом первом репозитории на xp-dev, когда Alpet начал тащить в него NLC-специфичные штуки, которые конечно крутые, но мне были не нужны.