Clogger

Nope, VR is currently a mess. I have gone from a pretty good place in terms of performance to a joke. ED does many great things with DCS but VR aint one of them unfortunately. Others can feel free to do ED's work for them by doing hours on end of tweaking but it has got to the stage where honestly I cant be arsed , I have limited gaming time available and while I certainty don't expect it to be plug and play I am not willing anymore to waste my hobby time messing around , OMMV. Hopefully multicore will sort a lot of this out , but that still sounds like a pipe dream. Edit: I know I am ranting , but got to vent somewhere right.

Just been away for 7 weeks working, updated and booted up open Beta, it's an absolute mess. Hats off for the improvements in the modules but the game is absolutely borked for VR. Gonna put the HOTAS away and just play some 2D games as DCS in its current state for VR is not playable. Hopefully by the time the CH46 gets released ED have improved the engine. Every update ruins performance unfortunately.

Yea this quite annoying, I usually just fly in the rear seat and having the CPG head all the way to left looks bad.

My current rig is a 12900k and 6800XT , if the performance increase was insane in DCS VR I would jump on a 4090, The reality is it wont be until ED sort out the engine to let our CPU's use multicore. For normal gaming at 1440p my rig is already overkill so I just don't see the point in throwing more money at DCS for marginal gains. OMMV of course.

@NineLine @BIGNEWY Lots of guys are having probs with boresighting in VR, this may be a simple solution IMHO, I don't think bore-sighting adds to much in the way of immersion but for those that do like doing it having the option in the special tab doesn't effect them. Below is one of the topics, seems a lot are struggling. If I render in my right eye VR, I can boresight fine following the procedure, but in both eye render in VR (which ED did to help users) it is not accurate at all as you have to focus on the boresight and line up a double image of the cross hair which can be hit or miss (literally).

You are removing paralax by gimping the system, you will have some paralax as the PNNVS is lower than your head. Casmo explained this in a vid and it happens in the real bird (maybe in DCS it doesn't get the paralax effect perfect) By doing what you are doing you are now telling the system you are looking somewhere else so that the FLIR image lines up with the real world. The idea of the boresight is so that your crosshair is a known datam point for targeting and not that the FLIR image lines up with the surrounding daytime real world.

Personally I can Boresight the IHADDS easy in VR , i.e all circles lining up if I have the right eye render, if both eye render it's a PITA and goes wrong. I have created a wish list topic to remove the need to boresight in the special tab, 3rd time being posted in this thread (thanks YoYo for also linking). This is a simple work around, remove the need to do it as option, it's a mundane task which doesn't add anything to the module really IMHO in terms of immersion and with the amount of different headsets etc.. this will probably be an ongoing issue.

I think the easiest option would be for ED to add an option in the specials tabs to enable/disable the need to boresight the IHADDS on a cold start. Yes not realistic (but it is a mundane task which can dramatically effect accuracy if done wrong). I am using both eye render in VR as the HUD looks better on my HMD that way. I started a topic in the wishlist section, give it a thumbs up and +1 in the comments if you agree

As we have the option to have the IHADDS rendered in in a number of ways, it makes it a bit of gymnastics routine to bore sight the IHADDS (and not very accurate in VR if using both eye render). Can we have an option in the specials tab to disable/enable the requirement for bore sighting. In a hot-start helo the IHADDS are bore sighted automatically. Thanks ED.

I have been a way at work for a long time and just hopped back in the hind and the rudder yaw AP still seems a bit of mess. I can't notice any difference since release. Kinda stage as the Black Hawk Mod has a similar system with micro switches in the pedals and they work fine. When the Hind launched there was loads of feedback on the issue but it seems to have gone no where unfortunately.

@BIGNEWY Are the team looking at the issues as per my OP ? I have edited the OP to clear it all up and added all issues in to one post. Thanks.

Thanks for the info , I will stick to not using the rudder helper option then, but I can see how your work around can be used to get the pedals centred after being left offset when turning off Yaw AP or taking over from the AI pilot. This is another option for people to experiment with. Having a separate bind to reset rudder trim to centre IMHO would also help those who like using the rudder helper IMHO. Click button and pedals are now centred and are in line with your real pedals or joystick if it has a yaw axis (with out effecting cyclic trim) adding the extra bind would not effect how anything currently works (which I feel is important). I edited my original post to better describe this possible solution.

I know how to use the trim function on the cyclic I am asking if you use the same trim button for both cyclic and rudders.

Ok so you are using the same button to set rudder trim and/or cyclic trim, correct ??

Thanks for the advise, but I don't like using the "rudder trimer'' option in the special menu (I have experimented on the Hind and other Helos) Can you clarify how you can apply separate trim to the rudder pedals that isn't tied to cyclic ?? maybe I am missing some thing here ? I thought pressing trim will set both pedals and cyclic ?? Thanks.

A lot of the flying of the Hind will end up being down to preference, however with the set up of the pedals a lot of the un wanted situations could be avoid IMHO with a simple way to centre the pedals that is not tied to the Cyclic. Personally I have no probs with how the AP systems work for flight, Its worth bearing in mind IRL they are mechanical gyros and more then likely wouldn't be perfect. its only when I turn them off or take over from the AI pilot I run into issues. I now work around these issues but I would prefer it if ED could implement a separate rudder re-rest bind.

Agreed, The difference is I guess in the Hind is, ED are trying to replicate how real systems work where as in the Gaz it is a Faux auto hover ?? But yes I like how when you turn off auto hover in the Gaz you just catch the tail and then it is doing what you want instead of having to reset any trim that has been baked in.

I started a topic about in the bugs section. We need a separate bind to reset the rudder pedals IMHO for when turning off Yaw AP, starting missions, or taking over form the AI pilot, all of those things will leave the pedals offset and the only way to center them is to hit reset trim which also centers the cyclic which in certain situations is not ideal.

Agreed, While I think a collective would be awesome for immersion but a proper cyclic would be fantastic. Hopefully one of the 3 big boys is looking to do a FFB base with the new interest in Helos. I have looked at at Virpil collective but haven't seen any good reviews as of yet. For pedals I use VKB's, would be great for them to have dampener kit or something, while not FFB it would be better. I do fly jets and Helos so a quick change kit would be great.

Below is thread I made describing the issues and difficulties I am finding with the current implementation of how the pedals work in the Hind. I don't have an issues flying around with all the AP channels on, I find you just have to be smooth. The problems are when I am turning off Yaw AP or taking over from the AI pilot really.

So more playing about today and to highlight the issue I am talking about. I have been testing the AI handover between seats and as mentioned in this thread the pedals create issues under certain cumstances. Simple Test: (no rudder helper selected in game options) Go into a stable hover , switch to front seat, let AI settle the hover, switch back to the pilots seat and then perform a 90 degree turn to the left and maintain stable hover (something you might actually do) Result: When you take back over the pilots seat the all the controls controls are trimmed, obviously this is good as you don't want to crash on take over. The problem becomes the pedals, when I do 90 degree turn I am fighting this offset left by the AI, once my turn is complete I am having to dab left rudder now to maintain a heading. While doable this starts becoming extremely awkward as my brain/muscle memory is telling me I need to right rudder in a hover plus I am only having lightly feather left which is also awkward. My pedals being center spring (VKB's) are now completely out of wack to the helo controls. To combat this you can reset trim, however as mentioned already the trim reset also zeros cyclic. I have managed to catch it and go back into hover but again this is making a simple task more difficult, resetting cyclic trim near the ground is not a good idea really. Would this be an issue at 300m in forward flight, no, but it can be an issue else where. The above is linked to the same prob with turning off Yaw AP, your pedals are stuck until you reset which cancels any cyclic trim. While resetting the pedals may not be accurate neither is the current system but rather it is just tied to re-setting cyclic. Possible Solution: I would assume there are different ways to to implement how the pedals work but adding a extra separate bind to re set the pedals would be easiest I would guess. This way you do not have to change the current behavior of the 2 ways to reset trim (double tap trim or trim reset) You could double tap set-trim to reset all, current re-set trim could still be used to cancel both cyclic and pedals, plus the extra reset pedals only needs be used if a player wants. With those 3 options it would cover all bases IMHO with out effecting currently how the module works. I would hazard a guess for those that like flying with the rudder helper, having a separate pedal re-set could also be useful. With the above , on my cyclic I would map ''set-trim'' and ''pedal reset trim'' as "set-trim'' does 2 functions.

There are a couple of collectives coming on the market, Virpil , Winwing and some general rumours that VKB and is also making one.

In a real Helo I don't have spring centre pedals, these sorts of features are not meant to replicate what the real bird does but rather enable the use of home sim equipment, the same way that we have the option of center pos trimming. The issue isn't when using AP but rather when turning it off or taking over from the AI pilot.

I have mentioned this in several posts thanks for clarifying. From what I have read the pedals have micro switches, as home simmers we can not replicate this. With the current implementation of systems in game when you turn off Yaw AP the pedals will remain offset, the only way to get them to sit back at centre is to re-set trim which also re-sets cyclic trim which is not ideal. The other prob tied to this is when taking over from the AI pilot, even if Yaw AP is turned off the AI can leave an offset to the pedals, Again only a trim re-set can re centre them. What we need is a separate way to zero the pedals that is not tied to Cyclic trim, this could be a separate bind or simply that when we as the virtual pilot touch the pedals after yaw ap is turned off or we take over from the AI pilot this registers as as we are using the micro switches and move to what we are inputting and on release they would zero.

The prob is when you hop in the front and then back into the pilots seat , the AI may offset the pedals which are left stuck, this has nothing to do with the yaw AP channel. So it needs to be just a rudder reset bind IMHO.