Valery Blazhnov

В принципе, пользователю можно дать возможность динамического доступа к значениям параметров из скрипта - и пусть развлекается. Однако, не следует забывать, что подгрузка графических ресурсов не всегда может выполняться мгновенно, поэтому такая настройка будет нетривиальным занятием. Поэтому потока претензий типа "А почему бы не сделать, чтобы автоматически было все шоколадно?" это не остановит.

По сути правильное замечание, хотя достичь требуемого минимального FPS не так-то просто. Иногда движок будет вынужден, как говорится, резать по живому, загрубляя полезную визуальную информацию.

Независимо от того, что и как мы делаем, всегда найдутся люди, которые хотят того, чего не бывает :)

Требовать одновременного выполнения экстремальных настроек - это то же самое, что утверждать, что у автомобиля на максимальной скорости должен быть обеспечен также минимальный расход бензина. Дело не в ЛокОне, он в любом случае свой век доживет таким, какой он есть. Дело в элементарной логике, которая применима к любому регулируемому продукту. Многие опциональные параметры влияют друг на друга и не позволяют достигать экстремальных настроек одновременно. А некоторые вообще являются взаимно исключающими. Совершенно непонятно, почему идея-фикс "хочу все и сразу" должна серьезно рассматриваться.

Не понял, к чему комментарий, раз уж ты цитируешь?

Неправда. Если пример с автомобилем не убедил, то выкрутите в графической карте все параметры на максимум и запустите любую мало-мальски продвинутую графическую программу с максимальными настройками - она у вас встанет колом. Это правило введено по требованию пользователей, которые настаивали на разнообразии опциональных предпочтений. IMHO вполне разумное требование.

И не будет придумана никогда. Максимальные настройки не для максимального железа, а для того, чтобы жертвуя одним, можно было опционально выигрывать в другом. На автомобиле никто постоянно на максимальной скорости ездить не сможет, однако никому в голову не приходит предъявить изготовителям претензии по этому поводу.

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

Разговор, в общем-то пустой, потому что старый движок никто существенно оптимизировать не будет, а нового еще никто из присутствующих не видел. Никакого влияния на FPS в ЧА данное обсуждение оказать не сможет. Все сказанное давным-давно известно разработчикам.

В файле Config/View/Server.lua нужно изменить функцию GetRearCameraPosition, заменив там константы на соответствующие смещения в метрах. Кроме того, возможно, понадобится изменить и другие параметры данного вида, отвечающие за начальное направление камеры и за угловые ограничители ее наклона (они заданы перед функцией): hAngleRearDefault, vAngleRearDefault, vAngleRearMin, vAngleRearMax. На другом компьютере трек не будет правильно проигрываться, если там другой Server.lua.

Нет, не секрет, он выйдет по мере готовности :)

Графический движок в 1.2 тот же самый, поэтому радикально в этом смысле ничего не изменится. И это хорошо, иначе FPS просядет капитально. Но этот "застой" продлится недолго, потому что новый движок тоже успешно разрабатывается. Вот с ним значительно продвинутся и ландшафт, и эффекты.

Не игра, а графический движок. Рано или поздно он будет заменен в симуляторе. Соответственно, и ограничения DX 8.1 будут сняты.

Какие конкретно "эффекты" имеются в виду? Дело в том, что DX SDK - это интструмент разработки программ, а не набор готовых эффектов.

Будет, но наблюдать его нельзя, поскольку соответствующая операция с текстурами не предусмотрена, и вблизи солнца луна не рисуется :)

Ну, а куда ж мы на фиг денемся с "подводной лодки"? :)

Ну, тогда и лететь никуда не нужно - свой домашний "МАКС" в ближайшее время гарантируется :)

В смысле, на своем самолете? ;)

Ничего страшного не произойдет. Скриншоты тоже есть подлинные и редактированные в фотошопе - никому это сильно не мешает. Проблему подлинности треков можно решить и другими способами, если это будет актуально.

Двигается и мышкой и клавиатурой. На паузе у мышки в свободной камере не работает только колесико-акселератор, потому что он на время завязан, которое на паузе остановлено.

Странно, только что проверил в режиме редактирования трека - свободная камера чудненько двигается на паузе.

Камеры заранее расставить тоже можно. На каждом аэродроме имеется своя отдельная камера, которая только изначально привязана к нему. Ничто не мешает заранее переместить несколько таких камер в соответствующие точки пространства вдоль маршрута самолета, чтобы затем переключаться на них клавишей F11, когда это необходимо. Обычно такие операции делаются в режиме редактирования уже записанного трека на паузе, при нажатой клавише 'S', тогда в отредактированном треке они будут незаметны. Также не паузе из вида F2 можно нажать Ctrl-F11, переместить камеру в нужную позицию, повернуть в сторону застывшего в воздухе самолета и отжать паузу. В треке получится, что камера как-бы заранее оказалась в нужном месте.

Наверное, ты хотел сказать Ctrl-F11? Ctrl-F10 переключает в вид F10, центрированный в текущей позиции камеры. Кстати, Ctrl-F11 работает и из вида F10, если кто не знает.

Самый простой способ переместить свободную камеру на нужный аэродром - это долбить F11, пока нужный не появится. Прямое переключение можно сделать по-другому: жмем F10, мышкой тыкаем на нужный аэродром и затем жмем F11. Кстати, так же можно переключаться и на объекты, тыкая в их иконки на карте и нажимая затем F2, F7, F9 или F12, в зависимости от типа объекта. Для слежения за самолетом во внешних видах имеется падлок (Numpad Del), который захватывает ближайший к линии визирования самолет. Читай Doc/KeyCommands.doc - там кое-что на эту тему написано.

Треки в ЛокОне сравнительно просты, малы и пишутся незаметно, потому что в них запоминаются только управляющие воздействия пользователя от устройств ввода, а не список всех событий и изменений позиций объектов. Поэтому трек - это не рельсы на выходе, а наоборот - интерпретация потока входных воздействий. Естественно, результаты такой интерпретации зависят от версии интерпретатора, т.е. - симулятора. Нас самих достает необходимость постоянно перезаписывать тренировочные треки, поэтому мы постараемся в будущем изменить принцип записи и интерпретации треков.