Перейти к содержанию

JustMe

Сталкеры
 Профиль  Обзор контента

  • Публикаций

    53

  • Зарегистрирован

  • Посещение

Сообщения, опубликованные JustMe

  1. Опубликовано

    9 часов назад, Nemdu сказал:

    Обратил внимание, что не поговорив с Лесником, лучше в МГ не соваться, особенно не брать флешку Каштана. Так поначалу сделал, перешел из МГ в Рыжий Лес поговорить с Лесником и затем скрашились сохранки, правда не сразу, чуток побегал. Затем ,если и  игра загружалась - то не было переходов, пришлось откатываться. Видимо нарушается логика квестов. Хоть автор и пишет, что можно идти, как хочешь, но лучше, как говорится вперед паровоза не бежать, а идти хотя бы по сюжету выполняемого задания. А так, мод очень даже зашел 

    Пошёл в МГ после разговора с Лесником. Сохранения всё равно накрылись. Там с самим МГ проблемы какие-то, безотносительно всего остального.

  3. Опубликовано

    5 часов назад, xr_Sanya сказал:

    Честно не вижу смысла поддерживать этот движок дальше, так как есть Anomaly. Может быть сделаю на его основе

    Вполне понятное решение, тащить в одиночку дальше этот дуршлаг просто нереально. Только Христом-богом молю, выпили из Anomaly весь Misery и отключи динамическую репутацию!

  4. Опубликовано

    2 часа назад, xr_Sanya сказал:

    Провел тест физики, не вылетело, хотя наспавнил кучу нпс псевдогигантов и все физические предметы

    Да у меня по физике вообще первый вылет за всё время игры в 1.5, так что это какая-то редкая редкость, на которую, по-моему, можно смело забить. Но если хочешь, я могу точно отследить цепочку вылета, чисто на всякий случай.

    • Жму руку 1

  5. Опубликовано

    8 минут назад, xr_Sanya сказал:

    Да чтож оно все вылетает?

    Желательно сейф с этим чудом

    Всегда выкладываю сейв, если знаю, как воспроизвести вылет. Но тут, как водится, рандом. Кстати, а ODE пушки, валяющиеся на земле, тоже обрабатывает?

  8. Опубликовано

    1 час назад, xr_Sanya сказал:

    Попробуй такую сборку движка https://yadi.sk/d/H9X5hu6zR6C43A

    Тут движок будет игнорировать вылет и восстанавливать правильное положение предмета в слоте (но это не точно)

    Я в предыдущем посте выложил сейв, который у меня гарантированно воспроизводит вылет (и с этим вариантом движка тоже). Извини, просто неправильно оформил дополнение поста.

  9. Опубликовано · Изменено пользователем JustMe

    15 часов назад, xr_Sanya сказал:

    Возможно удалось исправить этот вылет, нужно побегать, повоевать и полутать трупы.

    Нет, он всё ещё есть. На самом деле, его не так уж сложно воспроизвести, хотя точная последовательность действий от меня пока ускользает. Нужно в оба слота поставить пушки, а в инвентарь положить ещё парочку. Затем подходим к ремонтнику, открываем окно ремонта, выделяем пушку в слоте и начинаем хаотически менять её на пушки из инвентаря.

    Вот сейв, нужно зайти в инвентарь, заменить дробовик на любую пушку из инвентаря (визуально она не сменится), выйти из инвентаря и зайти в него снова.

    log.7z

  10. Опубликовано

    2 часа назад, xr_Sanya сказал:

    Выбросы работают нормально, проверил только что, их не менял.

    При установке "1-2 суток" первый случился спустя 2.5 суток после начала игры, такого ещё никогда не было.

    2 часа назад, xr_Sanya сказал:

    Медуза тоже вроде в порядке

    Она выводит радиацию, но значительно слабее, чем раньше. Раньше даже с одной Медузой я без накопления дозы мог находиться даже в самых сильных очагах, а теперь в них доза копится, причём быстро. Возможно, это связано с ослаблением защит костюмов; раньше я на параметр "Радиозащита" вообще не смотрел, он был просто неважен.

  11. Опубликовано · Изменено пользователем JustMe

    9 часов назад, xr_Sanya сказал:

    Обновил билд, правки движка и локализации, поправлена защита от артов.

    Вылет, старый.

    log.7z

    Дополнено 10 минуты спустя

    Теперь антирадиационные арты (по крайней мере, Медуза) не выводят радиацию. Ну или как-то слабо выводят.

    И, к примеру, кислотная аура (не аномалии!) прогрызает костюм на максимуме защиты. И выбросы перестали происходить. Такое впечатление, что нечто случилось со скоростью протекания какого-то класса процессов.

  12. Опубликовано

    Снова вылет по партиклам. А именно, недалеко от начала PAPI::CParticleManager::Update(PAPI::CParticleManager *this, int effect_id, int alist_id, float dt): сперва идут строки PAPI::CParticleManager::GetEffectPtr(int), PAPI::CParticleManager::GetActionListPtr(int), PAPI::ParticleActions::lock(void), а затем условный вызов какого-то виртуального метода -- вот на этом вызове и произошёл вылет.

    log_particle.7z

  13. Опубликовано

    7 часов назад, xr_Sanya сказал:

    возможно поправил "add_dependency" https://yadi.sk/d/1Iodtj_DVy5vQw 

    Не уверен что дело было в этом, но в любом случае добавил проверки для объектов.

    Наиграл около 5 часов, вылетов не было. На всякий случай прилагаю лог (есть warning'и).

    log.7z

    • Лайк 1

  14. Опубликовано

    В 19.11.2020 в 00:09, xr_Sanya сказал:

    Собрал новый билд.

    В него вошли всякие тестовые правки вылетов, быстрый сброс рюкзака, выбор лучшего оружия, удалены нерабочие глушители из продажи.

    Пока только "add_dependency", наиграл где-то 4 часа.

    Кстати, пси-арты так и не влияют на пси-шкалу. А вот разрыв действительно отображается.

    log.7z

  16. Опубликовано

    49 минут назад, xr_Sanya сказал:

    все файлы со студии

    Спасибо, пригодится. Главное, их же прикладывать к любому дополнительно выкладываемому бинарнику.

    50 минут назад, xr_Sanya сказал:

    могу доступ к репо дать

    Не, я пока так помучаюсь ?

    Значит, идея по поводу отлавливания add_dependency-бага: уничтожаемый object_rep (файл luabind/detail/object_rep.hpp) содержит поле m_classrep типа class_rep, доступное через метод crep(). В свою очередь, class_rep (файл luabind/detail/class_rep.hpp) содержит поле m_name, доступное через метод name(). Добавляем в функцию destroy_instance (файл src/object_rep.cpp) try..catch вокруг строки 83 (instance->~object_rep()), из catch в лог нужно вывести instance->crep()->name(). Так мы хотя бы узнаем, какой именно C++ класс глючит (если, конечно, он один). А заодно это предотвратит и вылет (вероятно, ценой протечки); ну или можно сделать throw, чтобы вылет таки случился.

    Единственный неприятный момент, видимо, состоит в том, что luabind понятия не имеет о системе логгирования Сталкера, так что придётся что-нибудь колхозить (проще всего родить собственный лог).

  17. Опубликовано · Изменено пользователем JustMe

    Могу попросить PDB для LuaJIT? А лучше сразу для всего, без них толком ничего не понятно.

    Словил уникальный вылет:

    log.7z

    Да, ещё замечания:

    • порядок кусков "историй у костра" перепутан: сперва идёт последний, за ним первый и прочие
    • характеристики "Севы" и "Севы-2" идентичны
    Дополнено 11 минуты спустя

    Ковыряние LuaJIT, по сути, ничего не дало. Прилагаю очередной типовой лог вылета. Цепочка вызовов внутри LuaJIT такова: lua_pushlstring->lj_gc_step->gc_onestep->gc_finalize (из ветки GCSfinalize)->gc_call_finalizer->lj_vm_pcall. Один шаг пропущен, поскольку я не нашёл в исходниках lj_vm_pcall (должен быть на асме), но и так всё предельно понятно: GC грохнул некую переменную (обслуживаемую luabind), в которой лежала ссылка на C++ объект и которая, соответственно, на момент уничтожения была уже забагована. Возможных причин просто море. Вопрос: насколько много обёрнутых C++ объектов (подлежащих уничтожению в процессе игры) используется в lua-скриптах Сталкера?

    log_dep.7z

  18. Опубликовано · Изменено пользователем JustMe

    2 часа назад, xr_Sanya сказал:

    Стоит попробовать эти файлы движка для лечения такого вылета

    Опять словил якобы add_dependency(). Поковырялся IDA'ой и выяснил, что падает вовсе не add_dependency(), а luabind::detail::destroy_instance на строке 83 (ручной вызов деструктора):

    Спойлер

    .text:000000018000C1D9
    .text:000000018000C1D9 loc_18000C1D9:                          ; CODE XREF: .text:000000018000C1CCj
    .text:000000018000C1D9                 mov     edx, 1
    .text:000000018000C1DE                 call    cs:lua_pushvalue
    .text:000000018000C1E4                 xor     r8d, r8d
    .text:000000018000C1E7                 mov     rcx, rbx
    .text:000000018000C1EA                 lea     edx, [r8+1]
    .text:000000018000C1EE                 call    cs:lua_call
    .text:000000018000C1F4
    .text:000000018000C1F4 loc_18000C1F4:                          ; CODE XREF: .text:000000018000C1D7j
    .text:000000018000C1F4                 mov     rcx, [rdi]
    .text:000000018000C1F7                 test    rcx, rcx
    .text:000000018000C1FA                 jz      short loc_18000C215
    .text:000000018000C1FC                 mov     rax, [rcx]
    .text:000000018000C1FF                 xor     edx, edx
    .text:000000018000C201                 call    qword ptr [rax]  <---- Вот здесь
    .text:000000018000C203                 mov     rcx, [rdi]
    .text:000000018000C206                 lea     rax, [rdi+8]
    .text:000000018000C20A                 cmp     rcx, rax
    .text:000000018000C20D                 jz      short loc_18000C215
    .text:000000018000C20F                 call    cs:__imp_free
    .text:000000018000C215
    .text:000000018000C215 loc_18000C215:                          ; CODE XREF: .text:000000018000C1FAj
    .text:000000018000C215                                         ; .text:000000018000C20Dj
    .text:000000018000C215                 mov     rcx, [rdi+30h]
    .text:000000018000C219                 test    rcx, rcx
    .text:000000018000C21C                 jz      short loc_18000C233

    Вероятно, проблемы с object_rep* instance (он берётся в самом начале, но до вызова деструктора не используется, поэтому падает только там). Могу поковырять ещё LuaJIT, но мне нужна ссылка на её исходники.

  19. Опубликовано

    25 минут назад, xr_Sanya сказал:

    Очевидно что из xrGame.DLL гдето вызывается функция add_dependency, в которую передаются неверные данные

    Засунь содержимое add_dependency в try..catch, из catch выведи в лог переданные параметры. Ну и даже на кривых параметрах хороший код падать не должен, так что add_dependency тоже "виновата".

    Дополнено 47 минуты спустя

    Не помню, выкладывал такой вылет или ещё нет. Довольно часто возникает при попытке обыска трупов.

    log.7z

  23. Опубликовано · Изменено пользователем JustMe

    Опять же, старый вылет. Возник при нажатии на F9. Рандомный. И вообще странный: каким образом из ucrtbase.free может вызваться ntdll.RtlAnsiStringToUnicodeString? Может, он логгирует чего?

    Хотя нет, странность-то в другом: вылет произошёл в ntdll.RtlAnsiStringToUnicodeString. То есть ошибка именно в ucrtbase.free. Да, возможно, ей был передан глючный указатель, но ошиблась функция именно при логгировании. Для справки: у меня Windows 7.

    log.7z

    Дополнено 48 минуты спустя

    Вылет при переходе с Юпитера на Затон. Конечно, рандомный. Всё тот же самый luabind::detail::object_rep::add_dependency(), на сей раз из сборщика мусора.

    log.7z

  24. Опубликовано

    1 час назад, xr_Sanya сказал:

    Опять при луте трупа? Я его не смог у себя повторить

    Нет, просто бежал.

    Дополнено 48 минуты спустя

    Кстати, вылетает и просто при выходе. Там ещё странности в логе есть, какие-то взаимоотношения с электроаномалией и кошкой, если я правильно понял (по всему логу), и тот же баг с владением пушкой (на 00:53:43.586, но вылета по нему не было).

    log.7z