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-гладкости (т.е. непрерывности).

Выгоды будут, стоит лишь попробовать. Только осторожно. Например, человек уже указывал на то, что если в жизни самолет виден на высоте 8000 м с земли как силуэт, то он должен бы был быть виден и в симуляторе как силуэт, пусть даже с геом. точки зрения он и занимает всего один пиксел... Ну увеличить его слегка!.. А на близких дальностях -- порядка пушечной -- рисовать его в нат.величину.

Отнюдь. Речь же идет о том, что если, скажем, игрок одновременно видит дерево в 500 м и самолет в 1000 м, и оба они имеют одинаковый угловой размер, то сейчас они на экране и рисуются одинаковой величины -- одинковое кол-во пикселей. Хотя самолет находится вдыое дальше (и сам он вдвое крупнее). А должно быть не так -- размер объекта на экране (в пикселях) должен быть функцией от его углового размера \alpha и расстояния r: f(\alpha, r). И если \alpha в обоих случаях одинаково, то r-то -- разные! Вот и все. При чем тут размер экрана?.. При изменении фокусного расстояния клавишами * и / все будет меняться -- это же просто гомотетия... Реализовать это можно было бы так: при изменении расстояния прорисовываемого объекта (самолета, скажем) от игрока он "раздувается" с опр. коэффициентом (гомотетия просто), а остальное (отрисовка) ложится на граф. процессор. Может быть, можно и как-то иначе...

Видишь ли, Чиж, то, о чем НА САМОМ ДЕЛЕ говорит человек (возможно, не подозревая об этом), заключается в том, что зрение человека (и то, как он мозгом обрабатывает картинку на сетчатке глаза) устроено так, что видимый размер объекта НЕЛИНЕЙНО зависит от его (оптического) углового размера. И эта нелинейная зависимость давно известна. А открыл это поконый Раушенбах Б.В. Вот видимо неучетом этого обстоятельства в ЛокОне (и всех других симуляторах) и объясняется то, что очень многим людям (и летчикам в частности, с которыми я разговаривал) многие объекты кажутся либо слишком большими, либо слишком малыми, хотя с точки зрения проективной геометрии все и верно. Достаточно данную нелинейную зависимость ввести -- и дело с концом. Об этом я, кстати, Блажнову говорил.