xogok

Коллеги, довольно давно уже я захотел сделать анимированный gif авиагоризонта, показывающего самолёт, выполняющий косую петлю. Сперва хотел попросить кого-либо из матёрых симуляторщиков записать мне соотв. трэк в ЛокОне, а потом сконвертить в gif, но по зрелом размышлении отверг этот путь как сложный и бесперспективный. В итоге принял решение отмоделировать манёвр и нарисовать авиагоризонт самостоятельно. Нарисовал в Wolfram Mathematica в векторной графике, результат можете увидеть тут: http://scilib-avia.narod.ru/Mednikoff1/index.html Это уменьшенная версия, оригинал крупнее, но за счёт векторности графики всё масштабируется пристойно. В принципе, результат достигнут, и люди говорят, что неплохой, но нет предела совершенству. С самого начала хотелось нарисовать максимально реалистичную приборную панель со всеми этими болтами, проводами, отверстиями, с выпуклостями и выемками, бликами и т.д. Вручную всё это рисовать чрезвычайно муторно и не совсем понятно как, а самое главное - кустарщина это, и совсем не нужная, поскольку соотв. текстуры неподвижных частей прибора уже есть - в ЛокОне. Я полез туда, нашёл файл CockpitsTexturesTGA.cdds, скачал утилиту LoTextureTool и выдрал текстуру авиагоризонта. Результат меня разочаровал: картинка получилась 256х256 - очень мелкая, и не анфас, а под углом. Что-то делаю не так, наверное. С другой стороны в папке /LockOn2/Bazar/TempTextures/ есть файл Dash-board.tga, в котором текстура авиагоризонта присутствует, причём в хорошем разрешении. Беда только в том, что это авиагоризонт А-10-го, который меня пока не интересует. Но качество этого уровня меня бы устроило. В общем просьба такая: не мог бы кто-нибудь сделать для меня текстуру неподвижных частей авиагоризонта и прилегающих к нему участков приборной панели? Подкладывать картинку под движущиеся части я в Wolfram Mathematica уже, вроде, научился.

Отрывок из письма Блажнову: "нашел один стабильный баг, который у меня приводит к крэшу ЛокОна. Когда в редакторе миссий создаешь новый самолет/авиагруппу, то справа появляется меню с кучей полей (тип самолета, название группы и т.д.), в частности "Номер самолета" и "Из" (общее кол-во самолетов в группе) -- цитирую по памяти. Эти надписи сопровождаются окошками для ввода/отображения числовых значений этих параметров. По-видимому, они предназначены лишь для отображения, а не для редактирования (а изменять их предполагается кнопками < и >), но вот тем не менее мышью можно в эти поля ввода щелкнуть, и в них появляется мигающий курсор. Но когда введешь туда что-нибудь -- ЛокОн вылетает с ошибкой. Еще забавный ляп (даже не забавный, а тревожный). Я сначала по ошибке скачал с сайта ЛокОна английский мануал и стал читать его, а затем уже с самой игрой пришел ко мне русский вариант. И я обнаружил разительное расхождение в описании топливомера. В английском варианте сказано: "The Flow Gauge (P) shows the rate of fuel consumption", что я перевожу так: "Расходомер показывает _скорость_ потребления топлива". Т.е., по идее, получается, что показания этого прибора жестко завязаны на положение РУДа: двину я его вперед -- расход топлива увеличится, скорость его потребления возрастет -- расходомер дернется вверх. Такое поведение возможно, но довольно бессмысленно, т.к. об эом параметре можно было бы судить, например, по указателю оборотов или по самому положению РУДа. Я удивился -- но и все. А вот в русском мануале на этом месте написано другое. У меня его сейчас нет под рукой, но там написано, что расходомер показывает все-таки остаток горючего, но вычисленный исходя из его расхода. Что представляется более разумным (вспоминается история про гибель Федотова и пр.). Посему: 1) Как же все-таки правильно? 2) Поскольку верных версий среди этих двух -- не более одной, то следует, наверное, в каком-то из мануалов неверную версию поправить. 3) И вообще, я этот пункт расписал бы подробнее. Поскольку приборы основаны на разных принципах -- это надо пояснить, и кроме того не совсем понятно все же, как интерпретировать показания этого (комбинированного) прибора."

