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

Цитата:

---

Originally posted by Miguel Gonsalez
Валер... не в плане занудства, просто вопрос возник - почему Lua выбрали? Есть же Python... объектный хотя бы...

---

Lua - встраиваемый язык программирования по определению, что нам и нужно. Lua у всех скриптовых языков выигрывает по производительности, что для симулятора очень важно. Lua сделан очень квалифицированно, авторам удалось создать простой, компактный, гибкий и мощный инструмент. Очень многие задачи решаются на Lua удивительно просто и эффективно. Lua обладает возможностями объектно-ориентированного программирования, раз уж об этом зашла речь, в книге автора языка Роберто Иерусалимского есть специальная глава на эту тему. Lua разработан на С и имеет простой и эффективный API для связи с C. Lua работает в любой среде, где работает C. Lua эксплуатируется уже 10 лет и прекрасно себя зарекомендовал практически, в том числе и в серьезных игровых программах (FarCry). Lua - свободно распространяется в исходниках, что позволяет легко дополнять и развивать его в различных направлениях, что и было сделано в многочисленных эддонах. Lua очень прост в освоении. Мы сами опробовали его практически, и результаты оказались очень хорошими. Наконец, Lua создан в Бразилии, где в лесах так много... сами знаете :) Кстати, lua - это по-португальски луна.

Спасибо, Валер. Просветил. Что-то я маловато, действительно об этом языке знал до сих пор. Только по OSS немного...

Валерий, продолжая вашу дискуссию на simhw.com насчет Dynamic Campaigns - выскажите своё мнение о возможности разработки механизма DC внешними 3rd-party (не знаю адекватный перевод) разработчиками при условии выноса достаточного кол-ва функционала в LUA скрипты.

Цитата:

---

Originally posted by Dmut
Валерий, продолжая вашу дискуссию на simhw.com насчет Dynamic Campaigns - выскажите своё мнение о возможности разработки механизма DC внешними 3rd-party (не знаю адекватный перевод) разработчиками при условии выноса достаточного кол-ва функционала в LUA скрипты.

---

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

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

Цитата:

---

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 чтобы в будущем добавить возможность импорта данных.
У обоих схем есть одинаковый недостаток - оба механизма не универсальны в смысле выбора набора данных. То есть экспортировать можно будет только то, что будет разрешено, и соответственно при введении в игру новых параметров нужно будет делать новые экпортирующие функции.

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

Цитата:

---

Сообщение от Dmut

в связи с выходом нового патча от 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 к устройствам отображения, что позволит уменьшить используемую полосу и уменьшить вероятность потери пакета.

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

Цитата:

---

Сообщение от Dmut

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

---

Неправда, механизм ED поддерживает внешнее управление программой в полном объеме. Кроме того, ED прилагает библиотеку LuaSocket.dll, которая поддерживает все основные стандартные протоколы в Lua, а также готовые скрипты с примерами использования этих протоколов. Да и как можно делать далеко идущие выводы о фитче, которой еще никто в глаза не видел? Домыслы, батенька, - дело неблагодарное :)

Мы не выпускаем в патче 1.02 готовую экспортно/импортную фитчу, мы отрабатываем технологию этого дела в экспериментальном порядке с теми заинтересованными специалистами-пользователями, которые изъявили желание практически взаимодействовать с нами в данном вопросе, поскольку они собираются разрабатывать специализированные кабины. Пока таких пользователей всего двое. Если после выхода патча объявятся еще желающие специалисты, пишите письма мне (valery@eagle.ru) - обсудим ваши возможности и потребности.

Цитата:

---

Сообщение от Dmut

забыл добавить самое интересное - при таком подходе LO будет совместим с устройствами\программами управления\отображения инормации, сделаными для Ил2, потому что на LUA скриптах можно будет сэмулировать формат DeviceLink, а вот Ил2 понимать проги и железки сделаные для LO не будет, в виду свободного формата траффика в LO.

---

Видимо, прийдётся заранее предусматривать в этом софте режим совместимости с Ил2. Вообще, непонятно, чем обусловлен такой достаточно жёсткий механизм у MG. На борьбу с читерами это, вроде, не похоже.

Цитата:

---

Сообщение от Dmut

ещё один небольшой минус формата DeviceLink - то что на каждый UDP запрос будет следовать UDP ответ, что увеличивает траффик и вероятность пропадания пакета [...]

