Перейти к контенту

Winsor

Опытные
  • Число публикаций

    255
  • Регистрация

  • Последнее посещение

  • Дней в топе

    2
  • AMKoin

    150 [Подарить AMKoin]

Весь контент пользователя Winsor

  1. Winsor

    [SoC] Вопросы по SDK

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

    Скриптование

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

    Скриптование

    1) Вылета не должно быть, так как в движке происходит return (*m_lua_function)(); а при вызове info_callback объект актора уже создан, т.е. функция возвращает указатель на существующий объект, движок преобразует это значение в true, так как оно не nullptr. т.е. в результате результат функции всегда true. 2) функция проверяется всегда, до тех пор пока не вызван remove_call. если у тебя не вызывается каждый раз msg() - скорее всего проблема в логике. возможно ты делаешь где то remove_call, либо у тебя повис скриптовый биндер, что очень плохо. Единственное что меня немного смущает - то что ты для глобального колбека используешь local function={} - вот это уже может приводить к "непонятному" поведению.
  4. Не вводите людей в заблуждение demo_record - вырезан, blinker - это ошметки моего неудачного эксперимента, который был удален из-за кривизны и недоделанности
  5. Дожились... Надо кнопку придумать в главном меню - "Пройти мод". Правки нарушили структуру как минимум system.ltx в котором пропали инклюды на текстовые файлы. иконками, иконками. ВНИМАНИЕ!!!! Данная правка приводит к нарушению структуры сейвов! А именно - установка размера скриптового рюкзака более 8000 (8192, если точнее) байт приведет к превышению допустимого размера нетпакета движка и при сохранении такой игры Вы испортите сейв. Далее, отключение кода в GetDataSize приводит к неправильной работе проверки на превышение данного размера, что тоже может приводить к битью сейвов. Причем такой сейв невозможно восстановить. Ребята, выкладывая правки - ну Вы хоть думайте, почему именно стоит такое ограничение. Ладно 4к - это было в оригинале, может кому и мало. Но делать больше 8к , еще и приводить в реадми пример с цифрой в 50к - ну это уже как то безнравственно что ли. По поводу default_container_size - все на ответственности игрока, хотя и тут значение в 50к как то уж слишком... 50000 id отдать только на хабар - ну,ну...Это уже не плюшкин
  6. ну это точно не получиться, есть еще мод "Динамические аномалии". т.е. они все равно будут. Ну я по поводу удаления более чем одной аномалии - в коде прямо комментарий есть по этому поводу... Ну я даже не знаю как еще подробнее указать. Я уже писал про это. В моде есть как минимум 2-а объекта (заряжатель и контейнер), которые используют сетку для отображения в скриптовых UI объектах иконки предметов. Т.е. на их идее можно сделать хотя бы примерно похожее отображение и в новых рюкзаках. Но вот чего то никто не хочет писать (никто не показал даже попыток, экспериментов с таким отображением) - все хотят чтобы им сделали. А раз только хотят - то придется ждать, может в 2.2 я наконец то успею их доделать.
  7. Вот ты упорный и недоверчивый. Я тебе как создатель мода говорю - не получится! Поддержка слота для дробовика добавлена в движок, и если ты и перенесешь файлы для нового слота в другой мод, не на основе движка ОП2.1 - работать не будет!!! Ну как еще объяснить? Например за рисование нового слота в инвентаре отвечает файл inventory_new.xml в папке config\ui. Попробуй, перенеси и убедись...
  8. Выложите пожалуйста это все не на яндекс, я посмотрю. и посоветую что-нибудь. === Ну как по мне - вешанье на биндер объекта контроль нахождения в слоте и управление 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) ну и очень внимательно посмотреть по коду - где еще по логике идет использование в биндере таких странных штук. после этого заспавнить итем себе в инвентарь. интерфейс должен активироваться двойным щелчком. после этого заспавнить себе в инвентарь
  9. Скачать с яндекса и подсказать на конкретном конфиге не могу, но сделать это очень просто. Необходимо в конфигурации итема, который спавниться в инвентарь изменить ему класс с оружия на обычный "съедаемый" предмет и добавить в конфигурацию параметр item_use_only = true и все. он будет активироваться из инвентаря и не пропадать при активации... p.s. зачем его в оружейный слот? О_О Автор, если есть желание - пишите в личку.
  10. Внимание! Мне не жалко - но как разработчик - НЕ РЕКОМЕНДУЮ!!!! использовать запакованный all.spawn утилитами не с набора ОП2.1! В ОП2.1 изменились некоторые движковые классы и соответственно их нетпакеты, работоспособность такой сборки не гарантирую от слова совсем!!!! это чревато очень интересными глюками! Опять таки как разработчик - не понимаю, что именно Вам надо от перепакованного all.spawn... Тем более если Вы не знаете что такое нетпакет и серверные классы...
  11. а что делать с теми квестами которые завязаны на этих "кустах"? Причем эти квесты уже кучу лет на этом основаны. игра физически не может запуститься на двух и более ядрах. Нет в движке такой возможности. affinity.exe позволяет запускать игру на процессоре, отличном от того который система выделяет запускаемому процессу/приложению по умолчанию - чаще всего это 0-й. На данный момент такая возможность встроена в игру, без каких либо сторонних утилит и батников. Делается это с помощью консольной команды g_affinity.
  12. в файле fsgame.ltx изменить строчку, которая начинается с $game_saves$.вместо $game_saves$ = true| false| $app_data_root$| savedgames\ указать $game_saves$ = true| false| полный_путь_к_новой_папке_сохранений желательно без кириллических символов в пути.
  13. Все патчи, которые будут исправлять какие то критические ошибки - будут выпускаться с индексом 8.х. Если критических проблем не будет найдено - 8.1 будет через пару недель - я планирую закончить "борьбу" с некоторыми АИ схемами и их производительностью. Глобально он ничего привносить не будет - только исправления скриптов схем. На этом работа над 2.1 скорее всего будет завершена. Но мод продолжает разрабатываться. Следующее обновление планируется через несколько месяцев и будет требовать НИ, так как накопилось много изменений, которые патчами не ввести (ну или муторно переспавнивать/переделывать). Над этой веткой (назовем ее, пусть, 2.2) - работа уже ведется, будет несколько "вкусностей" в игровом процессе, очень много изменений в внутренностях игры.
  14. По поводу Бармена - в патче 7.3 был убран постоянный переспавн Бармена при каждом посещении Бара, вместо этого логикой (конфигами) был поставлен запрет на использование той комнаты, в которую уходит Бармен. Если у Вас он все таки туда ушел - значит что-то из правок перекрывает логику патча. такой вывод сделан на основании того что на офсайт жалоб игроков (ну и сейвов с таким событием) на чистом патче 7.3 о том что Бармен ушел - не было. Что можно сделать (варианты решения): 1) найти все правки, которые замещают логику Бармена и адаптировать их. 2) вернуть постоянный переспавн Бармена (как было в ОП2 и ранних патчах), что не очень хорошо для "самого" Бармена - сбрасываются некоторые квесты, сбрасывается содержимое торговли, еще подобные вещи. Для этого необходимо в файле bind_actor.script убрать комментарии со строк 370 и 371, номера строк даны для патча а не для правленого биндера актора. 3) в патче в движок была добавлена функция teleport_object(id.pos,lv,gv), которая позволяет принудительно телепортировать, например, Бармена в определенную точку за стойкой бара. можно в тот же bind_actor.script вместо строк 370 и 371 написать такой код ai:teleport_object(server_object("bar_barman").id,xyz(132.294921875,-4.74485778808594,20.3684597015381),36323,1238) так как функция новая - требует тестирования. Но как минимум в онлайне - она работает.
  15. Winsor

    [SoC] Вопросы по SDK

    А то я не исправлял вертексы для рюкзаков, которые на землю падали, и на некоторых локациях скриптовый спавн (Юпитер, Затон). Получается что не должно изменяться - но изменяется. Ну да ладно - я не специалист в данном вопросе. Может те кто после меня придут - смогут реализовать. Всем спасибо.
  16. Winsor

    [SoC] Вопросы по SDK

    Я не хочу вот этого: А НИ - это уже побочный эффект, который не так уж и страшен.
  17. Winsor

    [SoC] Вопросы по SDK

    У меня есть специфическая идея, которая не требует наличия "перемещения" между этой локацией и другими для ботов. Так сказать - сама в себе локация. Все что от нее надо - поспавнить свои предметы на себе родной, при загрузке в онлайн. Можно попробовать обойтись координатами. Пока у меня мало опыта в этом направлении - это все предположения. Из существующей загруженной кросс таблицы последний максимальный, далее по нарастающей. Не подойдет? Нет, к сожалению - не проще. Перекомпиляция геймграфа без добавления локации уже может приводить к изменению значения вертексов, как показала практика. Оно будет, но не по этой причине. Если задумка не получиться - проще отказаться.
  18. Winsor

    [SoC] Вопросы по SDK

    Думаю что можно. Причем если level.spawn я представляю как заставить работать, то с графом труднее - а именно с нумерацией индексов, тут уже с компилятором надо что-то думать. Правда это уже в другую тему - тему движка. Спасибо!
  19. Winsor

    [SoC] Вопросы по SDK

    Хочется странного - подключить подземную локацию к игре, но при этом не перекомпиливать all.spawn и game.graph основной игры. Это возможно? возможно ли использовать только level.game и level.spawn?
  20. Так как на офф. сайт много пишут про несчастного ученого из лаборатории и абсолютно не слушают доводов и аргументов - напишу здесь:
  21. т.е. без какого то лишнего шага не обойтись? например, псевдокод: rawdata={["dsdsd"]=true} setmetatable(data,{__index,__newindex}) copy(data,rawdata)
  22. Вопрос по метатаблицам local data=setmetatable({},{ __tostring = function() return "data_table_name" end, }) log("1 "..tostring(data)) data={["dsdsd"]=true} log("2 "..tostring(data)) Вывод 1 data_table_name 2 0A0EC4C8 т.е. при инициализации таблицы новыми данными ее метатаблица затирается. если делать setmetatable после инициализации - не вызываются _index,__newindex. каким образом можно избежать такого эффекта? очень не хочется писать отдельные циклы заполнения таблицы с метаданными... p.s. все это вызывается из под движка ТЧ 1.0007 p.s.s. само собой, можно написать и так: local data=setmetatable({["dsdsd"]=true},{ __tostring = function() return "data_table_name" end, }) но все равно не вызываются события _index,__newindex у таблицы data.
  23. level.add_call добавляет на каждом апдейте вызов Ваших функций, указанных как параметры таким образом первый параметр - это функция которая должна в обязательном порядке вернуть значение булевого типа. если функция вернула true - это условие для вызова функции во втором параметре. результат второй функции - не важен. так как данная проверка происходит на каждом OnFrame - для ускорения работы движок не проверяет валидность результата функции my_func вообще. Если функция возвращает , например, userdata, либо не возвращает ничего - будет вылет. По поводу однократного вызова - проверка my_func будет вызываться до тех пор пока не будет сделан level.remove-call( my_func, another_func ) - ну и само собой - если my_func вернула true на каждом вызове - то и постоянно будет вызываться another_func.

AMK-Team.ru

×
×
  • Создать...