Просмотр полной версии : Как можно получить данные из игры?
Swift_CCCP
03.03.2004, 18:13
Давно собираюсь создать внешнюю панель приборов.
Как функциональную так и информативную.
Но если с функциональной панелью(тумблеры, кнопки итд)
более менее понятно, то с информативной панелью начинаются проблемы.
Вернее проблема одна но большая. Данные- откуда брать?
Разработчики Ил-2 сылаются на то что, если открыть доступ к ресурсам
где показывается скорость,высота, обороты итд,то нарушится безопастность
программы и читеры начнут эти данные использовать в своих корыстных целях.
Разработчиков LockOn данными вопросами не озадачивал.
Засела эта мысль в башку и придумал следущее.
Если разработчики создадут какую нибуть infopribor.dll и там будут
копии данных( изменяющиеся естественно с течением игры) то можно ли будет
с помощью этого файла "нарушить игру"? Я думаю, что нет.
Если это действительно не повредит игре, то сложно ли создать такую DLL?
Много человеко ресурсов это не отнимет, а уж панель можно будет забабахать ого-го
какую!!!
Пример номер 1.
Полно старых ноутбуков по бросовой цене(100-150$)
подцепляем его к своему основному компу и выводим на него
хоть приборы, хоть карту, да что хочешь.
пример номер 2.
подключаемая LPT port LCD panel
http://www.madalf.ru/modding/modone32.shtm
НО ДАННЫХ КАКИЕ НУЖНО ВЫВОДИТЬ НЕТ!
Вы мне скажете а как ты это все будешь реализоввывать?
Да найдем как. На форуме умных людей полно.
Вопрос только к разработчикам ИЛ-2 и LockOn
дайте возможность получить данные из игры законным способом,
а мы уж сами сделаем с этими данными что нужно.
Спасибо за внимание.
M@troskin
03.03.2004, 20:11
Originally posted by Swift_CCCP
Давно собираюсь создать внешнюю панель приборов.
Как функциональную так и информативную.
Но если с функциональной панелью(тумблеры, кнопки итд)
более менее понятно, то с информативной панелью начинаются проблемы.
Вернее проблема одна но большая. Данные- откуда брать?
Для MSFS такая приблуда есть, берет она данные откуда-то из кишок игры, отдает любому девайсу в нужном виде, называется FSUIPC.DLL.
Давайте Чижа спросим - может, можно такое сделать и в нашей игре? Мне не кажется, что это не слишком сложно - ведь в игре эти данные есть, раз они обрабатываются/выводятся на экран? Просто отдать их в некоем виде внешней проге... А она уже пережует и выдаст на показометры.
Я сам размышлял над этим вопросом, глядя на всякие приборные панели, часто попадающиеся в интернете, и пытаясь прикинуть, КАК можно сделать самому настоящий работающий командно-пилотажный прибор Су-25 :) и офигевая от ужаса...
Хочу сделать кокпит Су-25! Настоящий... С кнопочками, тумблерочками и приборами...
Аналогично. В свое время для Фланкера делал приборную панель. Хотел собсную прогу писать, чтоб данные снимала. Не вышло. Панель враги выкинули. Ежели разработчики сделают что- либо подобное- будет просто замечательно.
На такую работу нужно написать небольшое ТЗ, в котором описывались бы соответствующие программные интерфейсы. И прислать мне (valery@eagle.ru), а мы рассмотрим и подумаем.
Swift_CCCP
04.03.2004, 20:23
Спасибо за ваш ответ. Определюсь более четко и отпишусь.
Господа вирпилы по активнее идеи нужны в темпе!!!
А ведь Локоновцы глядишь сотворят чего! Очень хочется чтобы и Иловцы тоже ;)
Я бы не отказался на чтение иметь:
показания всех приборов (не только приборов а все данные, а то вдруг на каком пепелаце нету чего-нить), координаты самолёта, действующие в данный момент силы. :)
На запись и чтение - все органы управления, а также положение головы не только оси вращения, но и смещения!
Вот!
Всё это очень хочется иметь сразу и побольше. Но практика показывает, что всего не дают :( Дайте тогда хоть чего-нить! Ну хоть на чтение!!!
Губозакатывающую машинку где взять?
Originally posted by Hruks
Губозакатывающую машинку где взять?
В очередном ратче :D
Originally posted by Hruks
А ведь Локоновцы глядишь сотворят чего! Очень хочется чтобы и Иловцы тоже ;)
Присоединяюсь- хотя бы данные с основных приборов :) Предел мечтаний, чтобы ЕД и МГ договорились о едином формате вывода данных. Тогда одну панель приборов можно будет юзать сразу в двух симах ;)
Swift_CCCP
05.03.2004, 16:46
Это копия письма которую я отправил 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)
Децкий сад на прогулке. Я плакал...
мдаа, забавное ТЗ...
Swift_CCCP, ответьте как художник художнику - вы программируете(-овали когда нибудь)?
Originally posted by Dmut
мдаа, забавное ТЗ...
Swift_CCCP, ответьте как художник художнику - вы программируете(-овали когда нибудь)?
Во 1-х он не называл это техзаданием...
А во 2-х: ну так помогите ему правильно составить ТЗ, если Вы - специалист. Зачем же наезжать и ерничать?
Стандартная ситуация: те, кому оно нужно - не могут, а тем, кто может - оно не нужно.
Жаль.
Тем, кто может, оно тоже нужно. Может они об этом желании не знают? ;). Но начинать когда-то надо.
2 Swift_CCCP
Прежде всего - "Торописся не надо ..." ;)
Originally posted by Alezz
[...]
Предел мечтаний, чтобы ЕД и МГ договорились о едином формате вывода данных. Тогда одну панель приборов можно будет юзать сразу в двух симах ;)
Если будет написано ТЗ, то оно может стать единым для обеих команд (ЕД и МГ) - это вопрос чисто административный. А вот технические вопросы нужно спокойно, без суеты, основательно продумать. Не нужно замахиваться на всё сразу (в этом случае мы рискуем ничего не получить).
Для начала - абстрагируемся от вариантов аппаратных решений, т.е. - забудем про них (в том числе - вторые, третьи и т.д. мониторы ЖК- и плазменные панели, а также прочие синхрофазотроны :D). Здесь это не нужно. Сосредоточимся на главном и обсудим сначала общие вопросы. Здесь нужен конструктивный диалог с представителями разработчика (ЕД), иначе это - сотрясание воздуха.
1. Что нам нужно в первую очередь?
Показания всех приборов (кроме, пожалуй, ИЛС и МФД, так как это - отдельная песня).
Из этого я бы выделил прежде всего (в порядке убывания приоритета):
1. пилотажные и навигационные приборы;
2. индикаторы: топливо, механизация (шасси, торм. щитки, закрылки и т.п.);
3. индикаторы: оповещения об облучении и пуске, вооружения (подвески), отказов различных систем.
Что касается FFB и управления (ввод) по осям и т.д. - это уже, так или иначе, ходит через стандартные API. Если не хватает каналов управления - они добавляются там же (т.е. - нужно ли городить для них отдельный обходной путь?). В любом случае это - второстепенно.
2. Какой должен быть интерфейс (API)?
Тут, возможно, у разработчиков уже есть свои удобные наработки. Пусть расскажут, если есть что.
Возможный вариант:
Получать данные, очевидно, будет прикладная программа путём опроса, вызывая периодически специальную функцию, импортируемую из DLL.
Далее - вопрос: API-функция должна отдавать все данные сразу (а прикладная программа потом выбирает, что ей нужно)? Или же дать возможность вызывающей программе указать - какие конкретно параметры её интересуют (чтобы тащить только то, что она сможет передать в устройство)?
Какие ещё мнения на этот счёт? Когда устаканятся общие вопросы - тогда только имеет смысл обговаривать детали (формат данных и т.п).
PS: Отклик от разработчиков (Valery) - это не мираж? :D Просто неожиданно как-то. :)
Лично меня такой вариант устраивает :) Данные, думаю, нужно забирать группами, т.е. указываем номер группы- забираем 5(можно больше) переменных. Таким образом легко обеспечит масштабирование АPI. Можно и по одной переменной тянуть, но слишком много вызовов не есть хорошо
ну что же, попытаюсь и я сформулировать свою пародию на ТЗ, потому что внешние индикаторы мне действительно хотелось бы видеть.
общая схема взаимодействия:
игра каким либо интерфейсом взаимодействует с драйвером внешних индикаторов, пересылая независимые потоки данных, каждый из потоков определяет один изменяемый параметр, например скорость, высота, положение закрылков, 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, интересно услышать идеи-возражения-предложения по данному вопросу.
Originally posted by Mishel
1. Что нам нужно в первую очередь?
Показания всех приборов (кроме, пожалуй, ИЛС и МФД, так как это - отдельная песня)......
А почему "кроме МФД"? Я как раз об МФД на рядом стоящем ноутбуке губу раскатывал. А остальные приборы на втором рядом стоящем ноте. Или это невозможно по техническим причинам?
Swift_CCCP
06.03.2004, 12:12
Можете плакать, писать и усераться сколько вам влезет.
Обилие умных сопящих в трубочку ПОТРЕБИТЕЛЕЙ на этом форуме просто безгранично. Стоит придумать хоть что-то найдется куча народу это
критикующее.
Да я когда то программировал..КОГДА ТО...
Идея сырая согласен, но как показывают последние события имеющая право на жизнь.
Я не специалист в программировании, но сколько вас закостеневших в своих норках, да ну вас . надоело.
Если Вы хотите хоть что то увидеть то, цитирую разработчиков.
......мне нужны не способы реализации (мы их сами как-нибудь придумаем), а подробное описание необходимых интерфейсов, т.е. какие конкретно данные (вплоть до единиц измерения) мы должны предоставлять по внешним программным запросам.
Alezz, Hruks вы ж меня давно знаете(и мое косноязычие то же):p
процесс пошел, требуется только ваша дальнейшая помощь.
Ибо как я предполагаю реализоввывать предется ВАМ.:D
Swift_CCCP
06.03.2004, 12:32
Лано проехали...
У ВАС ВСЕХ ЕСТЬ РЕАЛЬНАЯ ВОЗМОЖНОСТЬ ПОМОЧЬ В СОЗДАНИИ
(ДА ЖЕ НЕ ЗНАЮ КАК ЭТО НАЗВАТЬ:)ЧЕГО ТО, ЧЕГО В ИГРАХ ЕЩЕ НЕ БЫЛО.
ВЫ ПО ЖИЗНИ ПРОСИТЕ ХОЧУ ТО(В ИГРЕ) ХОЧУ ЭТО, А ТУТ ПОПАЛСЯ ШАНС КОТОРЫЙ ДАСТ НАМ ВОЗМОЖНОСТЬ САМИМ РЕАЛИЗОВВЫВАТЬ КАКИЕТО ИДЕИ.
Я НЕ МОГУ НАПИСАТЬ ТЗ. ПОЭТОМУ ПРОШУ ГРАМОТНОГО ЧЕЛОВЕКА ЭТО СДЕЛАТЬ.
ЕДИННСТВЕННОЕ ЧТО МНЕ КАЖЕТСЯ ИМЕЕТ СМЫСЛ СДЕЛАТЬ В ПЕРВУЮ ОЧЕРЕДЬ.
1. СОЗДАТЬ НЕБОЛЬШУЮ КОМАНДУ ПОД ЭТОТ ПРОЕКТ, ЧТО Б НЕ БЫЛО КАК В БАСНЕ.
2. ВЫЯСНИТЬ ВСЕ ЖЕ РЕАЛЬНО ЛИ КАК ТО СТАНДАРТИЗИРОВАТЬ ПРОГРАММЫ ОТ ED & MG, ТАК СКАЗАТЬ С ЗАДЕЛОМ НА БУДУЩИЕ ИГРЫ.
ТО О ЧЕМ ПРОСИЛ ALEZZ, ЧТО Б НЕ ЛЕПИТЬ ПОД КАЖДУЮ ИГРУ ЧТО ТО НОВОЕ.
СПАСИБО ЗА ВНИМАНИЕ. ПОЙДУ ПОЧИТАЮ В ВЕТКЕ ЗС ЧТО ПИШУТ.:cool:
Спокйнее.. Спокойней, друзья.. Не нужно истерик.
На самом деле всё гораздо проще. В ED не "мальчики в коротких штанишках". Всё они прекрасно понимают и все "чаяния/потребности" вирпилов представляют зачастую получше "среднестастического" вирпила.
Так что все эти просьбы выдать т.н. ТЗ - от лукавого. Идея сама по себе не нова. Захотели - сами давно бы сделали. Без всяких "помощников". Просто не до этого им сейчас. Есть более серьёзные проблемы, требующие незамедлительного решения. Вкусности можно припасти и на потом. А вот то, что они свой козырь "профукали", который выделял линейку Фланкер в ряду других джет-симов (я имею ввиду дальнейшее существенное усовершенствование ФМ) - это действительно ПЛОХО.
изв. ИМХО
Originally posted by 9-3
А почему "кроме МФД"? Я как раз об МФД на рядом стоящем ноутбуке губу раскатывал. А остальные приборы на втором рядом стоящем ноте. Или это невозможно по техническим причинам?
Технически всё это возможно, только это другого класса задача, так как эти дисплеи содержат разного рода графическую информацию. Роль этих приборов могут выполнять дополнительные мониторы, вывод на которые - скорее - забота разработчиков "Lock On". Вывод во внешнюю программу этих данных (графических) потребует отдельного формата/протокола. Думаю, что не стоит, пока, перегружать этим обсуждаемый интерфейс.
На данном этапе, IMHO, нужно ограничиться числовыми данными и состоянием индикаторов. Для них можно разработать простой и достаточно универсальный формат.
По поводу способа передачи. Уважаемые господа разработчики прекрасного симулятора!;) А что, если этот обмен (между "Lock On" и внешеним софтом) построить на сокетах? Это даст широкие возможности разработчикам систем отображения, так как считывающая программа сможет работать как на локальной машине, так и на соседней, связанной с ней по сети. Такую систему можно без особого труда масштабировать в дальнейшем. При этом можно будет сочетать аппаратное моделирование приборов с программным. К тому же, этот способ избавляет от вмешательства в "чужой" процесс.
Что скажете?
M@troskin
08.03.2004, 14:24
QUOTE]Originally posted by M@troskin
Хочу сделать кокпит Су-25! Настоящий... С кнопочками, тумблерочками и приборами... [/QUOTE]
А вот и ссылочку нарыл на всякие моднячие девайсики для продвинутых :) охреневать тут (http://www.simkits.com/). Я рыдалъ... Особенно над прайсами... 4,5 кило Евров за панель для цессны...
НО ЗАТО НА НЕЙ ВСЕ ПОКАЗОМЕТРЫ ПОКАЗЫВАЮТ ЧТО ПОЛОЖЕНО!
M@troskin
08.03.2004, 16:04
Народ, а где можно купить и сколько стоят рулевые машинки? Те, которые для радиоуправляемых игрушек всяких...
Будильники (для авто-симов) делали на шаговых моторчиках из флопарей присоединенных к LPT (простейшая схема и софт).
Но не думаю что здесь стоит расплываться на оффтопики. А также полагаю что не стоит грузить разработчиков пере-наворотами до которых дело может и не дойти. Ожидать что они займутся UI-ем и прочими далекими (по нужности) для них вещами. И особенно "построения в очередь" и рвения сообща подстраиваться под вашу тулзу.
Консультируйтесь с спецами или самими разработчиками об оптимальных путях выдачи циферок, параллельно нарабатывая методы визуализацаии через чего/как вам надо.
M@troskin
08.03.2004, 18:27
Originally posted by chp
Будильники (для авто-симов) делали на шаговых моторчиках из флопарей присоединенных к LPT (простейшая схема и софт).
Пораскинем мозгой.
Но не думаю что здесь стоит расплываться на оффтопики. А также полагаю что не стоит грузить разработчиков пере-наворотами до которых дело может и не дойти.
А про перенавороты никто ничего и не говорил! Речь о том, чтобы в девайсину на шине USB через некую маленькую библиотЭку отдавались данные приборов для показометров в некоем удобоваримом виде.
под вашу тулзу.
Я с усталых глаз прочел "Тузлу". Долго думал. :)
Originally posted by Dmut
Valery, интересно услышать идеи-возражения-предложения по данному вопросу.
Меня интересуют конкретные технические предложения по интерфейсам и протоколам взаимодействия. Те, кто знает, что это такое, прошу прислать их мне. Тех, кто не знает, просьба не мешать. Меня пока что не интересуют организационные вопросы, способы реализации и идиотские иронические комментарии. Поэтому я согласен обсуждать данный вопрос только со специалистами лично.
Valery
"конкретные технические предложения по интерфейсам и протоколам взаимодействия" постить сюда или слать на мыло?
есть конкретные идеи насчет софтверной части, заниматься хардом не смогу.
Mishel идея с сокетами понравилась, организовать UDP траффик на заранее прописанный в конфиге адрес\порт несложно. принять на рядом стоящем ноуте и отобразить в виде различных "градусников" тоже проблем не составляет. но тогда "железячные будильники" отменяются, по крайней мере на первом этапе.
Погодите немножко с идеями, наверное до понедельника. Я всетаки надеюсь на единый формат для ЗС и Локона, насколько это возможно
Имеется одна голова и пара рук в помощь %)
Правда ли, что показания каждого прибора могут быть представлены либо точкой на вещественном кольце (угол), либо точкой на конечном вещественном отрезке, либо натуральным числом (лампочки, тумблеры, многопозиционные переключатели)?
Правда ли, что множество приборов, показываемых в LockOn, содержит в себе множество приборов, показываемых в Ил-2? Если нет, известно ли в чем эти множества отличаются?
Кто будет осуществлять координацию? Alezz?
Originally posted by Dmut
Valery
"конкретные технические предложения по интерфейсам и протоколам взаимодействия" постить сюда или слать на мыло?
есть конкретные идеи насчет софтверной части, заниматься хардом не смогу.
Только на мыло, здесь я ничего обсуждать не собираюсь. Интерфейсы и протоколы подразумеваются исключительно ваши прикладные. Не нужно мне объяснять, что такое TCP/IP или средства межпрограммного взаимодействия Win32 API, как это некоторые пытаются делать. Пришлите перечень приборов, для каждого из них укажите конкретный состав данных и желательный ПРИКЛАДНОЙ протокол получения этих данных - по запросу, периодически и т.п. И все, больше ничего от вас пока что не требуется.
Еще раз подчеркиваю, что если этих данных у вас нет, ничего не присылайте - я буду обсуждать только то, о чем я просил.
ok, значит я пока постараюсь подготовить некую спецификацию формата обмена, отталкиваясь от схемы "комп+ноут" с обменом на сокетах.
Originally posted by Dmut
ok, значит я пока постараюсь подготовить некую спецификацию формата обмена, отталкиваясь от схемы "комп+ноут" с обменом на сокетах.
Вот горячий парень, ему говорят подожди а он в бой рвется :) Если у меня до понедельника ни чего не получится, тогда пусть будут сокеты...
А может быть, пока стоит обсудить вот это?
перечень приборов, для каждого из них укажите конкретный состав данных
Originally posted by Alezz
Если у меня до понедельника ни чего не получится, тогда пусть будут сокеты...
Будет то, что определим мы, а не то, что у кого-нибудь получится или не получится. Советую не тратить время понапрасну, если речь идет о способах реализации экспорта данных из ЛокОна. Техническое решение уже, в принципе, готово и обсуждению не подлежит.
ранние спеки ушли на valery@eagle.ru (надеюсь я угадал адрес :) )
Техническое решение уже, в принципе, готово и обсуждению не подлежит. можно ли поподробнее? что именно уже зафиксировано?
M@troskin
11.03.2004, 11:35
Originally posted by Valery
Будет то, что определим мы, а не то, что у кого-нибудь получится или не получится. Советую не тратить время понапрасну, если речь идет о способах реализации экспорта данных из ЛокОна. Техническое решение уже, в принципе, готово и обсуждению не подлежит.
Что-то мне как-то Меддоксом повеяло... :(
Originally posted by Dmut
ранние спеки ушли на valery@eagle.ru (надеюсь я угадал адрес :) )
можно ли поподробнее? что именно уже зафиксировано?
То, как технически будет осуществляться экспорт данных. Но перечня самих требуемых данных я так ни от кого здесь не получил. Для справки: мне уже прислали из-за рубежа подробный перечень данных по F-15C. Стало быть, с него и начнем.
Originally posted by M@troskin
Что-то мне как-то Меддоксом повеяло... :(
Принимаю, как комплимент. А мне здесь очередным пустозвонством повеяло.
Originally posted by Valery
То, как технически будет осуществляться экспорт данных. Но перечня самих требуемых данных я так ни от кого здесь не получил. Для справки: мне уже прислали из-за рубежа подробный перечень данных по F-15C. Стало быть, с него и начнем.
Зачем тогда было писать вот это?
Меня интересуют конкретные технические предложения по интерфейсам и протоколам взаимодействия.
если сами предложения совсем не интересуют? Про перечень данных по каждому конкретному ЛА разговора, вроде не было.
Originally posted by Alezz
Зачем тогда было писать вот это?
Меня интересуют конкретные технические предложения по интерфейсам и протоколам взаимодействия.
если сами предложения совсем не интересуют? Про перечень данных по каждому конкретному ЛА разговора, вроде не было.
Вернись в начало разговора и посмотри, что от нас просили. Как можно экспортировать данные, не зная, что конкретно нужно клиенту? Я уточнил, что мне нужны именно ПРИКЛАДНЫЕ интерфейсы и протоколы - и ничего больше. Мы обеспечим экспорт требуемых данных на локальной машине, а уж что и как клиент будет дальше с ними делать - это не наши проблемы.
2 Valery
В течение какого времени можно присылать описание прикладного протокола / формата данных на valery@eagle.ru ? Свой вариант смогу прислать не ранее следующей недели.
2 Dmut
Originally posted by Dmut
[...] организовать UDP траффик на заранее прописанный в конфиге адрес\порт несложно. принять на рядом стоящем ноуте и отобразить в виде различных "градусников" тоже проблем не составляет. но тогда "железячные будильники" отменяются, по крайней мере на первом этапе.
На сёт "отменяются" - это уже кто как пожелает. Просто с сетевым вариантом возможности становятся немножко шире :).
Originally posted by Mishel
2 Valery
В течение какого времени можно присылать описание прикладного протокола / формата данных на valery@eagle.ru ? Свой вариант смогу прислать не ранее следующей недели.
Присылайте, когда хотите, все равно мы все сразу не реализуем, а будем действовать поэтапно. Только вот никакие форматы мне не нужны - только состав конкретных прикладных данных. Желательно также объяснить, как Вы их собираетесь использовать, чтобы мы поняли, для чего все это нужно.
Swift_CCCP
16.03.2004, 12:59
Я вот кашу заварил, а сам в програмировании ни бум-бум...
Ясно пока одно - МГ не какие данные не даст, значит вопрос о стандартизации отпадает...
Надежда только на LockON.
Как идет процесс?
Просветите хоть что ожидается.
Originally posted by Swift_CCCP
Я вот кашу заварил, а сам в програмировании ни бум-бум...
Ясно пока одно - МГ не какие данные не даст, значит вопрос о стандартизации отпадает...
Надежда только на LockON.
Как идет процесс?
Просветите хоть что ожидается.
Посмотри крайний топик про патч 1.02 :)
Swift_CCCP
01.04.2004, 15:44
Господа, раскажите мне по русски что выгорит из моей прозьбы?
Спасибо.
Так как, судя по словам разработчиков, спешить некуда (тем более, что первым на очереди - F-15), я решил составить более-менее детальный перечень данных для экспорта по самолётам Су-27 и Су-33 (для начала). В ближайшие дни постараюсь доделать его и отправлю в ED.
Ну а дальше - будем ждать реализации, набравшись терпения. "Москва не сразу строилась..." ;).
Miguel Gonsalez
01.04.2004, 20:09
Originally posted by Valery
То, как технически будет осуществляться экспорт данных. Но перечня самих требуемых данных я так ни от кого здесь не получил. Для справки: мне уже прислали из-за рубежа подробный перечень данных по F-15C. Стало быть, с него и начнем.
Валер, быть может я тоже пустозвоню... но... а что, нельзя присоединенному клиенту по запросу(или по таймеру) отдавать статус всех приборов в виде... да хотя бы xml? Пусть клиентская прикладуха сама разбирает как ей это отрисовывать... Объемы здесь не так важны, поскольку вряд ли кто будет передавать данные на лэптоп в Париже, реально находясь в Москве, посему морочиться с каким-нить мудрым протоколом обмена вряд ли нужно... :rolleyes:
Originally posted by Miguel Gonsalez
Валер, быть может я тоже пустозвоню... но... а что, нельзя присоединенному клиенту по запросу(или по таймеру) отдавать статус всех приборов в виде... да хотя бы xml? Пусть клиентская прикладуха сама разбирает как ей это отрисовывать... Объемы здесь не так важны, поскольку вряд ли кто будет передавать данные на лэптоп в Париже, реально находясь в Москве, посему морочиться с каким-нить мудрым протоколом обмена вряд ли нужно... :rolleyes:
Блин, ну кто говорил о каком-то мудром протоколе обмена? Прикладной протокол - это то, что конкретно нужно пользователю, и ничего больше. А что под ним лежит в качестве поддержки (UDP или что-нибудь другое) - для пользователя не так уж важно. Да и на кой, спрашивается, экспортировать данные по всем приборам, да еще на каждом кадре, если из них нужны только некоторые, да и то не всем и не всегда? Поэтому мы просто откроем интерфейсы для получения именно тех данных, которые у нас попросят сначала просто по-человечески, а затем, когда мы реализуем экспортные функции, - из экспортного скрипта. А также предоставим простые средства для передачи этих данных по стандартным сетевым протоколам туда, куда сам пользователь напишет в скрипте. А уж где будет работать пользовательская программа, взаимодействующая с ЛокОном, - на той же самой машине или в Париже - это не имеет с точки зрения реализации никакого значения.
Не стоит заморачиваться, сами увидите, что все гораздо проще, просто дискуссию здесь с самого начала повело явно не туда на почве какой-то непонятной мне стереотипной реакции на слово "протокол". Кстати, американец сразу все прекрасно понял, прислал перечень необходимых ему данных для подключения ЛокОна к имеющейся у него реальной кабине F-15 и заказал книжку по языку Lua, чтобы научиться писать скрипты.
Miguel Gonsalez
01.04.2004, 21:10
Originally posted by Valery
Блин, ну кто говорил о каком-то мудром протоколе обмена? Прикладной протокол - это то, что конкретно нужно пользователю, и ничего больше. А что под ним лежит в качестве поддержки (UDP или что-нибудь другое) - для пользователя не так уж важно.
Абсолютно согласен.
Да и на кой, спрашивается, экспортировать данные по всем приборам, да еще на каждом кадре, если из них нужны только некоторые, да и то не всем и не всегда?
Ну, про каждый кадр я не говорил... по запросу - более правильно, конечно. Да и почему бы не все? Запросил все(с пустым именем) - получи все, запросил конкретный - получи конкретный.
Поэтому мы просто откроем интерфейсы для получения именно тех данных, которые у нас попросят сначала просто по-человечески, а затем, когда мы реализуем экспортные функции, - из экспортного скрипта. А также предоставим простые средства для передачи этих данных по стандартным сетевым протоколам туда, куда сам пользователь напишет в скрипте. А уж где будет работать пользовательская программа, взаимодействующая с ЛокОном, - на той же самой машине или в Париже - это не имеет с точки зрения реализации никакого значения.
Теоретически, конечно, значения не имеет, а практически... все зависит от того в каком виде эти данные будут клиенту отдаваться. Иначе до Парижа они полдня ползти будут :D Я именно поэтому речь об xml завел. Формат хороший и удобочитаемый, но в случае больших объемов - тяжеловат, к сожалению...
Кстати, американец сразу все прекрасно понял, прислал перечень необходимых ему данных для подключения ЛокОна к имеющейся у него реальной кабине F-15 и заказал книжку по языку Lua, чтобы научиться писать скрипты.
Валер... не в плане занудства, просто вопрос возник - почему Lua выбрали? Есть же Python... объектный хотя бы...
Miguel Gonsalez
01.04.2004, 21:10
Originally posted by Dmut
Miguel Gonsalez
исходя из последней инфы от ED, механизмы и протоколы передачи данных из LO уже зафиксировны, обсуждается только возможный набор данных для экспорта.
в любом случае до выхода 1.02 ситуация с эспортом данных, судя по всему, не прояснится.
Интересненько... будем посмотреть. ;)
Originally posted by Miguel Gonsalez
Валер... не в плане занудства, просто вопрос возник - почему Lua выбрали? Есть же Python... объектный хотя бы...
Lua - встраиваемый язык программирования по определению, что нам и нужно. Lua у всех скриптовых языков выигрывает по производительности, что для симулятора очень важно. Lua сделан очень квалифицированно, авторам удалось создать простой, компактный, гибкий и мощный инструмент. Очень многие задачи решаются на Lua удивительно просто и эффективно. Lua обладает возможностями объектно-ориентированного программирования, раз уж об этом зашла речь, в книге автора языка Роберто Иерусалимского есть специальная глава на эту тему. Lua разработан на С и имеет простой и эффективный API для связи с C. Lua работает в любой среде, где работает C. Lua эксплуатируется уже 10 лет и прекрасно себя зарекомендовал практически, в том числе и в серьезных игровых программах (FarCry). Lua - свободно распространяется в исходниках, что позволяет легко дополнять и развивать его в различных направлениях, что и было сделано в многочисленных эддонах. Lua очень прост в освоении. Мы сами опробовали его практически, и результаты оказались очень хорошими. Наконец, Lua создан в Бразилии, где в лесах так много... сами знаете :) Кстати, lua - это по-португальски луна.
Miguel Gonsalez
05.04.2004, 20:08
Спасибо, Валер. Просветил. Что-то я маловато, действительно об этом языке знал до сих пор. Только по OSS немного...
Валерий, продолжая вашу дискуссию на simhw.com насчет Dynamic Campaigns - выскажите своё мнение о возможности разработки механизма DC внешними 3rd-party (не знаю адекватный перевод) разработчиками при условии выноса достаточного кол-ва функционала в LUA скрипты.
Originally posted by Dmut
Валерий, продолжая вашу дискуссию на simhw.com насчет Dynamic Campaigns - выскажите своё мнение о возможности разработки механизма DC внешними 3rd-party (не знаю адекватный перевод) разработчиками при условии выноса достаточного кол-ва функционала в LUA скрипты.
Отношусь к этому скептически, потому что ЛокОн не предназначен для моделирования операций (или кампаний по западной терминологии). ЛокОн - это сугубо тактический симулятор. На его базе, разумеется, можно разработать продвинутые фенечки и объявить их динамическими кампаниями, но к реальным кампаниям это не будет иметь никакого отношения. На мой взгляд, кампании нужно моделировать не менее честно, чем тактические боевые действия. А для этого игровой движок должен быть построен существенно по-другому. Иными словами, динамические кампании - очень интересная и непростая штука, достойная профессиональной разработки в отдельном проекте. А в тактическом симуляторе имеет смысл развивать командирские фитчи, в том числе и динамические.
Если же говорить о скриптах, то они в нормальном случае предназначены для модификации пользователями поведения объектов игры, а не для изменения ее целевого назначения.
Miguel Gonsalez
07.04.2004, 15:42
Originally posted by Valery
На мой взгляд, кампании нужно моделировать не менее честно, чем тактические боевые действия.
Не, Валер... делать все честно нельзя. Нужно правдоподобие. Тут много уже говорилось по поводу "бабблинга" в ДК Фэлкона, но на мой взгляд, бабблинг просто неизбежен... примерно в той же степени, как и использование LOD-ов в визуалке или ограничение дальности видения. Иначе любой комп сдохнет при более-менее разумном количестве объектов. Лучшее - враг хорошего, как известно, а потому, лучше не "честно", а "правдоподобно" ;)
Валерий, спасибо за инфу.
Ваша позиция ясна, позвольте мне поделиться моими идеями по поводу некой условной реализации некого возможного механизма DC в LO.
Прежде всего хочу заметить, что очень обнадеживает Ваше стремление к открытой архитектуре в LO путем внедрения и расширения функционала на LUA скриптах. Это несомненно шаг, который, при соответствующей реализации, в дальнейшем принесет большие плоды и намного увеличит популярность LO у тех, кто в него играет мало либо ещё не играл вообще. Так же не может не радовать Ваше видение скриптов LUA как механизма “для модификации пользователями поведения объектов игры”, что подразумевает возможность в дальнейшем улучшать AI собственными силами игроков.
Теперь о DC. Совершенно с Вами согласен, что настоящего моделирования театра боевых действий добиться нельзя, но это и не ставится как задача для игры, работающей на персональном компьютере. Достаточно создать такую связь между последовательными миссиями, что бы от действий игрока в предыдущей миссии зависела расстановка сил в следующей. И реализацию логики этих зависимостей я предлагаю переложить на плечи 3rd-party разработчиков.
Теперь о том, что требуется от ED, чтобы независимые разработчики смогли создать свой простейший механизм DC. В простейшем случае для этого нужны механизмы экспорта-импорта миссии в LO в открытом формате и экспорт результатов завершившейся миссии. Остальное может сделать внешняя программа: проанализировать предыдущую миссию и на основе результатов создать следующую. Таким образом у конечного пользователя значительно возрастет интерес с игре.
Некие подобные механизмы присутствуют во многих современных симуляторах, причем некоторые из них сделаны “народными умельцами”.
Насколько мне известно из некоторых сообщений на форумах ubisoft, в LO уже существует функционал импорта-экспорта миссий в более-менее открытый формат, но спецификации пока закрыты и доступны только небольшом кол-ву “не-ED” народа.
Так же хотелось бы добавить, что мне известно о том, что финансирование проекта LO от ubisoft очень ограничено, и что на обширное развитие LO просто нет денежных средств. Именно поэтому мне, как фанату LO, хотелось бы переложить большую чать работы по дальнейшему совершенствованию LO на плечи фанатов, но для этого ED нужно вынести необходимые функции наружу. Сейчас фанаты могут только создавать миссии, делать различные шкурки к технике и криво патчить MEinit.xml.
пока я писал свой опус, Miguel Gonsalez уже высказал похожее мнение, о том что можно реализовать и простой механизм DC, всё равно будет интереснее чем сейчас :)
Originally posted by Miguel Gonsalez
Не, Валер... делать все честно нельзя. Нужно правдоподобие. Тут много уже говорилось по поводу "бабблинга" в ДК Фэлкона, но на мой взгляд, бабблинг просто неизбежен... примерно в той же степени, как и использование LOD-ов в визуалке или ограничение дальности видения. Иначе любой комп сдохнет при более-менее разумном количестве объектов. Лучшее - враг хорошего, как известно, а потому, лучше не "честно", а "правдоподобно" ;)
Разумеется, у нас же не командно-штабные учения, а всего лишь игра, поэтому "честно" всегда означало, означает и будет означать "более или менее правдоподобно". В то же время, хотя игровой симулятор - это не тренажер, но он и не аркада. Я не потому упираюсь, что мне хочется моделировать кампании супер-пупер детально, а потому что в симуляторе даже при простеньком моделировании все равно нужно плясать от реальности, а не выдумывать фитчи из собственной головы, лишь бы интересно играть было. В противном случае нам давно уже следовало бы заняться массовым производством прикольных уфолетов на радость непритязательной развлекающейся публики. Но если мы, не дай Бог, пойдем по этому пути, вирпилам придется навсегда забыть о самом понятии "симулятор", не говоря уж о столь высоко ценимых в элитарных кругах продвинутых флайт-моделях, авиониках и прочих "архитектурных излишествах", судьба которых и так на волоске висит именно в результате применения сформулированного тобой тезиса, понимаемого буквально.
Originally posted by Dmut
Теперь о DC. Совершенно с Вами согласен, что настоящего моделирования театра боевых действий добиться нельзя, но это и не ставится как задача для игры, работающей на персональном компьютере.
Что-то не припомню, чтобы я такое говорил. Напротив, готов утверждать прямо противоположное, если разумно уточнить слово "настоящего".
Насколько мне известно из некоторых сообщений на форумах ubisoft, в LO уже существует функционал импорта-экспорта миссий в более-менее открытый формат, но спецификации пока закрыты и доступны только небольшом кол-ву “не-ED” народа.
Что ни день, то новости :) Ничего подобного у нас пока что нет, хотя и не проблема все это реализовать в свое время. К тому же, только небольшому количеству "не-ED" народа это и нужно. Пример с экспортом данных для разработанных пользователями кабин показал, что таких людей в мире пока всего лишь двое, и мы с ними работаем лично. Не понимаю, чем озабочены те, кого это вообще не касается.
Так же хотелось бы добавить, что мне известно о том, что финансирование проекта LO от ubisoft очень ограничено, и что на обширное развитие LO просто нет денежных средств. Именно поэтому мне, как фанату LO, хотелось бы переложить большую чать работы по дальнейшему совершенствованию LO на плечи фанатов, но для этого ED нужно вынести необходимые функции наружу. Сейчас фанаты могут только создавать миссии, делать различные шкурки к технике и криво патчить MEinit.xml.
Значит, если мы откроем больше, чем MEInit.xml, фанаты станут патчить не криво? Не смешите меня, будет еще кривее :D
Итак, если кто-нибудь действительно захочет взвалить на себя титанический труд и поучаствовать в реализации DC, то я готов обсудить с таким отъявленным фанатом данный вопрос подробно, но только в личной переписке. Однако, я заранее отказываюсь делать это на базе ЛокОна в виде всяческих фенечек и примочек.
PM ушло
Что ни день, то новости Ничего подобного у нас пока что нет, хотя и не проблема все это реализовать в свое время.насколько мне известно из сообщений на ubbxforums.ubi.com, RossMacGregor разрабатывает вой механизм генерации кампаний, значит у него как минимум есть способ генерировать миссии для LO без использования LO GUI, так же там упоминался способ брать результаты миссии, как находящийся в разработке.
Не понимаю, чем озабочены те, кого это вообще не касается. извените, вы про кого?
Значит, если мы откроем больше, чем MEInit.xml, фанаты станут патчить не криво? Не смешите меня, будет еще кривее любой механизм можно использовать не по назначению.
да, некоторые сейчас патчат MEInit.xml, но многим ли сейчас интресно летать с AIM-120 на Миг29 ? нет.
Так же как механизм создания миссий можно использовать для удовлетворения своих мелких психологических комплексов, но ведь есть и интересные миссии, пусть игроки выбирают лучшее.
Чем больше вы откроете, тем более разнообразней станет игра ( я не имею ввиду внедрение "прикольных уфолетов " ).
Originally posted by Dmut
насколько мне известно из сообщений на ubbxforums.ubi.com, RossMacGregor разрабатывает вой механизм генерации кампаний, значит у него как минимум есть способ генерировать миссии для LO без использования LO GUI, так же там упоминался способ брать результаты миссии, как находящийся в разработке.
Насколько известно мне, Ross MacGregor занимается этим по договору с The Fighter Collection, поэтому у него и есть соответствующий доступ к внутренним интерфейсам ЛокОна. На мой взгляд, о результатах его деятельности будет иметь смысл поговорить тогда, когда они появятся :)
извените, вы про кого?
Про большинство принявших участие в обсуждении данной темы.
любой механизм можно использовать не по назначению.
да, некоторые сейчас патчат MEInit.xml, но многим ли сейчас интресно летать с AIM-120 на Миг29 ? нет.
Так же как механизм создания миссий можно использовать для удовлетворения своих мелких психологических комплексов, но ведь есть и интересные миссии, пусть игроки выбирают лучшее.
Чем больше вы откроете, тем более разнообразней станет игра ( я не имею ввиду внедрение "прикольных уфолетов " ).
Использование механизмов не по назначению - это IMHO слабоватый аргумент. Мы как раз ходим делать механизмы строго целенаправленно, а не заниматься бесцельной ерундой для удовлетворения мелких психологических комплексов неизвестных нам лиц. Поэтому я и добиваюсь, чтобы мне объяснили подробно, кому, что и зачем нужно из ЛокОна.
наверное вы меня не поняли по "использование механизмов не по назначению".
я лишь хотел сказать, что какой бы механизм вы не сделали, некоторые всё равно будут это использовать не поназначению, для создания уфолетов, "удовлетворения своих мелких психологических комплексов", или просто экспериментов, как сейчас используют MEinit.xml. каким бы небыл микроскоп - пещерные люди всегда найдут способ, как разбивать им орехи.
я НЕ сторонник такого нецелевого использования, но знаю что защититься от него практически невозможно.
Поэтому я и добиваюсь, чтобы мне объяснили подробно, кому, что и зачем нужно из ЛокОна C экспортом данных из LO всё более-менее, будем ждать патча.
А вот "что и зачем нужно из ЛокОна" для организации DC - над этим нужно говорить в привате.
в связи с выходом нового патча от MG, где реализован механизм "экпорта данных" предлагаю опять поднять этот вопрос относительно LO.
OM реализовал этот механизм в виде полноценного UDP сервера, с возможностью не только отдавать данные но и принимать данные от сетевых устройств, это позволит в будущем реализовать нестандартные элементы управления, основаные не на джоях со стандартным USB/HID интерфейсом, а на сетевых TCP/IP устройствах.
в кратце принцип действия "экспорта данных" от MG такой - внешний клиент посылает по UDP пакет состоящий из идентификаторов параметров (ID), которые он хочет получить, и ID параметров+значение параметра, которые он хочет передать игре. сервер отсылает ответ.
то, что мне известно об экспорте данных из LO, позволяет сравнивать различные подходы, которые выбрали ED и MG.
с одной стороны, сразу после выхода механихм от MG будет чуть лучше из-за того, что поддерживает не только экпорт данных но и импорт в игру. с другой стороны механизм от ED гибче - пользователь сам пишет LUA скрипты и тем самым самым определяет характер траффика, протокол и формат. Опять таки нет никаких принципиальных трудностей для ED чтобы в будущем добавить возможность импорта данных.
У обоих схем есть одинаковый недостаток - оба механизма не универсальны в смысле выбора набора данных. То есть экспортировать можно будет только то, что будет разрешено, и соответственно при введении в игру новых параметров нужно будет делать новые экпортирующие функции.
приглашаю разработчиков и всех понимающих "тему" высказаться по поводу плюсов и минусов различных подходов. просьба не засорять трид непрофессиональными "хотелками".
в связи с выходом нового патча от MG, где реализован механизм "экпорта данных" предлагаю опять поднять этот вопрос относительно LO.
Насчёт экспорта в Ил-2 - тоже приятная новость :).
OM реализовал этот механизм в виде полноценного UDP сервера, с возможностью не только отдавать данные но и принимать данные от сетевых устройств, это позволит в будущем реализовать нестандартные элементы управления, основаные не на джоях со стандартным USB/HID интерфейсом, а на сетевых TCP/IP устройствах.
Чую, грядёт эра джойстиков (и иже с ними) с поддержкой TCP/IP ;).
[...] с одной стороны, сразу после выхода механихм от MG будет чуть лучше из-за того, что поддерживает не только экпорт данных но и импорт в игру.
И на нашей улице будет праздник ;).
с другой стороны механизм от ED гибче - пользователь сам пишет LUA скрипты и тем самым самым определяет характер траффика, протокол и формат. Опять таки нет никаких принципиальных трудностей для ED чтобы в будущем добавить возможность импорта данных.
Честно говоря, я надеялся, что и MG пойдёт по пути внедрения Lua (по примеру ED), ведь это сразу предоставляет широкие возможности не только для экспорта/импорта. Кроме того, как Вы справедливо заметили, это облегчает дальнейшее развитие (симулятора вообще).
Моё мнение: если механизм от MG реализован не через Lua, у механизма от ED преимущество будет даже сразу после выхода ;).
У обоих схем есть одинаковый недостаток - оба механизма не универсальны в смысле выбора набора данных. То есть экспортировать можно будет только то, что будет разрешено, и соответственно при введении в игру новых параметров нужно будет делать новые экпортирующие функции.
С другой стороны: а как иначе? Как предугадать возможные будущие потребности в данных? Экспортировать сразу всё - тоже не выход (что входит в это "всё"?). Поэтому и звучал вопрос "кому, что и зачем нужно из ЛокОна?". Круг подерживаемых параметров - в прямой зависимости от интереса пользователей :) (на счёт Ил-2 - не в курсе).
забыл добавить самое интересное - при таком подходе LO будет совместим с устройствами\программами управления\отображения инормации, сделаными для Ил2, потому что на LUA скриптах можно будет сэмулировать формат DeviceLink, а вот Ил2 понимать проги и железки сделаные для LO не будет, в виду свободного формата траффика в LO. таким образом без вмешательства MG и переделки DeviceLink нельзя будет использовать внешние программы отображения данных, написанные для LO, то же самое относится к будущим интеллектуальным кокпитам.
ещё один небольшой минус формата DeviceLink - то что на каждый UDP запрос будет следовать UDP ответ, что увеличивает траффик и вероятность пропадания пакета ( напоминаю что UDP это протокол без гарантированной доставки пакета ). Таким образом у неграмотно написаных программ будут возможны сутуациии "затыка", если программа мониторинга шлет запрашивающий пакет после приёма ответа с предыдущего запроса ( а это типичная ошибка новичков в сетевом программировании ) и запрашивающий пакет пропадает, то прога будет ждать таймаут либо подвиснет ожидая ответа.
В LO я собираюсь реализовать немного другой механизм запроса данных, тоже основанный на UDP, где управлящий пакет будет посылаться всего несколько раз за сессию и говорить предпочтительные параметры посылки ответных данных, например: слать каждую секунду, слать по событию и так далее. естественно при этом не отпадает необходимость проверки корректного прохождения управляющего пакета. при этом типичный траффик по сьёму данных будет односторонним - от LO к устройствам отображения, что позволит уменьшить используемую полосу и уменьшить вероятность потери пакета.
кстати, ещё одна революционная мысль - после того как в симуляторах будет доступно полноценное управление ЛА посылкой команд по сети - начнут появляться программы-помошники, боты-автопилоты, которые например никогда не дадут сорваться в штопор, будут строго выдерживать параметры полета лучше автопилота в игре, вовремя открывать-закрывать заслонку охлаждения и автоматически регулировать шаг винта наиболее оптимальным способом, и даже воздушный бой может превратиться в соревнование умных программ ботов, работающих от лица пользователя. то есть может закончитсья эра честных сетевых поединков - ведь никогда не будешь знаеть какие проги помогают в данный момент твоему оппоненту. вот такие вот дела могут начаться в ближайшие годы.
с одной стороны, сразу после выхода механихм от MG будет чуть лучше из-за того, что поддерживает не только экпорт данных но и импорт в игру.
Неправда, механизм ED поддерживает внешнее управление программой в полном объеме. Кроме того, ED прилагает библиотеку LuaSocket.dll, которая поддерживает все основные стандартные протоколы в Lua, а также готовые скрипты с примерами использования этих протоколов. Да и как можно делать далеко идущие выводы о фитче, которой еще никто в глаза не видел? Домыслы, батенька, - дело неблагодарное :)
Мы не выпускаем в патче 1.02 готовую экспортно/импортную фитчу, мы отрабатываем технологию этого дела в экспериментальном порядке с теми заинтересованными специалистами-пользователями, которые изъявили желание практически взаимодействовать с нами в данном вопросе, поскольку они собираются разрабатывать специализированные кабины. Пока таких пользователей всего двое. Если после выхода патча объявятся еще желающие специалисты, пишите письма мне (valery@eagle.ru) - обсудим ваши возможности и потребности.
забыл добавить самое интересное - при таком подходе LO будет совместим с устройствами\программами управления\отображения инормации, сделаными для Ил2, потому что на LUA скриптах можно будет сэмулировать формат DeviceLink, а вот Ил2 понимать проги и железки сделаные для LO не будет, в виду свободного формата траффика в LO.
Видимо, прийдётся заранее предусматривать в этом софте режим совместимости с Ил2. Вообще, непонятно, чем обусловлен такой достаточно жёсткий механизм у MG. На борьбу с читерами это, вроде, не похоже.
ещё один небольшой минус формата DeviceLink - то что на каждый UDP запрос будет следовать UDP ответ, что увеличивает траффик и вероятность пропадания пакета [...]
Выходит, что, в любом случае, даже при использовании только экспорта (без импорта), поток данных от внешнего софта в симулятор будет присутствовать. А что, заведомо большая (во много раз), относительно необходимой, ширина канала не спасёт "отца русской демократии"?:)
В основном-то, наверное, будет Ethernet использоваться.
В LO я собираюсь реализовать немного другой механизм запроса данных, тоже основанный на UDP, где управлящий пакет будет посылаться всего несколько раз за сессию и говорить предпочтительные параметры посылки ответных данных, например: слать каждую секунду, слать по событию и так далее. естественно при этом не отпадает необходимость проверки корректного прохождения управляющего пакета. при этом типичный траффик по сьёму данных будет односторонним - от LO к устройствам отображения, что позволит уменьшить используемую полосу и уменьшить вероятность потери пакета.
Если в LO использовать только экспорт, можно вообще обойтись без управляющих пакетов, настроив в скрипте всё заранее, или отправить этот пакет один раз - в самом начале сессии. Но если нужно управлять протоколом во время сессии, тогда, конечно, так, как Вы описали.
кстати, ещё одна революционная мысль - после того как в симуляторах будет доступно полноценное управление ЛА посылкой команд по сети - начнут появляться программы-помошники, боты-автопилоты, которые например никогда не дадут сорваться в штопор, будут строго выдерживать параметры полета лучше автопилота в игре, вовремя открывать-закрывать заслонку охлаждения и автоматически регулировать шаг винта наиболее оптимальным способом, и даже воздушный бой может превратиться в соревнование умных программ ботов, работающих от лица пользователя.
Это, ведь, замечательно! Откроется целое направление: соревнование ботов. Каждый пользователь, например, будет настраивать своего бота заранее, а потом - наблюдать за ним в игре. Нужно только удобную оболочку для настройки ботов сделать, чтобы играть мог любой желающий. Помните "Змеиный бой" или "Core Wars"? ;)
то есть может закончитсья эра честных сетевых поединков - ведь никогда не будешь знаеть какие проги помогают в данный момент твоему оппоненту. вот такие вот дела могут начаться в ближайшие годы.
Мне кажется, тут нет проблемы. Честность поединков лежит целиком на совести игрока. Играющий нечестно обманывает сам себя.
Неправда, механизм ED поддерживает внешнее управление программой в полном объеме. Кроме того, ED прилагает библиотеку LuaSocket.dll, которая поддерживает все основные стандартные протоколы в Lua, а также готовые скрипты с примерами использования этих протоколов. Да и как можно делать далеко идущие выводы о фитче, которой еще никто в глаза не видел? Домыслы, батенька, - дело неблагодарное :)
Валерий, ну зачем так сурово? про использование Luasocket.dll в LO я знаю, а вот про наличие функций допускающих управление в LO - это для меня действительно новость, и новость радостная. значит сабжевый механизм в ED продумали действительно лучше чем в MG, по крайней мере в теории.
Это, ведь, замечательно! Откроется целое направление: соревнование ботов. Каждый пользователь, например, будет настраивать своего бота заранее, а потом - наблюдать за ним в игре. Нужно только удобную оболочку для настройки ботов сделать, чтобы играть мог любой желающий. Помните "Змеиный бой" или "Core Wars"? Да именно соревнования типа CoreWars я и имел ввиду. так что возможно в будущих воздушных виртуальных боях будут побеждать не лучшие пилоты, а лучшие программеры :D
Валерий, ну зачем так сурово?
Всякий, кто пытается делать оценки и выводы, должен быть готов к возражениям. Ничего сурового в этом не вижу, как не вижу и опровержения своих слов.
zigzag74
24.08.2004, 16:24
Валерию .
Письмо Вам по необходимым переменным - отправил , надесюь будет прочитанно :-)
zigzag74
24.08.2004, 16:27
И на всякий случай - часть писма на форум выложу , если никто не будет против . Как бы - может кто добавит от себя пожелания ?
Обьём необходимой информации для моего тренажёра относительно невелик , и все значения удается запросить одной строкой и соответственно одной же строкой получить их .
Вот необходимые данные для моего тренажера :
- основное КУРС , СКОРОСТЬ , СКОРОПОДЬЁМНОСТЬ , ВЫСОТА относительная , число М , ВЫСОТА истинная , КРЕН , ТАНГАЖ .
- навигация КУР_АРК_1 , КУР_АРК_2 , КУР_РСБН , Дальность_РСБН , величины отклонения от РСЗ для директорного прибора .
- ПКРД величину ТВГ , обороты двигателя , температура масла , давление в маслосистеме , давление топлива перед форсунками , давление в основной и резервной гидросистемах , количество топлива (если возможно - по группам баков ) , давление в левой , правой и стояночной тормозной системах .
- разовые сигналы : пожар ( если возможно - по отсекам ) , повышенная вибрация , отказ СЭС 27 в. , отказ СЭС 208/115 в.,помпаж , топливный фильтр засорен , работа АПД , проход дальнего привода , проход ближнего привода . , сигнализация выпущенного положения стоек шасси , сигнализация открытиго положения створок шасси , сигнализация выпущенного положения закрылков , сигнализация выпущенного положения тормозных щитков , сигнализация предсрывного состояния .
- оружие сигнализация состояния подвесок , упрощённая сигнализация СПО ( 4 сектора по азимуту и всё ! ) , остаток снарядов для пушки снарядов .
В свою очередь с тренажера выдаются частоты настройки АРК_1 , АРК_2 , УКВ радиостанции , частота ИЛС/ДМЕ ( в принципе её можно использовать и как частоту РСБН ) , положеник крана шасси ( выпуск - нейтраль - уборка ) , признак север\юг для курсовой , фары ( выпуск - нейтраль - уборка ) , фары ( руление - нейтраль - посадка ) , включение аварийной НС , тормозной щиток ( выпусу - уборка ) .
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot