RackMonkey

I'd forgotten about that Bodnar had an app for their boards. I'll look at that this afternoon.

It's a Bodnar card. I know my options are limited. That's why I'm checking on the encoder. There are other things that a faster encoder would help with also. I'm also to lazy to learn DCS-BIOS and Arduino programming.

Thanks, I've watched that several times but it still doesn't answer the base question. Will a 32 detent encoder move the course knob at almost a 1 to 1 ratio. Right now one rotation of the encoder only gives you about a 10 degree change on the HSI. Of course since it seems all HOTAS manufactures seem to use 16 detent encoders the Dev's could give you a more realistic ratio via the software.

Can somebody explain encoders for me? I'm going to try and build a button box. I have noticed that most on the HOTAS I have are 16 detent. I am wondering what difference the different detent models do. In particular, think of the heading bug on the F16. With the encoder on my Virpil throttle (16 detent) the bug moves vary slowly. Can increasing the number of detents speed up the movement of the bug? Is there another electronic device that I can use to get the results I'm looking for?

Your the first person I've run into with an FFB stick. I'd like to have one to play with just to see. Maybe somebody else that hates the current trim system as much as I do will give it a try and let me know what they think of my solution.

While I can see the smallest of wiggles on the stick when I try to use the keyboard for pitch and roll its a little more like the keyboard inputs have been disabled when an axis has been assigned to it. EXCEPT that the yaw works fine. My rudder peddles are mapped to the yaw axis and the Z and X keys are also mapped to the yaw. The keyboard yaw function is also mapped to the left and right hat switch on my stick and it works. It is not disabled because of the multi mapping. What's confusing is that my trim system works on the Huey and Mi-8 on all three axis without any problems. I'm wondering if the programing has changed or maybe somebody has made a small boo-boo when they coded how this should be handled since the one axis works and the other two don't. I was thinking that this is so basic to all thing that fly that this section of the code would just be a copy and paste from the other choppers.

I'm going to ignore your response since it has nothing to do with the original post and you making the assumption that I don't know what I'm doing. I was just answering dburne's question of why I wanted to do it, not asking how you think it "should be" done. By the way, my solution to ED's screwy trim system works perfectly on the Huey and Mi-8. The yaw part of the trim even works on the Apache. And it's far less confusing.

Not a dumb question but the use is unorthodox. I use them for "trim". I map the fore and aft trim hat to keyboard pitch and the roll left and right to keyboard yaw. In the Mi-8 I find the keyboard movements a bit gross but within usable limits. I set the collective to max continues and tap the trim hat forward until I start descending. Trim back one tap and I start climbing, then reduce the collective just enough for level flight. This is far easier than the snap and jerk system that ED has. I only wish that the input of one tap on the keyboard could be reduced so that the trim hat would be smoother.

From the start the Apache has felt a little to twitchy to me but I chalked it up to it being an attack chopper. I have been flying the UH1 and Mi8 for a while and they are a little more like flying a truck. Now after the last update I can't keep this thing study. It's like trying to balance on top of a ball. If it gets going in any direction you can't pull it back without over correcting and it just keeps going back and forth until you crash. I've reset all the curves trying to soften the controls but it doesn't help. Once the oscillation starts I can't get it to stabilize under the rotor again. Is anybody else have the same problem?

OK, then after reading the rest of this I hope somebody has some suggestions that I might try. The YAW works as I expect it to. On screen both the axis inputs move the peddles and the Z and X keys on the keyboard move the peddles as they should. Both are mapped at the same time. In the pitch and roll, if I have the axis mapped, only the stick will move the controls. If I watch the screen closely and I try to move the stick using the keyboard the stick does move, but it is only a little wiggle that can barely be seen. If I remove the axis mapping for pitch and roll then the keyboard will move the stick the way you would expect it to when trying to fly.

Short version of the question. The long version may follow later. When the pitch, roll and yaw are mapped to the HOTAS axis does that disable the keyboard mappings? The UH1 and Mi-8 does not disable the keyboard mapping and both or either can be used to fly the chopper.

It looks like we have all done what we can with what we have and are just going to wait for the next update to either DCS or OpenXR.

