А KP settings у тебя как в контроллере настроены? может попытаться в эту сторону порыть?

стоит 3
насколько я понял чем больше, тем резче

null писал(а):А железо ты уже собрал?

пока нет, хочу с софтом сначала разобраться

Pavel155 писал(а):стоит 3
насколько я понял чем больше, тем резче

Ага, ниже некуда опускать уже ...

null писал(а):Имелся ввиду протокол обмена данными между сендером и профайлером. А UDP, TCP или еще что-то уже десятое дело. Сможешь перехватить, проанализировать и задокументировать? Будет протокол - софтину вместо профайлера гораздо проще будет написать. Хотя я и не уверен что это особо необходимо.

пока понял в каком месте просана скорость и положение передачи. заметил странность - 2 байта скорости были в инверсии. например: должно 1026, а есть по факту: 2610.



(Добавление)
в принципе, остальные данные выудить не сложно. аккуратно надо данные анализировать. порт UDP - 4444.

А зачем вообще этот колхоз? Или хочется свой велосипед изобрести?

(Добавление)

null писал(а):Кстати насчет D-Box. Случайно наткулся на вот это ....
http://wheelstandpro.ru/product_1328.html

Одного не пойму, как такая дрочь может стоить столько денег???

Они, походу, на нолик ошиблись. 50т еще туда-сюда, но 500т это шизофрения. За такие деньги можно полноценный 4DOF на асинхронниках купить. Ну чуток доплатить придется.

thor_nsk писал(а):А зачем вообще этот колхоз? Или хочется свой велосипед изобрести?

может, колхоз это profiler ?

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

Ты сейчас пытаешься сделать нечто такое, которое будет работать с протоколом dbox, а его не поддерживает ГТР, РБР, Рфактор и прочие. Выходит так называемая вещь в себе.

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

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

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

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

Если всё таки хочется чего нибудь сделать этакого, я бы занялся написанием плагинов для сендера с целью расширения списка поддерживаемых игр. Можно вспомнить например НФС, фанатом которого я не являюсь, но многие тебе были бы благодарны. Или например я давно задумывался использовании кресла в 3д шутерах, наверное тоже было бы прикольно.

Так что перед тем как начинать, хорошо подумай над всем этим.
Удачи!

null писал(а):
Кроме того просто взять данные с игры и отправить их в сом порт недостаточно. Их надо еще и обработать. Для этого в профайлере есть ряд математических плагинов.
Если всё таки хочется чего нибудь сделать этакого, я бы занялся написанием плагинов для сендера с целью расширения списка поддерживаемых игр. Можно вспомнить например НФС, фанатом которого я не являюсь, но многие тебе были бы благодарны. Или например я давно задумывался использовании кресла в 3д шутерах, наверное тоже было бы прикольно.

Так что перед тем как начинать, хорошо подумай над всем этим.
Удачи!

я не хочу избавиться от сендера. я не хочу использовать профилер. на счёт математики тоже вопросов не возникнет, как мне пока кажется. (програмирую на labview, там достаточно большой математический инструментарий).

плагин вряд ли смогу написать.

я использую сендер>свой софт>желязяка (какая железяка, протокол (UDP, TCP, LPT, COM) пока тоже не выбрал) железяка тоже самодельная будет.

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

http://rk-stud.ru/2010/10/razrabotka-ctap-1/
- моя поделка (точнее дипломный проект)

если едло пойдёт, то буду освещать его на форуме (строительство, имею в виду)

в любом случае спасибо и вам и форуму. много узнал инетерсного

2 Segriv Коль Вы занялись реверсингом прогрграмм думаю будет полезно знать что часто(почти во всех протоколах) число передается младшим байтом вперед поэтому и получается

заметил странность - 2 байта скорости были в инверсии. например: должно 1026, а есть по факту: 2610.

Если-бы Вы сделали маленький настольный(карманный) сим с ранее описанными схемами управления было-бы прще все остальное(реверсинг, создание своего)

может поможет в реверсинге это для ДИРТ2:
Movememory(@sinx, @DP[56], 4);
Movememory(@cosx, @DP[64], 4);
Movememory(@pitch, @DP[48], 4);
Movememory(@roll, @DP[60], 4);
далее это нужно пересчитать в углы но и это только начало.

Movememory(@GS.Velocity.x, @DP[32], 4);
Movememory(@GS.Velocity.z, @DP[36], 4);
Movememory(@GS.Velocity.y, @DP[40], 4);
Movememory(@GS.Acceleration.x, @DP[136], 4);
Movememory(@GS.Acceleration.y, @DP[140], 4);
где @DP -указатель на буфер приема
[56]- смещение от начала,
4 -размерность);

самое страшное( сложное) пересчитать в перемещения платформы. это самое первое на что нужно ответить, - умеете пересчитать, знаете-ли математику перемещений, для скольки осей и т.д.?

diglook писал(а):2 Segriv Коль Вы занялись реверсингом прогрграмм думаю будет полезно знать что часто(почти во всех протоколах) число передается младшим байтом вперед поэтому и получается
Цитата:заметил странность - 2 байта скорости были в инверсии. например: должно 1026, а есть по факту: 2610.


Если-бы Вы сделали маленький настольный(карманный) сим с ранее описанными схемами управления было-бы прще все остальное(реверсинг, создание своего)

может поможет в реверсинге это для ДИРТ2:
Movememory(@sinx, @DP[56], 4);
Movememory(@cosx, @DP[64], 4);
Movememory(@pitch, @DP[48], 4);
Movememory(@roll, @DP[60], 4);
далее это нужно пересчитать в углы но и это только начало.

Movememory(@GS.Velocity.x, @DP[32], 4);
Movememory(@GS.Velocity.z, @DP[36], 4);
Movememory(@GS.Velocity.y, @DP[40], 4);
Movememory(@GS.Acceleration.x, @DP[136], 4);
Movememory(@GS.Acceleration.y, @DP[140], 4);
где @DP -указатель на буфер приема
[56]- смещение от начала,
4 -размерность);

самое страшное( сложное) пересчитать в перемещения платформы. это самое первое на что нужно ответить, - умеете пересчитать, знаете-ли математику перемещений, для скольки осей и т.д.?

платформа планируется 3dof на поворотном основании ( в итоге 4dof). математика несложная там. спасибо за наводочку. дома попробую, посмотрю что из этого выйдет.

математика несложная там

что Вы можете сказать конкретно

для 3dof примерно так, при условии, что моторы расположеты через 120 град.

мотор1=(П)+В
мотор2=(-Н+П/2)+В
мотор3=(+Н+П/2)+В


П-право/лево
Н-назад/вперёд
В-верх/вниз

П-право/лево
Н-назад/вперёд
В-верх/вниз

Это понятно но их нужно вычислить. Как Вы собираетесь это сделать?
Ведь в наличии углы и ускорения, а получить нужно перемещения на нужное расстояние и с нужной скоростью . И это еще не все.

ускорение пересчитываем в угол. (пример крайних положений: 0g=0 град, 1g=180 град)

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