BR55Sevas

Получится болванка без систем, способных взаимодействовать с миром игры. Т.е. нельзя никак на своем радаре получить координату другого самолета в игре. Нельзя получить положение своего самолета относительно приводных систем в игре. Нельзя в своем самолете управлять своей ракетой. Всё остальное можно -своя физика полета можно, кликабельность кнопок - можно, своя логика физика систем (за исключением тех что нельзя) самолета - можно. В итоге можно самолет, которому не нужно оружие и всякие GPS и радары. Не тратьте свое время на создание какого-нибудь более менее сложного самолета в DCS. Нелетабы не рассматриваю.

Бесполезная трата времени и сил. OPen Api не позволяет взаимодействовать с объектами, приводами, координатами в игре и т.д. Можно сделать только летающую болванку без навигации, радаров и прочих важных систем.

Смените ip-адрес 127.0.0.1 в export-e на адрес вашего второго компьютера в сети.

А, тогда ок.

I think this method not works with DCS.

Custom gauge animation makes by lua. No need DirectX routine. But there are no SDK, no guidelines about here... Here my tests with my own custom HUD and MFD animation. How I did this? I`m lazy to describe it :) All info look for at current ED`s modules. Radar operation impossible for modders. Current open API not support radar/weapon/GPS systems.

Клончика бы деанонимизировать. ну или кто там дубля сделал. плюсануть хочу :D

Поддерживаю GK. Кривым моделям кривую тему, дефолтным моделям дефолтную тему! :D

Нельзя, там материал не предназначен для рисования. спрашивали уже у GK.

Это слишком грубое сравнение, имхо даже неуместное. Арифметика может одна и та же, но подход к моделированию разный. Это как попросить кого-то нарисовать объект, один нарисует его карандашом, другой красками. В обоих случай модель (рисунок) воспроизводит объект, но разница в моделях налицо. С самолетами тоже самое - есть разные методы моделирования, один другому рознь. Сравните, если конечно до такого опуститесь, метод тяг и методом мощностей. Или более трешевый вариант - разложите циркуляцию по Кутту-Жуковскому, вроде так называется. Может YoYo уточнит. Или попроще - как рассчитать эффективный УА с учетом геометрии? Формула то одна и та же, но крыло то разное, получится что разные крылья по одной формуле дадут разный результат. Я в этом аматор, но очевидно одно - методов много, какой-то дорогой в плане вычислительных дел, какой-то проще, но грубее и т.д. Ясно, что разные разработчики будут делать так как могут, возможно даже идут на компромисс между производительностью и точностью. Не делите мир на только черное и только белое, всё где-то между, и мы там :D

Похоже и тему тоже :D

Особо не слежу за новостями. Подскажите кто в курсе - автор обещал более менее цивильную коллизию объектов?

Pls, don`t use googletranslator in your posts. With russian it works bad. Just add original english text.

http://forums.eagle.ru/forumdisplay.php?f=202 Не тратте своё время, создание модулей для DCS бесперспективно. нет ни документации, ни полного функционала. даже небоевой полуфабрикат сделать та еще задача.

Да, конечно, если делать, то с учетом всех авторских дел - летать могут только купившие кампанию.

Сделайте возможность в платных кампаниях изменить слот игрока и его подопечных на клиентов, интересные миссии иногда хочется в коопе полетать.

Еще вспомнил одну проблему. Вытаскивать параметр через анимацию правильно можно не всегда. Проблемы точно возникнут при многопредельных приборах. Скажем высотомер и его стрелка, отсчитывающая метры. Или тахометр миг-15. при разных высотах, скажем 500, 1500, 2500 м, метровая стрелка всегда будет в одном и том же положении, т.е. никакая интерполяция не поможет. Ладно метры. Теперь берем тахометр миг-15. стрим- Шкала спаренная, т.е. стрелка что при 2000 об/мин, что при 12000 об/мин в одном и том же положении. Экспорт вернет два одинаковых значения. Как вы узнаете, какие же на самом деле сейчас об/мин? Это проблема, здесь даже Советский Рик и другие программисты не помогут. Для них это геморрой, нужны отдельно делать что-то типа флага, который укажет что прибор перешел во второй диапазон работы, причем этот флаг опять же надо как-то пропихивать через экспорт. Имхо, это в ближайшее нерешаемо ни со стороны ЕД, ни с нашей. Можно конечно лезть в память, искать где эти параметры находятся и оттуда их сливать, но это уже извращенство. Врядли кто-то из простых юзеров это осилит.

Простите, не удержался :D

Исходные данные Engine_RPM.input = {0.0, 500.0, 1000.0, 1500, 2000, 2500, 3000, 3500, 3600.0} Engine_RPM.output = {0.0, 0.032, 0.082, 0.206, 0.390, 0.601, 0.789, 0.961, 0.983} input это это конкретная физическая величина в единицах измерения, тобишь об/мин. output это безразмерный коэфициент, лежащий в пределах от 0 до 1, где 0 - начальное положение стрелки прибора, 1 соответственно максимальное. игра экспортом как раз и возвращает эти величины от 0 до 1. Для перевода в нужные нам об/мин. нужно. Построить график соответсвия об/мин его известным безразмерным значениям коэфициента положения стрелки. Как видим зависимость явно нелинейная, если попытаться построить уравнения прямой по ней, то получим значительные ошибки Поэтому есть 2 варианта как сделать перевод точно. По научному эти все уравнения называют по разному, где-то аппроксимация, где-то регрессия и т.д., но суть одна и та же. Кусочно-линейная аппроксимация. Разбить на линейные участки зависимость, и для каждого участка строить свое уравнение. Тогда в ваш код экспорта нужно будет написать примерно так Тогда, отправляя в сокет Engine_RPM_REAL вы получите уже об/мин. Аппроксимация полиномом С полиномом все несколько проще, вместо кучи уравнений используем одно длинное. Единственное что нужно очень внимательно посмотреть на график, красная линия это именно наше полиномиальное уравнение. чем оно ближе к исходным точкам тем точнее результат, варьируя степень полинома, можно получать разное приближение. Может получиться так, что на каком-то участке полином идеально впишется в исходники, а где-то вылезет. Тут все индивидуально. В экселе это делается в графиках, добавляете линию тренда и отображаете её на графике. От себя добавлю, что если использовать линейную аппроксимацию, то в экспорт это кучу пихать неудобно, лучше все таки принимать положение стрелки, а в вашем хосте уже заниматься его переводом в нужные единицы описанными выше способами.

Напишу к вечеру пост, тут без поллит.... без картинок не разобраться. ожидайте. :)

Если есть готовый экспорт, то выкладывай. посмотрю и покажу. желательно с одним параметром для простоты. Есть 2 варианта, простой, но объемный - кусочно-линейная интерполяция с кучей if-оф в коде. либо более научный - интерполяция полиномом, с расчетом коэффициентов методом наименьших квадратов. тут меньше кода но может быть больше погрешность на краях диапазона. Страшных слов боятся не надо, все автоматом можно посчитать в том же экселе или в спец программах.

Разработчики много раз говорили, что экспорт в стадии, но не в первой по понятным причинам. Что же до экспорта с модулями внешних разработчиков, то на кошках можно потренироваться на других модулях, скажем тот же ми-8 или хок, с 101м. Врядли 15й станет исключением. К параметрам придется обращаться через mainpanel, и делать пересчет по интерполяции будильника указанной там же. Точно не помню, но там должно быть чтото вроде input[0,0.5,1] output[0,300, 450] то есть нелинейная шкала переводится в угол проворота анимации стрелки. Я с этим не эксперементировал, но вроде как это должно работать именно так.

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