Xenia

Именно этим и занимаюсь. Просто подумала, что велосипед изобретаю, и кто-то раньше этот путь проходил. К частности - изобретатели механических симуляторов, когда электродвигатели раскачивают/вращают кресло пилота синхронно с самолетом в игре. Для этой задачи является крайне необходимым, чтобы положение самолета в воздухе мониторилось непрерывно без разрывов. Тогда как зашкал на границах первого радиана привёл бы к катастрофическим последствиям, когда при выполнении бочки пилота тряхнуло от одного зашкала до другого, т.е. с +57.3° сразу до -57.3°, где 245.4° градусов в промежутке оказываются потерянными. Да и пилоту не сладко придется, если его на такой угол разом крутануть. Не надо малую проблему раздувать в большую, чтобы найти оправдание для отказа. Я не доки прошу для себя переписывать, а лишь указать верное направление для ее решения. Скажем, если бы я сама была разработчиком и знала ответ на вопрос "как получить непрерывный тангаж?", но мне понадобилось бы не более трех слов, чтобы назвать нужную для этого функцию или метод.

tactview ставила, но ни у нее, ни у DCS-BIOS, нет никакого "своего export.lua" - та и другая вставляют в файл export.lua вызов самих себя. DCS-BIOS вставляет туда вызов своего базового модуля BIOS.lua, а tactview - своего TacviewGameExport.lua. Если проинсталлировать обе, то в export.lua окажутся сразу оба вызова. Больше ничего в этом файле нет! Речь, конечно, идет о файле export.lua, находящимся в директории "C:\Users\?????\Saved Games\DCS\Scripts\Saved Games\", т.к. другой файл с тем же именем несет исключительно справочную информацию и никогда не запускается. Поэтому ваш совет "понять, что там внутри происходит" фактически эквивалентен совету разбираться в коде этих двух программ. И будет большой ошибкой считать, что программисту или программистке достаточно только взгляд бросить на их код, чтобы понять, как эти программы работают.

Я там не только искала, но даже на английском языке туда писала .: и именно там я получила "ценный" совет не изобретать велосипед, а использовать DCS-BIOS с Arduino-библиотеками. Тем не менее, этот форум очень большой, а потому я не могу гарантировать, что прочла на нем всё, что пишут по этой тематике.

Этого недостаточно :). Советы использовать для этих целей программы сторонних производителей наводят на предположение, что у них имеются нау-хау, неизвестные не только заинтересованным пользователям, то и самим разработчикам "DCS World". Тем более что применяемые для добычи данных методы порой граничат с хаком. Положим, что сторонняя программа помогла - нужные данные из "DCS World" извлекла, но тогда начинается бег по второму кругу - встает задача, как теперь извлечь данные из этой программы. Т.к. она свои данные обычно дает либо только на погляд, либо пишет в файл лога, тогда как требуется получать данные (по тангажу и крену) в режиме реального времени с минимальной задержкой. И даже если такая промежуточная программа имеет средства экспорта данных, то все равно она здесь оказывается в роли лишнего посредника. С подобной ситуацией я уже сталкивалась на этом форуме, когда мне предложили такой вариант: поставить стороннюю программу DCS-BIOS, выход из которой через COM-порт присоединить к Ардуине, в которую загружена библиотека "dcs-bios-arduino-library", и добывать данные из игры, вызывая функции из этой библиотеки. Если мысленно сократить этапы, через которые здесь путешествуют данные, то обнаружим, что этот совет сводится лишь к тому, чтобы вместо одних функций добывать данные через другие функции, которые не только еще хуже документированы, чем Export.lua, но и имеют различные имена в зависимости от типа самолета. При таком раскладе кажется целесообразным сторонним софтом совсем не пользоваться (чтобы не плодить посредников), а ... взять разработчиков за грудки и вытрясти из них информацию о том, откуда они берут данные для F2-табло, которое никогда не зашкаливает и единообразно работает со всеми типами самолетов. Или, по крайней мере, получить от них четкую рекомендацию о том, как извлечь правдивые (неурезанные до 1-го радиана) данные по тангажу и крену. Пока же я вижу только следующие альтернативы: 1-ый способ. Использовать экспортируемую функцию LoGetADIPitchBankYaw() и получить искомые данные так: pitch, bank, yaw = LoGetADIPitchBankYaw() Это самый простой вариант, однако полученные этим способом данные оказываются урезанными: у самолета Su-25T крен и тангаж упираются в ограничитель 57.3° (1 рад), а у самолета TF-51D упирается в ограничитель только тангаж, а крен работает на полный оборот. С другими самолетами ситуация с креном и тангажом мне неизвестна, т.к. за них надо денежку платить :). Однако здесь необходимо заметить, что F2-табло для этих двух самолетов показывает крен и тангаж верно, откуда следует, что оно берет данные не через эту функцию. 2-ой способ. Использовать экспортируемую функцию LoGetSelfData(), а из объекта, который она выдает, читать элементы Pitch и Bank. Вот так: object = LoGetSelfData() pitch = object.Pitch bank = object.Bank 3-ий способ. Использовать метод хака из DCS-BIOS - сперва добыть ссылку на "нулевой девайс" (?), а затем прочитать из него элемент по известному номеру: pitch = dev0:get_argument_value(arg_number) К сожалению, узнать, под каким номером находятся нужные параметры, не представляется возможным. Не говоря уже он том, что у разных типов самолетов они, как правило, тоже разные. 4-ый способ. Использовать dll-библиотеку CockpitBase.dll, на это намекает заголовочный файл для языка C/C++ - ccParametersAPI.h Этот путь, по-видимому, подразумевает написание своего собственного dll-модуля, который неясно как следует оформлять, чтобы он заработал. Т.к. примера такого модуля нигде не видно, в том числе и в интернете. Возможно, что существуют еще и другие способы, доселе мне неизвестные. Но хотелось бы хоть какой-то определенности с тем, в какую сторону тут ломиться.

