Особенности реализации эффектов force feedback.

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

Еще раз спрошу, только объясните как долб...у. Т.е. записывается в трек не положение РППУ (видно на индикаторе), а все таки Output?!! Есть ли разница между аутпутом и положением РППУ? Ну и наконец как работает "ожидание возврата в ноль"? Ведь там вообще в ноль даже один и тот же человек приведет в разное время?

2 Gl-ER, тоже мысль (с переносом настройки), и действительно ни кто не говорит, чтоб "прям щаз вынь да положь", естественно все это требует тщательной проработки требующей времени.

. Т.е. записывается в трек не положение РППУ (видно на индикаторе), а все таки Output?!!.

Как я понял, Output - это красная точка, т.е. реальное положение РППУ, она и пишется в трек и от нее все пляски с бубном начинаются.

А задержка устанавливается именно в инпут и от него уже расчет скорости перемещения красной точки в ноль после триммирования.

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

Меня тут посетила мысль... достаточно крамольная. Сделать триммирование по 3-м каналам, как в самолете. Некошерно? Да. Зато удобно. :)

З.Ы. По мне так сходимость треков дело десятое. Главное, что б вертушку не клевало.

Верно, но не до конца.

Извините, торопился, а надо было мне сначала обозначить терминологию, а именно, что подразумеваю под РППУ:

1. Под физическим РППУ понимаю джойстик пользователя и действия им со стороны этого пользователя в виде данных Output в игре (перемещение красной точки).

2. Под виртуальным РППУ понимаю тот РППУ, который мы видим в виртуальной кабине.

3. Соотношения между 1м и 2м настраиваются манипуляцией с осями и коэффициентами.

Так вот,

в полете манипулирование джойстиком отзывается через Output на положении РППУ в кабине, но только до момента триммирования.

В момент триммирования виртуальный РППУ начинает стремится к нулю с какой-то фиксированной скоростью (как реализовано сейчас в случае если опция ожидания возврата не используется) и при этом за отведенное для этого время физический РППУ в руках пользователя должен тоже переместиться в ноль, если этого не происходит, то получаем рывок.

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

А дальше напрашивается компромисс между этими двумя условиями - сделать настраиваемое пользователем время ожидания возврата в ноль в заданном диапазоне (какой это будет диапазон необходимо определить на практике). Например для кого-то будет комфортно 0,5 сек, а кому-то 0,9 или больше.

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

Соответственно родилась альтрнатива.

На данный момент при включении ожидания возврата центра в ноль после триммирования сим будет ожидать возврата джоя в ноль без ограничения времени. В связи с этим возникают проблемы при интенсивном маневрировании, в запаре не всегда возвращаешь точно в центр и пытаясь быстро сманеврировать сразу после триммирования получаешь отказ управления от джоя. Соответственно предложение, при обработке настройки ожидание возврата в центр сделать следующую логику: при отпускании кнопки триммер отключить считывание положения джоя до возврата в центр (как сейчас) ИЛИ на 1,5 секунды!!!

Таким образом получаем действие тримммера следующее. Игрок в отклоненном состоянии джоя нажал-отпустил кнопку триммер и ведет джой в центр, если игрок успел вернуть в центр до 1,5 сек., то начинать считывать положение джоя с момента возврата в центр, если не успел, то через 1,5 сек. после триммирования начинать считывать положение джоя вне зависимости от его положения суммируя его положение с положением РППУ (красного квадрата).

Почему 1,5 сек.? взято с потолка, в идеале нужно среднестатистическое время возврата джоя из крайнего положения в ноль.

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

1,5 сек. (ну или сколько там получится) сделать одинаковыми для всех, соответственно расхождений в треке быть не должно. Как такой вариант?

Разовью мысль, озвученную в своем предыдущем посте.

Обсуждается вариант установки задержки по времени, но есть и другой путь - манипулировать не временем задержки, а скоростью возвращения виртуального РППУ в ноль.

Поясню,

Время задержки предполагается использовать всегда фиксированное 0,5сек в моем примере и 1,5 сек в посте выше, НО РППУ в полете отклоняется на разные углы - от минимального до крайнего и поэтому оперировать фиксированной задержкой по времени нельзя, а надо оперировать именно скоростью возврата РППУ в ноль, т.к. этот параметр позволяет учесть и расстояние и время - расстояние РППУ от нуля и время прибытия РППУ от точки триммирования до нуля, т.е. чем больше угол отклонения РППУ, тем больше времени понадобится для возврата в ноль.

Если представить себе, что при ограничении по времени виртуальный РППУ находится в точке триммирования, а по истечении времени задержки телепортируется в ноль (в этот временной интервал физический РППУ должен быть перемещен в ноль иначе рывок, при чем чем боль угол отклонения, тем больше рывок), то при использовании варианта оперирования со скоростью перемещения красной точки до нуля, виртуальный РППУ сразу после триммирования начнет движение в ноль с заданной пользователем скоростью и даже если пользователь сразу не подберет комфортное для себя значение скорости возврата виртуального РППУ, кивок вертолета, на мой взгляд, будет меньше, чем при использовании задержки и телепортатора красной точки в ноль.

Может немного сумбурно, но если разобраться, то по-существу.

Не пинайте сильно :).

Возник еще один вопросик по фидбэку на P-51D — триммирование каким-либо образом на РУС «проецируется»?

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

Ну вот и яркий пример того, о чем говорилось несколькими страницами ранее. Пока дикий крик сумрак не прорежет — никто не отзовется :)

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

На вопросы трехмониторным конфигурациям уже несколько раз нулевая реакция

"Многодисплейные конфигурациии не приоритетны."(с) Chizh

"Многодисплейные конфигурациии не приоритетны."(с) Chizh

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