On that note what do you guys think about OpenXR's motion reprojection?

I haven't ghosted the thread but it's taking time to check all the recommendations. I also had my G2 torn apart to drill some vent holes in it to get rid of the heat it generates. I can't believe that the unit is completely closed up.

First, I switched to OpenXR. The rest of my setup is in my Sig. 1. Since I switched to OpenXR my GPU frametime has gone from 10 to 12ms up to 17 to 21ms. All my setting are the same and OpenXR is default. Nothing I change seem to bring down the GPU frametime. It's not unusable but there is some stuttering any time I'm above 15ms. And to answer your next question, I have tried moving all my setting to their lowest or off. It just stays around 17ms more and doesn't hit 21ms as often. 2. Is there any way to get the MFD image sharper? I have my texture setting on high, cockpit at 1024 every frame, MSAA at 4, OpenXR sharpness is at 40 and I increased the size of the cockpit to as much as 50 in the VR settings. I just can't find and ID ground targets with the TGP with the fuzzyness that I currently have.

Your having the same problem I am. You want to bind you KEYBOARD yaw trim command buttons to your trim hat switch. I use the keyboard yaw flight buttons (LEFT and RIGHT) to trim with. But like I was asking about earlier...they don't seem to work for everybody and we'll just have to wait for the first update and see if they fix it or if we have to repost the problem until they do.

Do you have another flight sim installed that you could try or have you tried do it with another helo...if you own one? I think the problem is with DCS and the Apache and we will just have to wait for updates to correct the problems that we are finding.

I really hate the trim systems on these helo's so I use the keyboard flight keys bound to the trim hat for pitch and yaw trim. It works great on the Huey and Hip. On the Hip one little tap on the trim switch really moves the trim a little to far but I just trim for speed and coordinated flight and adjust the collective for altitude. On the Apache the keyboard yaw works and I have it bound to the trim hat but the pitch and roll (up, down, left and right) don't work from the keyboard. I've tried remapping them to different keys with out success. I'll have to see what the next update brings.

Expanding on this question a little bit. It appears that the pitch and roll does not work from the keyboard either. The collective does work. Would somebody be able to confirm this along with the yaw problem that dmatsch has found? UPDATE-On my system I can map the yaw to my stick trim hat. I guess it's just an inconsistency with the Apache. My Huey and Hip still work the way they are mapped.

That's fine for you, but I'm 64 and can't twist the way I used to. Add that to the limited FOV that you have in an HMD and I can barely get past 90Deg. Not a good situation in a dog fight and definitely not realistic. I really love the guys that say mods take away from the immersion factor with out taking into account the limitations that VR imposes.

Flarpt expresses my feelings exactly. After 2 years of trying to get DCS to be useable in VR I've given up. I still fly DCS because it is an exceptional sim but I will not buy any other airframe from them, at least not until they pull their head out of their ass and see they need to move forward. VR is the future and as the price of the HMD's come down more and more people will move to it. ED will shortly find themselves so far behind the curve they won't be able to catch up and somebody else will step in and take the crown...along with the revenue and ED will just be another foot note in a long line of flight sims. By the way. Those of you that think you are having a good experience with their VR I can only say that you have very low expectations. I will not lower myself to a "good enough" mind set.

Can somebody explain definitively what the difference is between SteamVR per eye resolution and DCS PD. The closest I can see is that PD makes larger jumps between resolutions where SteamVR is more granular. It's impossible to decide which one to use if you don't really know the difference. Or maybe a combination of both will g2ive the best performance at a given resolution.

There will always be people who get sick. Can't help that. Just means they don't use the program I would like to see produced. Right now I can't use VRNeckSafer because it always puts me 5ft above the cockpit. I've tried every "fix" I could find and I'm not the only one with the same problem. It did work so I conclude that VRNeckSafer needs an update to properly register the pilots eye position with the updates that have come out since VRNS last work for me.

They do but they are already built into the headset. There is no limit as to how far left or right your movement is able to be tracked. No more camera on the top of the monitor with a limit of how far the camera can see the LED's or reflectors.