Winsor

Меня больше интересует вопрос - правятся они ладно, а вот как быть с тем что индексы на старых локациях смещаются при компиляции? в этом варианте подключения как происходит? p.s. и мне не надо чтобы мобы ходили в данную локацию.

Хм... Приношу свои извинения за введение в заблуждение. "Почитал" более внимательно движок ТЧ - все что я писал ранее не относится к вызовам, которые добавляются из скриптов, а именно CPHScriptAction и CPHScriptCondition. Для других condition и action которые добавляются в движке - алгоритм работает немного иначе... Действительно, CPHScriptCondition (условие проверки) выполняется всегда и постоянно, при возврате true из данной функции выполняется запуск CPHScriptAction. если CPHScriptCondition или CPHScriptAction перешел в состояние obsolete ("устаревший"), менеджер вызовов удаляет этот call. Тонкость в том что именно скриптовый CPHScriptAction сразу после первого вызова переводит свое состояние в obsolete void CPHScriptAction::run() { (*m_lua_function)(); b_obsolete=true; } что и приводит в удалению всего вызова после единственного срабатывания. Еще раз - прошу прощения за неточность...

1) Вылета не должно быть, так как в движке происходит return (*m_lua_function)(); а при вызове info_callback объект актора уже создан, т.е. функция возвращает указатель на существующий объект, движок преобразует это значение в true, так как оно не nullptr. т.е. в результате результат функции всегда true. 2) функция проверяется всегда, до тех пор пока не вызван remove_call. если у тебя не вызывается каждый раз msg() - скорее всего проблема в логике. возможно ты делаешь где то remove_call, либо у тебя повис скриптовый биндер, что очень плохо. Единственное что меня немного смущает - то что ты для глобального колбека используешь local function={} - вот это уже может приводить к "непонятному" поведению.

Не вводите людей в заблуждение demo_record - вырезан, blinker - это ошметки моего неудачного эксперимента, который был удален из-за кривизны и недоделанности

пока никак.

Дожились... Надо кнопку придумать в главном меню - "Пройти мод". Правки нарушили структуру как минимум system.ltx в котором пропали инклюды на текстовые файлы. иконками, иконками. ВНИМАНИЕ!!!! Данная правка приводит к нарушению структуры сейвов! А именно - установка размера скриптового рюкзака более 8000 (8192, если точнее) байт приведет к превышению допустимого размера нетпакета движка и при сохранении такой игры Вы испортите сейв. Далее, отключение кода в GetDataSize приводит к неправильной работе проверки на превышение данного размера, что тоже может приводить к битью сейвов. Причем такой сейв невозможно восстановить. Ребята, выкладывая правки - ну Вы хоть думайте, почему именно стоит такое ограничение. Ладно 4к - это было в оригинале, может кому и мало. Но делать больше 8к , еще и приводить в реадми пример с цифрой в 50к - ну это уже как то безнравственно что ли. По поводу default_container_size - все на ответственности игрока, хотя и тут значение в 50к как то уж слишком... 50000 id отдать только на хабар - ну,ну...Это уже не плюшкин

ну это точно не получиться, есть еще мод "Динамические аномалии". т.е. они все равно будут. Ну я по поводу удаления более чем одной аномалии - в коде прямо комментарий есть по этому поводу... Ну я даже не знаю как еще подробнее указать. Я уже писал про это. В моде есть как минимум 2-а объекта (заряжатель и контейнер), которые используют сетку для отображения в скриптовых UI объектах иконки предметов. Т.е. на их идее можно сделать хотя бы примерно похожее отображение и в новых рюкзаках. Но вот чего то никто не хочет писать (никто не показал даже попыток, экспериментов с таким отображением) - все хотят чтобы им сделали. А раз только хотят - то придется ждать, может в 2.2 я наконец то успею их доделать.

