Как можно получить данные из игры?

[Swift_CCCP]

Давно собираюсь создать внешнюю панель приборов.
Как функциональную так и информативную.
Но если с функциональной панелью(тумблеры, кнопки итд)
более менее понятно, то с информативной панелью начинаются проблемы.
Вернее проблема одна но большая. Данные- откуда брать?
Разработчики Ил-2 сылаются на то что, если открыть доступ к ресурсам
где показывается скорость,высота, обороты итд,то нарушится безопастность
программы и читеры начнут эти данные использовать в своих корыстных целях.
Разработчиков LockOn данными вопросами не озадачивал.
Засела эта мысль в башку и придумал следущее.
Если разработчики создадут какую нибуть infopribor.dll и там будут
копии данных( изменяющиеся естественно с течением игры) то можно ли будет
с помощью этого файла "нарушить игру"? Я думаю, что нет.
Если это действительно не повредит игре, то сложно ли создать такую DLL?
Много человеко ресурсов это не отнимет, а уж панель можно будет забабахать ого-го
какую!!!
Пример номер 1.
Полно старых ноутбуков по бросовой цене(100-150$)
подцепляем его к своему основному компу и выводим на него
хоть приборы, хоть карту, да что хочешь.
пример номер 2.
подключаемая LPT port LCD panel
http://www.madalf.ru/modding/modone32.shtm

НО ДАННЫХ КАКИЕ НУЖНО ВЫВОДИТЬ НЕТ!
Вы мне скажете а как ты это все будешь реализоввывать?
Да найдем как. На форуме умных людей полно.
Вопрос только к разработчикам ИЛ-2 и LockOn
дайте возможность получить данные из игры законным способом,
а мы уж сами сделаем с этими данными что нужно.

Спасибо за внимание.

[M@troskin]

Originally posted by Swift_CCCP
Давно собираюсь создать внешнюю панель приборов.
Как функциональную так и информативную.
Но если с функциональной панелью(тумблеры, кнопки итд)
более менее понятно, то с информативной панелью начинаются проблемы.
Вернее проблема одна но большая. Данные- откуда брать?

Для MSFS такая приблуда есть, берет она данные откуда-то из кишок игры, отдает любому девайсу в нужном виде, называется FSUIPC.DLL.
Давайте Чижа спросим - может, можно такое сделать и в нашей игре? Мне не кажется, что это не слишком сложно - ведь в игре эти данные есть, раз они обрабатываются/выводятся на экран? Просто отдать их в некоем виде внешней проге... А она уже пережует и выдаст на показометры.
Я сам размышлял над этим вопросом, глядя на всякие приборные панели, часто попадающиеся в интернете, и пытаясь прикинуть, КАК можно сделать самому настоящий работающий командно-пилотажный прибор Су-25 и офигевая от ужаса...
Хочу сделать кокпит Су-25! Настоящий... С кнопочками, тумблерочками и приборами...

[Фагот]

Аналогично. В свое время для Фланкера делал приборную панель. Хотел собсную прогу писать, чтоб данные снимала. Не вышло. Панель враги выкинули. Ежели разработчики сделают что- либо подобное- будет просто замечательно.

[Valery]

На такую работу нужно написать небольшое ТЗ, в котором описывались бы соответствующие программные интерфейсы. И прислать мне (valery@eagle.ru), а мы рассмотрим и подумаем.

[Swift_CCCP]

Спасибо за ваш ответ. Определюсь более четко и отпишусь.
Господа вирпилы по активнее идеи нужны в темпе!!!

[Hruks]

А ведь Локоновцы глядишь сотворят чего! Очень хочется чтобы и Иловцы тоже

Я бы не отказался на чтение иметь:
показания всех приборов (не только приборов а все данные, а то вдруг на каком пепелаце нету чего-нить), координаты самолёта, действующие в данный момент силы.

На запись и чтение - все органы управления, а также положение головы не только оси вращения, но и смещения!
Вот!

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

Губозакатывающую машинку где взять?

[Valery]