Это верно конечно, я говорил лишь об акценте на этом аспекте. Тем более, что: 1) вообще говоря не всегда свежайшие драйверы -- наилучшие. Бывает, что в поздних версиях отключают какие-то функции, или производительность падает (так было уже не раз). Так что не всегда и надо пользоваться самой свежей версией. 2) когда версия 1.00 на машине идет, а версия 1.02 -- нет (а ведь 1.02 -- это же просто патч, исправление ошибок), то знаете -- на драйверы думаешь в последнюю очередь. Ну, по крайней мере, не в первую. Ибо движок же не переписывался!.. Я понимаю, что в данном случае был неправ, но люди могут так рассуждать. И вот чтобы направить их мысли в правильное русло -- можно было бы что-нибудь такое и черкнуть. Но дело вкуса, конечно.

Вот это тема!! А вы реализм, земля круглая.... Слава богу ED до такого не додумались.... Ну, а что?.. В принципе... отправить Су-27 (или МиГ-29) в Корею или Вьетнам и посмотреть, что бы получилось... было бы забавно. Или в Египет (Сирию). :-) Хотя, как всегда, есть более простое решение, по типу "Нет уж, лучше вы к нам." Фантом в ЛокОне уже есть... :-) Добавить МиГ-15 и Сейбра -- и развлекайся себе... :-) Только уговаривать себя постоянно придется: "Я в Корее, Я в Корее, Я в Корее..."

Так, всем спасибо, проблема решилась. Причем решилась тривиально: переустановкой видео-драйверов (были референстные 22.08, стали Detonator 53.03). Понятно, что в плане производительности или качества картинки они моему GeForce 2MX400 ничего не дали, но, видимо, "заглушки" там стоят на своих местах. Зато под это дело нарастил память компа до 512М. Разработчикам -- предложение: пополнить мануал к ЛокОну (раздел troubleshooting) фразой наподобие такой: "Перед запуском убедитесь, что у вас установлена новейшая стабильная версия DirectX и самые свежие видеодрайверы -- даже если ваша видеокарта не относится к числу самых современных. Известны случаи, когда одна версия ЛокОна запускалась со старыми драйверами, а последующие -- нет (хотя оборудование оставалось неизменным). Последующие версии игры могут использовать новейшие возможности видеодрайверов даже если они и не поддерживаются на вашей системе аппаратно (в последнем случае используются "заглушки")." Т.е. донесите эту простую мысль до пользователей. Ибо недоумению моему не было предела.

Вы как-то несерьезно подходите к вопросу... Причем тут "глобус причерноморья"??? Но ведь ТВД у нас уже довольно приличный по размерам (уже не только Крым), и в реальности уже возникают вопросы самолетовождения (летать по ортодромии, локсодромии и т.д.) Я про это спрашивал, а вы переводите все в какой-то невменяемый треп. Не брызгайте слюной, на вопрос ответьте.

Как сообщество, хочет, чтобы в будущем в продуктах от ED Земля была круглой? Или это неинтересно (несущественно), и пусть она остается плоской как сейчас? Я -- за круглую Землю.

Да по-моему, на 9.0, хотя... проверю. Понимаете, ведь 1.00 шел же и так, этот-то почему не хочет???

Может, ссылочку дадите -- чтоб вас не напрягать?

Уже. Это было первое, что я попробовал. На раб.столе было 32 бита, летал я в 16-ти. Переделал раб.стол в 16 бит -- та же шняга. Насчет .cfg-файла -- попробую. Кстати, а с каким DirectX'ом версии 1.02 живется наиболее комфортно? 8.1 или 9.0 или еще более новой?..

Описываю ситуацию. Моя машина: Celeron 1000MHz, video GeForce 2MX400 (64Mb RAM), винт 120Gb, Windows XP SP1 и... 256М RAM. Машина старенькая конечно (покупалась еще под Flanker 2.5), но, как ни странно, LockOn 1.0 на ней пошел, и пошел УДОВЛЕТВОРИТЕЛЬНО. Конечно, без красот и шейдеров, но... летать можно было. Чему я был несказанно рад. Ставлю патч 1.02, русский (1.0 --> 1.02). LockOn запускается, но модуль симуляции не работает -- выдает ошибку и вылетает. Что-то системное, кажется в модуле dxrenderer. Ага, думаю, понятно, программа стала более требовательна к ресурсам -- вполне естественно. Первое, что легче всего изменить -- объем памяти. Вчера поставил еще 256М, доведя объем памяти до 512М. Замечу, что в клубе мы на таком объеме памяти летаем, и вполне прилично. Дома же у меня ЛокОн ведет себя ровно так же, как и до наращивания памяти -- как будто ничего и не произошло. Вот я и думаю -- в чем же дело? Видно, не в памяти... но в чем же тогда?.. Уж и не знаю, что думать. DirectX? Какие-то XML-ные примочки? Что-то еще?.. Вопросы: 1) кто эксплуатирует LockOn на похожей системе -- поделитесь опытом. 2) Разработчики: что можете подсказать в такой ситуации? Валеру мне уже совестно спрашивать, поскольку своими письмами я его, должно быть, уже достал. Может, Chizh поможет?... Помогите, у меня во вторник зачет по сложному пилотажу, а мне еще тренироваться надо, чтобы его сдать!!!