Вот ты упорный и недоверчивый. Я тебе как создатель мода говорю - не получится! Поддержка слота для дробовика добавлена в движок, и если ты и перенесешь файлы для нового слота в другой мод, не на основе движка ОП2.1 - работать не будет!!! Ну как еще объяснить? Например за рисование нового слота в инвентаре отвечает файл inventory_new.xml в папке config\ui. Попробуй, перенеси и убедись...

Выложите пожалуйста это все не на яндекс, я посмотрю. и посоветую что-нибудь. === Ну как по мне - вешанье на биндер объекта контроль нахождения в слоте и управление UI - это сильно. Да и вообще - у себя я так и не смог его запустить - у меня уже нету 2.1, а ставить облом. Как это переделать, примерно: 1) заменить конфиг итема на такой 2) в скрипте callback_use в таблицу добавить примерно такую секцию 3) в скрипте _bind_mobile.script в функции mobile_binder:OpenMenuManager() повыбрасывать проверки на положение в слоте и оставить только open_menu = _mobile.Mobile(self) level.start_stop_menu(open_menu,true) 4) в этом же скрипте убрать с апдейта mobile_binder:update вызов self:OpenMenuManager() 5) повыбрасывать из этого же скрипта self.back_item_id,self.back_active_slot,self.save_back_active_slot 6) ну и очень внимательно посмотреть по коду - где еще по логике идет использование в биндере таких странных штук. после этого заспавнить итем себе в инвентарь. интерфейс должен активироваться двойным щелчком. после этого заспавнить себе в инвентарь

Скачать с яндекса и подсказать на конкретном конфиге не могу, но сделать это очень просто. Необходимо в конфигурации итема, который спавниться в инвентарь изменить ему класс с оружия на обычный "съедаемый" предмет и добавить в конфигурацию параметр item_use_only = true и все. он будет активироваться из инвентаря и не пропадать при активации... p.s. зачем его в оружейный слот? О_О Автор, если есть желание - пишите в личку.

Внимание! Мне не жалко - но как разработчик - НЕ РЕКОМЕНДУЮ!!!! использовать запакованный all.spawn утилитами не с набора ОП2.1! В ОП2.1 изменились некоторые движковые классы и соответственно их нетпакеты, работоспособность такой сборки не гарантирую от слова совсем!!!! это чревато очень интересными глюками! Опять таки как разработчик - не понимаю, что именно Вам надо от перепакованного all.spawn... Тем более если Вы не знаете что такое нетпакет и серверные классы...

а что делать с теми квестами которые завязаны на этих "кустах"? Причем эти квесты уже кучу лет на этом основаны. игра физически не может запуститься на двух и более ядрах. Нет в движке такой возможности. affinity.exe позволяет запускать игру на процессоре, отличном от того который система выделяет запускаемому процессу/приложению по умолчанию - чаще всего это 0-й. На данный момент такая возможность встроена в игру, без каких либо сторонних утилит и батников. Делается это с помощью консольной команды g_affinity.

в файле fsgame.ltx изменить строчку, которая начинается с $game_saves$.вместо $game_saves$ = true| false| $app_data_root$| savedgames\ указать $game_saves$ = true| false| полный_путь_к_новой_папке_сохранений желательно без кириллических символов в пути.

в 2.2 скорее всего да.

Все патчи, которые будут исправлять какие то критические ошибки - будут выпускаться с индексом 8.х. Если критических проблем не будет найдено - 8.1 будет через пару недель - я планирую закончить "борьбу" с некоторыми АИ схемами и их производительностью. Глобально он ничего привносить не будет - только исправления скриптов схем. На этом работа над 2.1 скорее всего будет завершена. Но мод продолжает разрабатываться. Следующее обновление планируется через несколько месяцев и будет требовать НИ, так как накопилось много изменений, которые патчами не ввести (ну или муторно переспавнивать/переделывать). Над этой веткой (назовем ее, пусть, 2.2) - работа уже ведется, будет несколько "вкусностей" в игровом процессе, очень много изменений в внутренностях игры.