Originally posted by Hruks
Губозакатывающую машинку где взять?

В очередном ратче

[Alezz]

Originally posted by Hruks
А ведь Локоновцы глядишь сотворят чего! Очень хочется чтобы и Иловцы тоже

Присоединяюсь- хотя бы данные с основных приборов Предел мечтаний, чтобы ЕД и МГ договорились о едином формате вывода данных. Тогда одну панель приборов можно будет юзать сразу в двух симах

[Swift_CCCP]

Это копия письма которую я отправил Valery.
Здравствуйте Валерий.
Те вопросы что я затронул на форуме могут быть решены несколькими путями
1. Клиентская DLL.
или да же две..
in.dll - это то очем говорил Hruks, туда можно помещать данные с обратной связью, то есть которые можно изменять.
Hruks и Alezz чень хорошо поднатарели по расшерению возможностей обзора в ИЛ-2 и эти наработки
успешно используем и в LockOn.
out.dll это те данные которые сообщают о состоянии самолета и сли открыть в игре к ним доступ напрямую то читеры
этим несомненно воспользуются. Поэтому данные в этой библиотеке должны быть паралельны данным в игре, но их изменнение
ни чего не даст. Только мониторинг. Так сказать вариант защиты.
2. Поддержка 2 монитора с выводом на него осносных приборов необходимых в каждом режиме полета.
К примеру 1. Режим навигации, марша и посадки. На втором мониторе должна отображатся карта, указатеть топлива высоты , скорости в общем то, что нужно в этом режиме. Формат приборов был бы интересен как на главной странице LockOn.
Пример 2. Режим ДВБ
На втором мониторе выводится радар, какие подвески выбраны, указатель наравления излучения итд.
Либо настраиваемая панель.

Чем хорош Вариант 2? Тем что все делаете вы, а мы только даем советы и ругаемся на форуме.Ни какого допуска посторонних
и соблюдается защита игры.
Вариат №1 мне нравится больше по причине именно возможностей которые он открывает.
Что можно с ним сделать.
1.Во первых необходимо ввести некоторые стандарты на вывод данных. Что бы не делать под каждый симулятор
свою панель, свою клиентскую часть итд. Так как Вы первые то Вам и карты в руки. То есть даешь от каждой игры свою DLL-совместимую с другими!!!
2.При соответствующем уровне программистов которые возмуться за обработку данных, то мы их сможем увидеть
а) на втором мониторе
б) на другом компьютре(имеющим связь с головным)
в) вообще внешнем устройстве подключенном к компьютеру. Либо мигание диодов, LCD панель.

В общем были бы данные.
Давайте пока попробуем пробную одностороннюю dll, с данными о
скорости, высоте, состоянии закрылок, шасси, воздушного тормоза, форсажа.
На пробу я думаю этого будет достаточно.

С уважением, Сергей Сафонов.(Swift_CCCP)

[Freddie]

Децкий сад на прогулке. Я плакал...

[Dmut]

мдаа, забавное ТЗ...
Swift_CCCP, ответьте как художник художнику - вы программируете(-овали когда нибудь)?

[arkady]

Originally posted by Dmut
мдаа, забавное ТЗ...
Swift_CCCP, ответьте как художник художнику - вы программируете(-овали когда нибудь)?

Во 1-х он не называл это техзаданием...
А во 2-х: ну так помогите ему правильно составить ТЗ, если Вы - специалист. Зачем же наезжать и ерничать?

[9-3]

Стандартная ситуация: те, кому оно нужно - не могут, а тем, кто может - оно не нужно.
Жаль.

[Mishel]

Тем, кто может, оно тоже нужно. Может они об этом желании не знают? . Но начинать когда-то надо.

2 Swift_CCCP
Прежде всего - "Торописся не надо ..."

Originally posted by Alezz
[...]
Предел мечтаний, чтобы ЕД и МГ договорились о едином формате вывода данных. Тогда одну панель приборов можно будет юзать сразу в двух симах

