FragBum

I'd make a backup copy of control settings and your logbook if you want to keep it. Have you done a repair on your beta version? Are your graphics drivers up to date? Is there anything in your DCS log file that points for example to and "access violation"?

Sorry I may have misunderstood the transfer curve, using the dead zone and X saturation allow me to use HALL effect devices which do not provide the necessary full input range. They only provide from 0.8V to 4.3V so I need to use the settings I used to gain full operating range. Interesting how the inputs only use that limited range, maybe because they are based on key/button inputs. Is this something that can be changed in software? Is there a way to define the input range? The problem I found in trying to set the transfer curve was in providing an offset for the starting point as you did with user curves, Y saturation seems like it can provide the transfer curve but it needs someway of offsetting the start point. For me I'd put a resistor in series with the pot so input voltage starts at the required voltage (33% or 50%) and the pot would provide an output from the desired start point to max. But! The problem is, as you say different aircraft seem to have a different starting point. Or maybe use a Leo Bodnar or similar USB interface and rotary encodes. I'll ponder over that.

What are you using to generate the input a potentiometer? And you want the input to start at a set leve and go upl?

Okay try this when in slider mode dead zone controls the top offset and saturation X the lower offset. Effectively I have about 1/3 of control voltage input but using this gives me full control range for the input into DCS. :) This might help. Video link here. :thumbup:

That's indicating your not getting full amplitude of control?? If so with slider enabled, use dead zone and X saturation to set start and end values, it should work as advertised. You will need to set dead zone and X saturation if you change 'invert" state.

You need to build a cyclic interface,.. :D Gazelle feels okay as far as input goes, it seems the "same" as Huey and Mi-8, for me whats missing is required deflection of cyclic to counter parasitic drag or blowback/blowforward CG but that's just my opinion. The cyclic is simply centric. Reducing saturation helped me initially but placing the cyclic between my legs and having an extension made it work for me. Try rolling and looping,.. link to short vid.:thumbup:

Maybe have a look here Still might be able to use your 10 turn pot.

Limited experience here but there is no concept of return to "center" and there is just slight resistance to movement of the cyclic. R44 cyclic is just so light to move. Also if you roll or pitch the aircraft and return the cyclic to neutral (center) the aircraft wont correct it self you have to do that yourself by applying the necessary correction. There seems to be a bug in the autopilot cyclic control of the Mi-8, cyclic seems normal iwith AP off. I started off modding a Logitech 3D Pro here This works very well for helicopters. Same applies to torque pedals there is not center detent. <edit> With a center detent you need to trim so the center position of the joystick coincides with "correct" input. And yes getting rid of the detent made heli simming that much better.

Alright here is a possible solution for your ADF tuning. It's the Broadcom model HRPG-ASCA#54R 200 PPR but the kicker is it's about $35USD each although can get the price down to just over $10USD each but minimum purchase is 150 units. :cry:

Well I don't know then. :huh: Attempted to start DCS and got the message saying"We're having trouble starting Oculus" Went into programs and settings selected repair Oculus with gnashing of teeth then ended up at that download page.

I have to be a tad more optimistic given that the Mi-24 needs multi-crew the Gazelle, Huey and the F-14 also need multi-crew. Yes I know the Gazelle has support for multi-crew, so too the F14 however we are awaiting ED to better support multi-crew. I know right kidding ourselves again. :cry:

We know,.. :thumbup: Just saying,.. :) :megalol:

Well a lot of modules seem to slide on aircraft carriers in MP it's common knowledge and funny to watch. :music_whistling:

Well the plane for you sir is the CE 2,.. :thumbup:

Nah, they are just getting the last few rivets of the FA 18 just spot on, shouldn't be long now,..:smilewink: :lol:

There has been a Windows 10 update that "possibly" can cause performance hits. Also if your using Rift, Oculus also did an update, but for me it just plain broke Rift, there is a patch available on their web site. I also got that effect when the Rift cable went faulty as well.

Turns out Oculus did another one of those updates we have zero control over and guess what it broke itself! But there is a patch available on their web site,.. I know it's almost impossible to think that could happen and it wouldn't happen with microsft :smilewink:

Duno about FSB, maybe? However there seems to be a fair amount of CPU usage and data moved around during start up and opening a mission etc.. I am running the "stable" version currently for testing. Single player restart DCS Caucasus map including Oculus Rift. DCS start up including Rift VR about 6 seconds. up to 3GB RAM and 1.5GB VRAM Open simple free flight mission about 10 seconds. up to 8.7GB RAM and up to 4.2GB VRAM Choose role in about 5 seconds. up to 11.1GB RAM and 6.9GB VRAM In module in about a Second, down to 9.6GB RAM and 6.9GB VRAM

Go into Options-VR and set to use mouse you might also want to limit mouse to DC's as well.

Pricing here in Australia has 2808Ti 's starting around $2000 AUD and up. :cry: 9600K $410AUD.

I'd consider 9600K/9700K Z390 chipset. I've recently built a 9600K rig I had to buy CPU PSU and motherboard as I had some other hardware available from prior upgrades and kept the Rift in the budget otherwise I'd likely have gone the 9700K. Long story short with 32GB RAM and my old 1080Ti it's a great Rift VR rig. Basically for DCS clock speed is a clear advantage, followed by GPU and fast memory!

Projects looking good there. :thumbup: I went away from bushings to bearings because the additional load by the "steering damper" would have killed the bushes over time, it works amazingly well. I have bought all my controls over to my Leo Bodbar 836 USB interface and it works well. I kept things to a level that basic hand tools is all that was needed to build and construct

I have seen some test results here on this forum which indicate similar results between SATA SSD and M.2 SSD. The difference in load times was small. I have done similar tests with SATA SSD and Intel PCIe 750 series SSD and there wasn't much in difference in load times, I also don't see any significant disk access once DCS is loaded and running. My thoughts are as DCS launches it's reading data from disc and creating the required data structures in RAM and VRAM using that data so SSD speed becomes secondary as the CPU is doing a lot of work during the load process. You could try MSi afterburner it allows you to monitor many aspects of DCS. For DCS the performance triangle is CPU clock, RAM speed and GPU, is at the moment if I read between the lines the high performance rigs sit at around the 5Ghz CPU clock, >3000Mhz RAM and 2080Ti which is pretty much a formula build. Rift VR DCS local SP basic mission RAM about ~4 GB, VRAM ~6GB DCS online MP basic aerobatics server RAM about ~6GB, VRAM ~10.7GB

I am testing on stable and I would need to force it to change and update if I wanted to. Here is the update and change relesae version info hope it helps. :thumbup: Sorry my bad re-read the question,.. Doh! :doh: :D

Are you using stable version?