Да, Helios это круто! А у меня наоборот - на самолете летать не хватает нервов, а рыться в программном коде люблю . Не похожа - у меня нет такой бородавки на левой щеке .

Не вижу никакого преимущества TCP/IP над COM-портом, когда игра, DCS-BIOS и программа-получатель информации находятся на одном и том же компьютере. Какой смысл по сети друг дружке депеши слать? Тогда как COM-порт - наиболее удобное средство связи с DCS-BIOS внутри одного компьютера, тем более что альтернативы ему не видно. Однако сама проблема не в том, что связь через COM-порт плоха, а через TCP/IP она станет лучше. Какой интерфейс связи ни возьми, хоть WiFi, BlueTooth или радиомодуль, но если передатчик (он же источник информации) передает данные о тангаже лишь в пределах одного радиана, но это средствами связи исправить нельзя. Спасибо за ссылку - буду смотреть, что это за функции такие .

Несмотря на горячий оптимизм по поводу файла Export.lua , с точки зрения выполняемых им функций, он - ... пустой! А конкретно содержит одни лишь комментарии, позволяющие ознакомиться с именами тех функций, которые способен экспортировать симулятор "DCS World". Т.е. никаких иных функций, кроме чисто ознакомительных, этот файл не несет. Тому свидетельством является как то, что к нему нет никаких обращений из самолетных модулей, так и то, что он может быть безболезненно удален или переименован без малейшего ущерба для работы DCS-BIOS. Что касается функции LoGetADIPitchBankYaw(), то она действительно присутствует в списке экспортируемых функций, с которым нас знакомят комментарии внутри Export.lua. Однако вот парадокс - функция LoGetADIPitchBankYaw() негде не используется (!), кроме как в модуле "FC3.lua" для бесплатного самолета Su-25T. Тогда как все остальные самолеты DCS-BIOS отслеживает без обращения к этой функции (для пущей убедительности "файл FC3.lua" может быть удален, чтобы упоминания функции LoGetADIPitchBankYaw() нигде больше не было). Выходит, что DCS-BIOS замечательно обходится без этой функции, а достает данные по тангажу, крену и всему прочему, каким-то другим путем. Впрочем, даже у самолета Su-25T, чей модуль поддержки содержит вызов функции LoGetADIPitchBankYaw(), на последнюю есть нарекания. Например, этот самолет способен выполнить бочку, когда крен на табло (фото которого приведено было ander'ом) последовательно проходит все 360° (углы свыше 180° считает отрицательными). Тогда как функция LoGetADIPitchBankYaw() выдает крен лишь в пределах радиана в ту и другую сторону (от -57° до +57°), упираясь в крайние значения шкалы. Оправданием тому могут являться недостатки прибора ADI у этого самолета, имеющего ограниченный диапазон индикации, но тогда вопрос выливается в форму, ранее озвученную ander'ом, - как получить данные о крене и тангаже из табло, которое всегда отображает их правильно, даже за пределами шкалы прибора ADI. Что касается github'а, куда меня послали с предыдущим вопросом, то там я обнаружила целых два "конкурирующих" друг с другом проекта: https://github.com/dcs-bios/dcs-bios/ (этот постарше) https://github.com/DCSFlightpanels/ (этот моложе) Сама же до сих пор пользовалась первым из них - так исторически сложилось, поскольку в названии первого есть слово "dcs-bios" - google-поиск нашел его первым. Тем не менее, второй проект я тоже смотрела и с первым сравнивала, но каких-то кардинальных изменений не обнаружила - там и там функция LoGetADIPitchBankYaw() используется только (!) для самолета Su-25T (и его группы "FLAMING CLIFFS"). Теперь удовлетворю любопытство относительно моих целей . Дело в том, что у меня на компьютере есть "Искусственный интеллект (ИИ)" собственного приготовления, который тоже хочет не только полетать (с этим и автопилот справится), но и поучаствовать в боях . Поэтому Arduino мне без надобности - у нее ни мозгов, ни скорости не хватит, чтобы стать ИИ, когда многоядерный десктоп едва с этой задачей справляется (при лимите времени). Поэтому я пока соединила два COM-порта драйвером (виртуальный нуль-модем) и читаю через второй COM-порт тот поток данных, который посылает DCS-BIOS Ардуине. Отсюда и задача тот поток расшифровать. Между тем расшифровка потока оказалась совсем простым делом, но вот полученной информацией я сильно недовольна. А недовольна, прежде всего, тем, что в потоке вижу лишь выборочные данные из приборной панели, не имея возможности получить данные из табло. Т.е. и тут крен и тангаж получаю с углом, ограниченным в 1 радиан. Общую картину я пока представляю так: DCS-BIOS хакает (или получает легально) данные у симулятора "DCS World", а затем рассовывает их по разным адресам (в зависимости от типа самолета и особенностей его приборного оснащения), а затем периодически сбрасывает эту информацию в COM-порт (адрес-длина-блок данных). Тогда как Ардуина (а точнее ее библиотека) со своей стороны "фильтрует" этот поток, вызывая местные функции, связанные с теми адресами, которые ей знакомы. Отсюда возникает та трудность, что у каждого самолета эти функции называются различно, и нигде не видно разъяснения, к чему эти функции относятся. Например YAW есть у самолета Su-25T, тогда как у TF-51D этот параметр нигде не упоминается. Или, скажем, у самолета F-16C есть функция "YAW TRIM Knob", но, судя по названию, это кнопка, а не измерительный прибор. И таких функций с витиеватыми названиями, неподдающихся расшифровке, там масса. Однако на сегодняшний день наиболее актуальным для меня является получение данных по тангажу, чтобы мертвую петлю можно было контролировать на всех ее этапах, а не только в пределах одного радиана.

Hi, I’m new here :). Never thought I’d have to ask advice on a forum, thought I’d somehow manage myself (I’m on first-name basis with electronics and programming, I’d like you to know). As it turns out, I suck at plane-building :D. I’ve tried working with DCS-BIOS by analyzing the data stream sent to the COM-port. It looked simple, packages consisting of “initial address” and some amount of different data stored at said address and following it. Addresses are always even cause DCS-BIOS always transfers data through a 16-bit word (2 bytes). I think DCS-BIOS just transfers data bits from a game’s memory block. What I don’t get is how it cuts up those memory bits for transfer. Some entries looked paradoxical to me. For example, the name of the plane «Su-25T» (it starts from zero point) sometimes get sent starting from 3rd and 5th letters (?!), capturing pointless bytes outside the line. It’d be complete nonsense if DCS-BIOS understood what it even transfers. Otherwise, it'd send not some memory bits, but data related to specific plane instruments. I think it’s obvious that it itself doesn’t know the meaning of these numbers and tries to send the bits of a memory block which data changed since the last transfer. For example, it sends the «time meter» (FFFE) every time when it increases by 1, while the name of the plane is rarely mentioned. My problem is how bind the addresses to specific measuring instruments in the cockpit. Specifically, I'm only interested in two parameters - roll and pitch. At first I hoped that I would recognize the roll and pitch from the changes that occur when flying the aircraft. However, it turned out that even in free flight, when I do not touch any controls with my hands, a lot of the data transmitted by the DCS-BIOS changes over time, some of them quite significantly. In short, I could not identify the roll and pitch in the data. Hence my question to the forum users: does the DCS-BIOS give information about roll and pitch to the COM port, and if so, where can I look for it? Ideally, I would like to be poked with my nose into the information where the binding of devices to addresses would be written, instead of referring to some sketches that supposedly know everything and can do everything :). But in the worst case, I also agree with the sketches.