Если будет написано ТЗ, то оно может стать единым для обеих команд (ЕД и МГ) - это вопрос чисто административный. А вот технические вопросы нужно спокойно, без суеты, основательно продумать. Не нужно замахиваться на всё сразу (в этом случае мы рискуем ничего не получить).

Для начала - абстрагируемся от вариантов аппаратных решений, т.е. - забудем про них (в том числе - вторые, третьи и т.д. мониторы ЖК- и плазменные панели, а также прочие синхрофазотроны ). Здесь это не нужно. Сосредоточимся на главном и обсудим сначала общие вопросы. Здесь нужен конструктивный диалог с представителями разработчика (ЕД), иначе это - сотрясание воздуха.


1. Что нам нужно в первую очередь?

Показания всех приборов (кроме, пожалуй, ИЛС и МФД, так как это - отдельная песня).
Из этого я бы выделил прежде всего (в порядке убывания приоритета):
1. пилотажные и навигационные приборы;
2. индикаторы: топливо, механизация (шасси, торм. щитки, закрылки и т.п.);
3. индикаторы: оповещения об облучении и пуске, вооружения (подвески), отказов различных систем.

Что касается FFB и управления (ввод) по осям и т.д. - это уже, так или иначе, ходит через стандартные API. Если не хватает каналов управления - они добавляются там же (т.е. - нужно ли городить для них отдельный обходной путь?). В любом случае это - второстепенно.

2. Какой должен быть интерфейс (API)?

Тут, возможно, у разработчиков уже есть свои удобные наработки. Пусть расскажут, если есть что.

Возможный вариант:
Получать данные, очевидно, будет прикладная программа путём опроса, вызывая периодически специальную функцию, импортируемую из DLL.

Далее - вопрос: API-функция должна отдавать все данные сразу (а прикладная программа потом выбирает, что ей нужно)? Или же дать возможность вызывающей программе указать - какие конкретно параметры её интересуют (чтобы тащить только то, что она сможет передать в устройство)?

Какие ещё мнения на этот счёт? Когда устаканятся общие вопросы - тогда только имеет смысл обговаривать детали (формат данных и т.п).

PS: Отклик от разработчиков (Valery) - это не мираж? Просто неожиданно как-то.

[Alezz]

Лично меня такой вариант устраивает Данные, думаю, нужно забирать группами, т.е. указываем номер группы- забираем 5(можно больше) переменных. Таким образом легко обеспечит масштабирование АPI. Можно и по одной переменной тянуть, но слишком много вызовов не есть хорошо

[Dmut]

ну что же, попытаюсь и я сформулировать свою пародию на ТЗ, потому что внешние индикаторы мне действительно хотелось бы видеть.

общая схема взаимодействия:
игра каким либо интерфейсом взаимодействует с драйвером внешних индикаторов, пересылая независимые потоки данных, каждый из потоков определяет один изменяемый параметр, например скорость, высота, положение закрылков, etc.

чтобы не перегружать процесс неприрывной пересылкой данных признак пересылки очередного нового значения параметра должен быть настраиваемым:
1) пересылка по таймеру (например каждые 0.5 сек),
2) пересылка по изменению на заранее заданную величину (например "скорость" на каждые 5км\час),
3) пересылка по требованию драйвера

так же должны быть настраимаемы единицы пересылки: метры, километры, мили, etc.

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

само устройство индикации должно работать с одним из популярных PC интерфейсов: например Serial (COM1,etc)(как более легкий) или USB (как более сложный)

организации канала передачи данных:
способов межпроцессорного взаимодействия в среде MS Windows существует много (от фалов, как наиболее простой, до виртальных портов, SharedMemory, Semaphores), но не все из них оптимальны для нашей задачи, например общение на уровне файловой системы, даже виртуальной, сразу отразится на взаимодействии.
не имея информации о внутреннем обмене данными в LO сложно что-то конкретизировать, да и не нужно на данном этапе.
если разработчики поделятся идеей, то, как пример, можно использовать существующее взаимодействие LO c TrackIR.

