JustMe
Сталкеры-
Публикаций
53 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Блоги
Календарь
Новости
Моды
Весь контент JustMe
-
Пошёл в МГ после разговора с Лесником. Сохранения всё равно накрылись. Там с самим МГ проблемы какие-то, безотносительно всего остального.
-
Не нашёл поиском жалоб на музыку, поэтому жалуюсь сам: Жекан, пожалуйста, убери автовключение громкости музыки, задолбался я её уже отключать.
- 4 320 ответов
-
- новый сюжет
- новые локации
-
(и ещё 1 )
C тегом:
-
Вполне понятное решение, тащить в одиночку дальше этот дуршлаг просто нереально. Только Христом-богом молю, выпили из 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