---

Выходит, что, в любом случае, даже при использовании только экспорта (без импорта), поток данных от внешнего софта в симулятор будет присутствовать. А что, заведомо большая (во много раз), относительно необходимой, ширина канала не спасёт "отца русской демократии"?:)
В основном-то, наверное, будет Ethernet использоваться.

Цитата:

---

Сообщение от Dmut

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

---

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

Цитата:

---

Сообщение от Dmut

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

---

Это, ведь, замечательно! Откроется целое направление: соревнование ботов. Каждый пользователь, например, будет настраивать своего бота заранее, а потом - наблюдать за ним в игре. Нужно только удобную оболочку для настройки ботов сделать, чтобы играть мог любой желающий. Помните "Змеиный бой" или "Core Wars"? ;)

Цитата:

---

Сообщение от Dmut

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

---

Мне кажется, тут нет проблемы. Честность поединков лежит целиком на совести игрока. Играющий нечестно обманывает сам себя.

Цитата:

---

Сообщение от Valery

Неправда, механизм ED поддерживает внешнее управление программой в полном объеме. Кроме того, ED прилагает библиотеку LuaSocket.dll, которая поддерживает все основные стандартные протоколы в Lua, а также готовые скрипты с примерами использования этих протоколов. Да и как можно делать далеко идущие выводы о фитче, которой еще никто в глаза не видел? Домыслы, батенька, - дело неблагодарное :)

---

Валерий, ну зачем так сурово? про использование Luasocket.dll в LO я знаю, а вот про наличие функций допускающих управление в LO - это для меня действительно новость, и новость радостная. значит сабжевый механизм в ED продумали действительно лучше чем в MG, по крайней мере в теории.

Цитата:

---

Сообщение от Mishel

Это, ведь, замечательно! Откроется целое направление: соревнование ботов. Каждый пользователь, например, будет настраивать своего бота заранее, а потом - наблюдать за ним в игре. Нужно только удобную оболочку для настройки ботов сделать, чтобы играть мог любой желающий. Помните "Змеиный бой" или "Core Wars"?

---

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

Цитата:

---

Сообщение от Dmut

Валерий, ну зачем так сурово?

---

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

Валерию .
Письмо Вам по необходимым переменным - отправил , надесюь будет прочитанно :-)

И на всякий случай - часть писма на форум выложу , если никто не будет против . Как бы - может кто добавит от себя пожелания ?
Обьём необходимой информации для моего тренажёра относительно невелик , и все значения удается запросить одной строкой и соответственно одной же строкой получить их .
Вот необходимые данные для моего тренажера :
- основное КУРС , СКОРОСТЬ , СКОРОПОДЬЁМНОСТЬ , ВЫСОТА относительная , число М , ВЫСОТА истинная , КРЕН , ТАНГАЖ .
- навигация КУР_АРК_1 , КУР_АРК_2 , КУР_РСБН , Дальность_РСБН , величины отклонения от РСЗ для директорного прибора .
- ПКРД величину ТВГ , обороты двигателя , температура масла , давление в маслосистеме , давление топлива перед форсунками , давление в основной и резервной гидросистемах , количество топлива (если возможно - по группам баков ) , давление в левой , правой и стояночной тормозной системах .
- разовые сигналы : пожар ( если возможно - по отсекам ) , повышенная вибрация , отказ СЭС 27 в. , отказ СЭС 208/115 в.,помпаж , топливный фильтр засорен , работа АПД , проход дальнего привода , проход ближнего привода . , сигнализация выпущенного положения стоек шасси , сигнализация открытиго положения створок шасси , сигнализация выпущенного положения закрылков , сигнализация выпущенного положения тормозных щитков , сигнализация предсрывного состояния .
- оружие сигнализация состояния подвесок , упрощённая сигнализация СПО ( 4 сектора по азимуту и всё ! ) , остаток снарядов для пушки снарядов .
В свою очередь с тренажера выдаются частоты настройки АРК_1 , АРК_2 , УКВ радиостанции , частота ИЛС/ДМЕ ( в принципе её можно использовать и как частоту РСБН ) , положеник крана шасси ( выпуск - нейтраль - уборка ) , признак север\юг для курсовой , фары ( выпуск - нейтраль - уборка ) , фары ( руление - нейтраль - посадка ) , включение аварийной НС , тормозной щиток ( выпусу - уборка ) .