Это-то как раз легко. Забитые в самом начале установки делаются умолчательными, и при подключении к сети все установки, "накрученные" пользователем, автоматические принудительно сбрасываются в умолчательные (ему об этом даже не надо сообщать). Все, все летают на одинаковых машинах, все довольны, читерства нет. В оффлайне -- пожалуйста, делай что хочешь.

Коллеги, не знаю, обсуждалось ли это уже здесь, но хочу поделиться с вами безрадостным наблюдением и предлагаю вместе подумать над тем, как в принципе можно было бы улучшить ситуацию. Рассмотрим линейку симуляторов Flanker 1/5 --> Flanker 2.01 --> Flanker 2.5x --> LockOn В этой последовательности шло планомерное усложнение кабины, увеличение ее сложности, красоты, приближение к реализму и... ухудшение условий работы с ней летчика. Приборы становятся все менее и менее читаемыми и сейчас работать со многими практически невозможно. Мелко, да и тестуры размыты. Особенно это касается ПНП -- его подвижной шкалы (единственной, кстати, среди всех приборов!) и стрелок. В Су-25 я, например, не могу отличить один конец стрелки АРК (с кружком) от другого при стандартном угле обзора 70 градусов. Нет, конечно, если включить увеличение (уменьшить угол обзора) -- тогда ЭТОТ прибор будет прекрасно виден... но только он, и пилотировать станет невозможно. Чего, в общем-то, и следовало ожидать -- размер монитора значительно меньше размера реальной кабины, и при приближении приборной панели к реальности читаемость ухудшается. Но можно ли здесь хоть что-то сделать, хотя бы в принципе, имеющимся в нашем распоряжении набором средств? Я предлагаю подумать нам над этим и донести наши размышления до разработчиков, чтобы тем было известно, чего хочет community, что оно считало бы удобным. Мои мысли: 1) Надо иметь возможность быстрого взгляда на конкретный прибор. Не так как сейчас, по нажатию на NumPad-0, когда угол обзора не меняется, а так чтобы и угол менялся. Т.е. сделать функцию "snap-view" -- и чтобы пользователь настроил ее: как, под каким ракурсом, в каком увеличении он хочет видеть прибор (группу приборов), и пусть он повесит ее на какую хочет клавишу. И по нажатию на нее ему включался этот вид, а по отпусканию -- вид возвращался в исходный. 2) Модификация 1) -- все то же самое, но вид не изменяется, а, скажем, конкретный прибор "всплывает" снизу на панели увеличенный. Отпустил -- он исчез. Это удобнее, т.к. позволит видеть одновременно и закабинное пр-во и данный прибор, причем в читаемом варианте. 3) Имеющийся сейчас квазинепрерывный способ перемещения головы по кабине конечно красив, но на практике малополезен. Ибо голову в бою надо вертеть БЫСТРО и, как правило, в фиксированные положения (я не беру сейчас режим ШЛЕМ, для этого пэдлок существует). Я не предлагаю от этого способа избавляться -- он кое для чего годится, но хотелос бы дополнить его фиксированными видами а-ля Flanker 1.5, когда по нажатию на ту или иную клавишу голова поворачивалась в опр. положение и оставалась там. Теперь же это фиксированное положение головы можно было бы сделать настраеваемым пользователем. Такие у меня мысли. Что ВЫ думаете по этому поводу?

Да, чтобы не быть голословным, приведу здесь линк на краткое изложение пропагандируемых здесь взглядов. http://fotoclub.udmlink.ru/?m=14&id=24 Почитайте, интересно.

Совершенно верно! Но, Ди, неужели ты думаешь, что разработчики об этом не знают?.. Я говорил об этом, и причем самому Валере, и к книге Раушенбаха отсылал. Так что, имеющий уши -- да услышит. Наверное это действительно сложно... или не до того им... Но хотелось бы. Мне кажется, так не пойдет, зависимость должна быть непрерыной, иначе при переходе из зоны в зону возникнут внезапные "скачки" -- объекты будут мгновенно меняться в размерах. Впрочем, никто не говорит, что зависимость должна быть гладкой, на первых порах достаточно C^0-гладкости (т.е. непрерывности).