Вся задача разбивается на несколько этапов и групп занятых людей:
группа 1 (железячная): пишет драйвер устройства, работающего через serial port (для начала), и создающая пару индикаторов разных типов (например типа "будильник" и числовой ), 2-3 человека
этап 1: создание индикатора с принципиальной возможностью чтения данных заданного формата из COM порта
этап 2: согласовав с группой 2 форматы создаются ТЗ на конкретные индикаторы (скорость, высота, закрылки, шасси, etc)

группа 2 (софтверная): вместе с человеком из ED договаривается о конкретном внешнем програмном интерфейсе, описываются форматы и константы, 1+1 или 2+1 человек.

этап 1:: группа выполняет тест задачу по принципиальной возможности получения данных, исследуется вопрос оптимального по скорости и удобству механизма
этап 2: описываются форматы и интерфейсы, создаётся спецификация, пишутся приложение настройщик "микшер" и драйвер.

дальнейшие эпапы подскажет уровень успеха обоих групп.

Valery, интересно услышать идеи-возражения-предложения по данному вопросу.

[9-3]

Originally posted by Mishel
1. Что нам нужно в первую очередь?

Показания всех приборов (кроме, пожалуй, ИЛС и МФД, так как это - отдельная песня)......

А почему "кроме МФД"? Я как раз об МФД на рядом стоящем ноутбуке губу раскатывал. А остальные приборы на втором рядом стоящем ноте. Или это невозможно по техническим причинам?

[Swift_CCCP]

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

Если Вы хотите хоть что то увидеть то, цитирую разработчиков.
......мне нужны не способы реализации (мы их сами как-нибудь придумаем), а подробное описание необходимых интерфейсов, т.е. какие конкретно данные (вплоть до единиц измерения) мы должны предоставлять по внешним программным запросам.
Alezz, Hruks вы ж меня давно знаете(и мое косноязычие то же):p
процесс пошел, требуется только ваша дальнейшая помощь.
Ибо как я предполагаю реализоввывать предется ВАМ.

[Swift_CCCP]

