JustMe

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

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

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

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

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

Новый вылет. В логе, кстати, всё ещё есть ругань на "There are no free room to place item". log.7z

Примерно вот такой. В последнее время игра всё чаще не дописывает лог при вылете. log.7z

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

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

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

Вылет, старый. log.7z Дополнено 10 минуты спустя Теперь антирадиационные арты (по крайней мере, Медуза) не выводят радиацию. Ну или как-то слабо выводят. И, к примеру, кислотная аура (не аномалии!) прогрызает костюм на максимуме защиты. И выбросы перестали происходить. Такое впечатление, что нечто случилось со скоростью протекания какого-то класса процессов.

Снова вылет по партиклам. А именно, недалеко от начала 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

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

Пока только "add_dependency", наиграл где-то 4 часа. Кстати, пси-арты так и не влияют на пси-шкалу. А вот разрыв действительно отображается. log.7z

Вылет при переходе с Затона на Юпитер. Не воспроизводится. log.7z

Спасибо, пригодится. Главное, их же прикладывать к любому дополнительно выкладываемому бинарнику. Не, я пока так помучаюсь ? Значит, идея по поводу отлавливания 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 понятия не имеет о системе логгирования Сталкера, так что придётся что-нибудь колхозить (проще всего родить собственный лог).

Могу попросить 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

Опять словил якобы add_dependency(). Поковырялся IDA'ой и выяснил, что падает вовсе не add_dependency(), а luabind::detail::destroy_instance на строке 83 (ручной вызов деструктора): Вероятно, проблемы с object_rep* instance (он берётся в самом начале, но до вызова деструктора не используется, поэтому падает только там). Могу поковырять ещё LuaJIT, но мне нужна ссылка на её исходники.

Засунь содержимое add_dependency в try..catch, из catch выведи в лог переданные параметры. Ну и даже на кривых параметрах хороший код падать не должен, так что add_dependency тоже "виновата". Дополнено 47 минуты спустя Не помню, выкладывал такой вылет или ещё нет. Довольно часто возникает при попытке обыска трупов. log.7z

Нет, всё тот же вылет. На всякий случай: исходники luabind берёшь отсюда? log.7z

Вот тот же вылет. Собственно, вылетает-то luabind, а не luajit. log.7z

Вылет сразу же в начале загрузки сохранения. log.7z

Опять же, старый вылет. Возник при нажатии на F9. Рандомный. И вообще странный: каким образом из ucrtbase.free может вызваться ntdll.RtlAnsiStringToUnicodeString? Может, он логгирует чего? Хотя нет, странность-то в другом: вылет произошёл в ntdll.RtlAnsiStringToUnicodeString. То есть ошибка именно в ucrtbase.free. Да, возможно, ей был передан глючный указатель, но ошиблась функция именно при логгировании. Для справки: у меня Windows 7. log.7z Дополнено 48 минуты спустя Вылет при переходе с Юпитера на Затон. Конечно, рандомный. Всё тот же самый luabind::detail::object_rep::add_dependency(), на сей раз из сборщика мусора. log.7z

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

А вот и первый вылет (он уже был, и остался): log.7z