Вопрос риторический — ответа не требует, и так всё предельно прозрачно.

Теперь подождем ответа по теме — а именно по фидбэку и триммированию на P-51D.

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

Вопрос риторический — ответа не требует, и так всё предельно прозрачно.

 

Теперь подождем ответа по теме — а именно по фидбэку и триммированию на P-51D.

в настоящем мустанге, тримера не отклоняют рус. Соответственно и эффекта такого не надо.

в настоящем мустанге, тримера не отклоняют рус.

Уверен? :)

Я перед тем как поднять этот вопрос какое то время разбирался, благо помогли.

Триммеры в первую очередь влияют не на сам сам крафт, а на управляющие плоскости. Т.е. отклонение триммера или флетнера (дополнительных маленьких плоскостей на рулях высоты/направления и элеронов) отклоняет РВ/РН/элероны, которые в свою очередь уже и влияют на ЛА. А поскольку «большие» плоскости отклоняются, то отклоняется и РУС, поскольку связан с ними напрямую.

Причем сами триммеры отклоняются в обратную сторону — т.е. для создания триммирования на пикирование они отклоняются на кабрирование. Это я к тому, что в Ил-2 триммеры создают дополнительный «поворотный эффект» (чем народ активно пользуется), чего в реальности быть не может.

Ну, а если без теории (в которой я сильно слабоват) — посмотри на «кокпитный» РУС и покрути триммерные «колеса». Он будет на них реагировать и это явно неспроста :)

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

А что тут изложено невнятно или неполно? Не понять сказанного можно лишь в одном случае — если никогда не было «опыта общения» с мультимониторными конфигурациями. Но же я обращаюсь к разработчикам, у которых этот опыт однозначно есть — поскольку опция раздельного рендера в настройках DCS World имеется и вряд ли появилась там случайно.

Та же история и с реакцией «фидбэчного» РУС на триммирование в P-51D. Что в написанном невнятного? В «жизни» и в «нарисованном кокпите» реакция РУС на работу триммеров имеется, а на фидбэке джойстика не ощущается. Я и предположил, что либо это не реализовано, либо не ощущается по причине хренового качества G940. И хотелось бы выяснить какое из этих двух «либо» является правильным.

я уже приводил пример с "Пушка не стреляет".

Так что корректности приведенного примера, в применении к моему случаю, слегка не хватает :)

жалко времени

Если столь жалко времени, то можно было ограничиться единственным предложением из вышенаписанного — «Будет что сказать конкретно - скажу». И в ответ было бы — «Большое спасибо».

Но время (которого жалко) было потрачено на дополнительные комментарии про внятность и полноту изложения. А поскольку это было сказано в прямом обращении, то мне (разумеется) стало очень интересно, что же именно я невнятно изложил? Раз уж звучит «обвинение», то должны быть и «доказательства», без которых сказанное всего лишь неудачная попытка «изобразить умного».

Вопрос риторический, ответа не требует (дабы и дальше не тратить время, которого жалко). Тем более, что фраза «Многодисплейные конфигурации не приоритетны. © Chizh» меня вполне устроила.

А про фидбэк и триммирование на P-51D — разумеется подожду, еще раз спасибо.

USSR_Rik, я конечно уже задолбал, но тем не менее такой вариант приемлем? http://forums.eagle.ru/showpost.php?p=1901131&postcount=183

Еще по несовместимости треков, на досуге скачал трек записанный судя по всему с монитором меньшего разрешения, соответственно ничего не трогая наблюдал картину как "желтый крестик" на тумблер не наведен (очень сильное расхождение) и переключает его. Баг я так понимаю?

Трек качался отсюда http://forums.eagle.ru/showpost.php?p=1903875&postcount=1979 , воспроизводился на 1920х1200

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

... а память жрёт как прорва.

Есть какие-то конкретные данные по этому вопросу или это просто слова?

Есть какие-то конкретные данные по этому вопросу или это просто слова?

какие данные.... здесь просто логика.... в игре есть запись треков, игра при загрузке в миссию заполняет 98 % памяти.... вывод если все лишнее отключить то я думаю ига перестанет требовать столько памяти... следственно и стабильность можно будет получить.

Какая игра еще может сама себя записывать ?. а трек весит огого сколько.

зы Если разработчики подскажут в каком файле можно закоментить сие.... то смогу поэкспериментировать. :book:

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

Зачем пишешь о том чего не знаешь?

Да, по поводу файла.

Ты способен разобраться в Lua скрипте (в нормальном скрипте, а не скрипте, содержащем только таблицы параметров)?

Предполагаю, что в трек пишет не lua-скрипт, а скомпилированный код C/C++ в одной из dll. Это скорее всего. В этом случае никто и ничего не сможет увидеть. Если конечно не заняться обратным инженирингом. Но это настолько сложно, что и разговаривать здесь об этом нечего.

ZORG, только не пойми меня пожалуйста превратно. Мне все равно, кто написал подобное ты или кто-то другой. Просто в твоих категоричных утверждениях, по поводу треков, много того, что мне лично просто резануло слух, вот и все. А задача записи трэка - нетривиальная. Тут очень много трудных моментов. А сами трэки нужны. Иногда - просто необходимы. Я не помню и сейчас негде посмотреть, отключается ли запись трэков, где-то в конфигах. Вот ввести опцию отключения этого механизма (если такого нет), было бы - неплохо. Но ни в коем случае не полная ликвидация.

Естественно, этот механизм обязательно жрет некоторый объем памяти. Хотя, я лично нигде не видел постов на этот счет от разработчиков (мож пропустил). Т.е. точных данных по этому вопросу на форуме, похоже, нет. А сказать по поводу того много ли это или мало, могут только разработчики. Те, кто работает с движком.

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