Лано проехали...
У ВАС ВСЕХ ЕСТЬ РЕАЛЬНАЯ ВОЗМОЖНОСТЬ ПОМОЧЬ В СОЗДАНИИ
(ДА ЖЕ НЕ ЗНАЮ КАК ЭТО НАЗВАТЬЧЕГО ТО, ЧЕГО В ИГРАХ ЕЩЕ НЕ БЫЛО.
ВЫ ПО ЖИЗНИ ПРОСИТЕ ХОЧУ ТО(В ИГРЕ) ХОЧУ ЭТО, А ТУТ ПОПАЛСЯ ШАНС КОТОРЫЙ ДАСТ НАМ ВОЗМОЖНОСТЬ САМИМ РЕАЛИЗОВВЫВАТЬ КАКИЕТО ИДЕИ.
Я НЕ МОГУ НАПИСАТЬ ТЗ. ПОЭТОМУ ПРОШУ ГРАМОТНОГО ЧЕЛОВЕКА ЭТО СДЕЛАТЬ.
ЕДИННСТВЕННОЕ ЧТО МНЕ КАЖЕТСЯ ИМЕЕТ СМЫСЛ СДЕЛАТЬ В ПЕРВУЮ ОЧЕРЕДЬ.
1. СОЗДАТЬ НЕБОЛЬШУЮ КОМАНДУ ПОД ЭТОТ ПРОЕКТ, ЧТО Б НЕ БЫЛО КАК В БАСНЕ.
2. ВЫЯСНИТЬ ВСЕ ЖЕ РЕАЛЬНО ЛИ КАК ТО СТАНДАРТИЗИРОВАТЬ ПРОГРАММЫ ОТ ED & MG, ТАК СКАЗАТЬ С ЗАДЕЛОМ НА БУДУЩИЕ ИГРЫ.
ТО О ЧЕМ ПРОСИЛ ALEZZ, ЧТО Б НЕ ЛЕПИТЬ ПОД КАЖДУЮ ИГРУ ЧТО ТО НОВОЕ.

СПАСИБО ЗА ВНИМАНИЕ. ПОЙДУ ПОЧИТАЮ В ВЕТКЕ ЗС ЧТО ПИШУТ.

[9-3]

Спокйнее.. Спокойней, друзья.. Не нужно истерик.
На самом деле всё гораздо проще. В ED не "мальчики в коротких штанишках". Всё они прекрасно понимают и все "чаяния/потребности" вирпилов представляют зачастую получше "среднестастического" вирпила.
Так что все эти просьбы выдать т.н. ТЗ - от лукавого. Идея сама по себе не нова. Захотели - сами давно бы сделали. Без всяких "помощников". Просто не до этого им сейчас. Есть более серьёзные проблемы, требующие незамедлительного решения. Вкусности можно припасти и на потом. А вот то, что они свой козырь "профукали", который выделял линейку Фланкер в ряду других джет-симов (я имею ввиду дальнейшее существенное усовершенствование ФМ) - это действительно ПЛОХО.

изв. ИМХО

[Mishel]

Originally posted by 9-3
А почему "кроме МФД"? Я как раз об МФД на рядом стоящем ноутбуке губу раскатывал. А остальные приборы на втором рядом стоящем ноте. Или это невозможно по техническим причинам?

Технически всё это возможно, только это другого класса задача, так как эти дисплеи содержат разного рода графическую информацию. Роль этих приборов могут выполнять дополнительные мониторы, вывод на которые - скорее - забота разработчиков "Lock On". Вывод во внешнюю программу этих данных (графических) потребует отдельного формата/протокола. Думаю, что не стоит, пока, перегружать этим обсуждаемый интерфейс.

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

По поводу способа передачи. Уважаемые господа разработчики прекрасного симулятора! А что, если этот обмен (между "Lock On" и внешеним софтом) построить на сокетах? Это даст широкие возможности разработчикам систем отображения, так как считывающая программа сможет работать как на локальной машине, так и на соседней, связанной с ней по сети. Такую систему можно без особого труда масштабировать в дальнейшем. При этом можно будет сочетать аппаратное моделирование приборов с программным. К тому же, этот способ избавляет от вмешательства в "чужой" процесс.
Что скажете?

[M@troskin]

QUOTE]Originally posted by M@troskin
Хочу сделать кокпит Су-25! Настоящий... С кнопочками, тумблерочками и приборами... [/QUOTE]
А вот и ссылочку нарыл на всякие моднячие девайсики для продвинутых охреневать тут. Я рыдалъ... Особенно над прайсами... 4,5 кило Евров за панель для цессны...
НО ЗАТО НА НЕЙ ВСЕ ПОКАЗОМЕТРЫ ПОКАЗЫВАЮТ ЧТО ПОЛОЖЕНО!

[M@troskin]

Народ, а где можно купить и сколько стоят рулевые машинки? Те, которые для радиоуправляемых игрушек всяких...

[chp]

Будильники (для авто-симов) делали на шаговых моторчиках из флопарей присоединенных к LPT (простейшая схема и софт).

Но не думаю что здесь стоит расплываться на оффтопики. А также полагаю что не стоит грузить разработчиков пере-наворотами до которых дело может и не дойти. Ожидать что они займутся UI-ем и прочими далекими (по нужности) для них вещами. И особенно "построения в очередь" и рвения сообща подстраиваться под вашу тулзу.

Консультируйтесь с спецами или самими разработчиками об оптимальных путях выдачи циферок, параллельно нарабатывая методы визуализацаии через чего/как вам надо.

[M@troskin]

Originally posted by chp
Будильники (для авто-симов) делали на шаговых моторчиках из флопарей присоединенных к LPT (простейшая схема и софт).

Пораскинем мозгой.

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

А про перенавороты никто ничего и не говорил! Речь о том, чтобы в девайсину на шине USB через некую маленькую библиотЭку отдавались данные приборов для показометров в некоем удобоваримом виде.

под вашу тулзу.

Я с усталых глаз прочел "Тузлу". Долго думал.