
Отчасти это решалось этим:
LOD_RADIUS=5.500000
, и мы всегда помнили, что:
DDM (11 December 2012 — 15:06) писал:
Сегодня в летя рейс AB 7318 EDDT-OMDB, несмотря на все меры предосторожности от такого рода ошибок (как значение LOD_RADIUS так и значение Autogen density=Very DenseDense, x64 ОС, Виртуальная память 3072-3072 на системном диске)
все таки словил ошибку «out of available memory»
, которой не видел на своем мониторе очень давно. Думаю, все знают как это происходит, FSUIPC несколько раз подает звуковой сигнал, затем спустя некоторое время и появляется «заветное» окошко. Попытки закрыть все открытые сторонние приложения и в аварийном порядке выключить весь автоген и т.п. не привели
Обидно после 6 часов полета, не так ли? Раз есть проблема, значит, есть и её решение. Вот я и отправился его искать.
В процессе стандартного гугления наткнулся на эту тему. Кратко прочитав первый пост, согласился с автором второго:
FSMP сказал:
Да и следующие посты оптимизма не преувеличивали, но я все же решил попробовать описанные действия.
По-русски:
1) Скачиваем это. (! Это для пользователей FSX SP2, коим я и являюсь, для пользователей разгона см. тему)
2) При помощи нехитрого и интуитивно понятного инсталлера патчим свой api.dll (о бэкапе можно не беспокоится, утилитка об этом позаботится)
3) Соответственно смотрим результат.
=> Чем я и занялся. У меня CTD в ходе произошел когда отметка используемой памяти приближалась к 3 Гб, поэтому я отправился на тестирование с попыткой искусственно вызвать OOM, приложив для этого все усилия: все настройки на максимум, тяжелая сцена, тяжелый крафт. Максимумы использованной памяти я фиксировал: 3.194 Гб, 3.177 Гб, 3.151 Гб. на «заходе» (в кавычках, т.к. заход был а аркадном режиме) в KJFK от FsDreamTeam, повторюсь на максимально возможных настройках. ФПС «порадовали»
В Дубаях от FSDreamTeam где и произошел вылет, так же тестировал, но там мне не удавалось сделать так, чтобы расход памяти стабильно переступил отметку в 3 гб. (не виртуальной, а физической, речь насколько я понимаю, все время идет о ней).
«Нотариально заверенный скриншот» (
еще раз прошу не обращать внимания на приборы и положения ВС относительно ВПП, ибо не в этом суть) пересечения отметки в 3 Гб. Конечно, полноценным тестированием этого фикса может быть только полноценный регулярный полет на тяжелом крафте, в тяжелую сцену, но в 2 часа ночи этого делать как то не хочется 
Честно сказать, даже не знаю, что и думать. Может ли это быть страховкой от таких вылетов в дальнейшем? Пока, я не нашел аргументов что бы не оставить патченный api.dll в свой системе, хотя тестирование будет еще продолжаться. Так же на просторах Интернета было обнаружено это. Кто что обо всем этом думает? Предлагаю продолжить обсуждение, если, конечно, я не вынес в отдельную тему давно известный баян (в случае чего заранее извиняюсь).
Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 03:31
Я все ближе подхожу к выводу, что это открытие avsim.com -а равносильно открытию панацей вроде HIGHMEMFIX=1 и ему подобных. Странно, что она не является must-have-ом… В общем, пробуйте!
Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 03:42
Сообщение отредактировал Enzzo: 16 December 2012 — 09:38
Stetter (16 December 2012 — 12:55) писал:
Речь идет об x64. У меня сейчас 8 Гб физической памяти. x64 ибо уже является must-have-ом.
Я полетаю с этой dll, говорят, что не только мне она помогла. Посмотрим, что получится.
Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 15:39
Прикрепленные изображения
Zorgair (16 December 2012 — 17:44) писал:
Так ты летел в глубинке так сказать. У меня расход памяти в ходе регулярного рейса возрос до 3000 гб в Дубаях от Тампы и произошел вылет сима после 6 часов полета. А так у меня тоже такие вылеты редкость, но раз проблема проявилась, то её нужно было решить.
Enzzo (16 December 2012 — 18:32) писал:
Теперь у меня комп из разряда «Маст Хэв Фо АЫЧ за 60 руб», разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать…
Согласен, что ловить OOM в ORBX будет сложно. А вот в Анкоридже от а-софта + UT Alaska самое то.
Не знаю, я никогда не летал в FSX на x32 на тяжелых крафтах в тяжелых сценах. Только на слабом ПК с дефолтном баловался.
Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 18:37
Zorgair (16 December 2012 — 18:32) писал:
Одно я знаю, наверняка, теперь от вылетов с «недостатком» памяти я застрахован чуть более лучше. Лишняя страховка никогда не помешает.
Enzzo (16 December 2012 — 18:40) писал:
Знаю. Сейчас вот ставлю Анкоридж что бы проверить окончательно ли я застрахован от ООМ-ов в дальнейшем. С UTAlaska мне не летать по Европе, но лучшего места для проверки нет.
Enzzo (16 December 2012 — 18:32) писал:
Теперь у меня комп из разряда «Маст Хэв Фо АЫЧ за 60 руб», разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать…
А если и буду летать дальние рейсы в Анкоридж, уже на всякий случай поставил UT Alaska на минимум ибо…
Enzzo (16 December 2012 — 18:57) писал:
1.01 на борту
Прикрепленные изображения
Теперь у меня комп из разряда «Маст Хэв Фо АЫЧ за 60 руб», разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать…
Не получится прорваться за 2Гб или 3Гб, в зависимости от того как они были скомпилированы, в 32 битном приложении. И дело не в количестве памяти, а в адресуемом пространстве. Почему так, можно почитать тут: http://wm-help.net/b…64/59464-6.html
Предвосхищая вопрос почему такие цифры и почему под 64 битной win по другому, то если почитать внимательно по ссылке выше то можно узнать, что 32 битное приложение может адресовать 4Гб, но верхние 2 или 1Гб забирает система. Т.е. диспетчер задач показывает общее использование памяти в адресном пространстве процесса.
При запуске под 64 битной системой, в которой 32 битные приложения выполняются под эмулятором WoW64, сильно снижается нагрузка как раз на эти верхние 2Гб и уменьшается вероятность проблем нехватки адресного пространства там, плюс освобождается возможность заюзать 1Гб дополнительно для тех dll, которые это могут. Сам fsx по всем признакам не может видеть более 2Гб.
Сообщение отредактировал НЕБО: 16 December 2012 — 23:49