St4rgun

This is my very reason to stop paying in pre-orders. Hind was the last one for me to pre-purchase just to see the "not-so-optimized" performance in VR when released. Fortunately ED introduced the two weeks trial method, which I will follow with Apache also. I'd rather pay full price when Apache actually releases after checking it out on my system than pay 70% but after that the module will be unusable for me.

The truth is, the average people don''t want to know all the tiny details daily basis. But having some information (even "bad news" in time) is neccessary to get the community engaged. I'm sure that ED could find the way inbetween. Check this out: https://www.psychologyofgames.com/2019/10/loading-when-were-willing-to-wait/

In my previous comment I said that the 1st and 2nd priorities are Vulkan+Multicore. I have to correct myself upon reading this whole thread. +++THE+++ number 1 priority is: Honest, clear, frequent and somehow detailed communication about ANY progress status of the development regardless if it's core or module related. If we can have this, then we'll surely wait for the others...

Vulkan + Multicore (the strong base) + VR optimization (when the base is done) - 1st+2nd priority Visuals (weather, cloud aliasing etc) - 3rd priority ... Some other important features which is not module related... - 4-9th priority Apache - 10th priority Everything else.

What is interesting, that I also had this problem exactly as you described some time ago, but I never checked the assign controls when this happened to see that DCS applied the default JOY_RZ axis instead of my settings. I beleived also, that something is wrong with the actual DCS OB and I was only able to left kick a bit at mission start. Sometimes the issue disappeared after next DCS update. Sometimes I had this issue again, sometimes it wanished. But right now I am aware of the auto-calibration feature of my TFRP rudder, that was unknown for me before. Maybe this feature caused that before any movement the rudder reports some non-existing axes, that's why DCS detects it wrong. I started the other topic because the weird behaviour of my toe brakes and I also suspected the new OB. But I did everything to eliminate the rudder hardware side error and it was a success - for me, and with TFRP. Now everything is working well. Maybe it was a bad conincidence of OB and a possible Win10 patch which related to the device issue. In this phase only some dev can have any more ideas. Maybe we should ask @BIGNEWY?

OK, it became much clearer for me. So the question is: why there's no TPR entry for your device? For me the "default.lua" is in the game folder under "\Config\Input\Aircrafts\Default\joystick\" which is OK. Now in the user's Saved Games directory there should be .lua files for ech plane you already configured correctly. Like for me the A-10C II input config lua looks like this, check out the "removed" line for the JOY_RZ, and the "added" for JOY_Z: Filename: "\Saved Games\DCS.openbeta\Config\Input\A-10C II\joystick\T-Rudder {8D238D70-89B7-11eb-8001-444553540000}.diff.lua" Content: local diff = { ["axisDiffs"] = { ["a2001cdnil"] = { ["name"] = "Pitch", ["removed"] = { [1] = { ["key"] = "JOY_Y", }, }, }, ["a2002cdnil"] = { ["name"] = "Roll", ["removed"] = { [1] = { ["key"] = "JOY_X", }, }, }, ["a2003cdnil"] = { ["added"] = { [1] = { ["key"] = "JOY_Z", }, }, ["name"] = "Rudder", ["removed"] = { [1] = { ["key"] = "JOY_RZ", }, }, }, ["a2004cdnil"] = { ["name"] = "Throttle Both", ["removed"] = { [1] = { ["key"] = "JOY_Z", }, }, }, ["a2112cdnil"] = { ["added"] = { [1] = { ["filter"] = { ["curvature"] = { [1] = 0, }, ["deadzone"] = 0, ["invert"] = false, ["saturationX"] = 1, ["saturationY"] = 1, ["slider"] = true, }, ["key"] = "JOY_Y", }, }, ["name"] = "Wheel Brake Left", }, ["a2113cdnil"] = { ["added"] = { [1] = { ["filter"] = { ["curvature"] = { [1] = 0, }, ["deadzone"] = 0, ["invert"] = false, ["saturationX"] = 1, ["saturationY"] = 1, ["slider"] = true, }, ["key"] = "JOY_X", }, }, ["name"] = "Wheel Brake Right", }, }, } return diff So if you are using the rudder at the same USB port every time then the device enumeration should find it always and use the properly configured inputs regardless the setting in the default.lua file. If you also have the correct input config lua file in the Saved Games folder and still having the same problem then I run out of ideas...

This JOY_RZ axis is really strange if your deviche should only have JOY_Z, JOY_X and JOY_Y. Are you sure, that DCS detects the "phantom" axis, or maybe the rudder's driver reports something falsely? Double checked the firmware and latest driver for your TPR? (https://support.thrustmaster.com/en/product/tpr-en/) Are you using the T.A.R.G.E.T sowftware? Did you use the Advanced calibration tool for the rudder?

Hold on for a second, I re-read your OP. As you said: "Looking into the Axis controls for the rudder, it seems DCS defaults the rudder to the JOY_RZ axis, when the one it should use, and the one I assigned to it should be the JOY_Z axis." So you are NOT assigning all the rudder axes for all planes you would like to fly MANUALLY, do you? Are you relying on the default mapping of DCS? I always map all my HOTAS axis to the proper ones for each plane one-by-one by hand in DCS menu, carefully removing all the default bad bindings (like auto binding the throttle to rudder axes etc.). It should be done once per plane upon any hardware changes, but after that I can forget it.

Now the results: 1. Freshly rebooted PC, started DCS (i'm using VR, with G2), mission editor, test. 2. Caucasus, in the air, both F-5E and MiG-19 tested. 3. I did NOT touch the pedals AT ALL (not prior booting, nor after). 4. The planes behave perfectly balanced at mission start without touching the rudder pedals. Not a sign of any left rudder proplem. After that the rudder and toe brakes work as intended I can use them fine. Tried the above after DCS restart, with the same results. Everything is working fine.

I'm using TFRP, not TPR. Interestingly the driver named FFB, I don't have any idea why... I'm pretty sure that STEP 2 is the important part, because that's what removes the misconfigured Win10 default driver from the system. I'll just start DCS and check out a quick mission as you requested. BRB with the results.

No, they are not the same. 1. First you should remove the Thrustmaster driver (from Win10 Apps&features list look for the "Thrustmaster FFB driver" and UNINSTALL). 2. After that look for the rudder device in device manager (Win10 START menu -> Settings -> Devices) and hit REMOVE to totally remove the device from the computer. 3. Now phisically disconnect the rudder from the USB port. 4. After those steps start by connecting the device to the USB port, Win10 will recognize it and automatically installs default driver. That's OK, but do NOT do any other with that default driver (DO NOT CALIBRATE!). 5. Now you can re-install Thrustmaster rudder driver. After the installatation check the properties of the rudder (Win+R -> type in "joy.cpl"+ENTER to quick get to the joystick devices), if you hit the "Properties" button, then the Thrustmaster status page should appear like this: If that is the case then you've done everything properly. Now if you move any axes or toe brakes the toe brake axes jump out the default centered position to the zero value and change according to the pedal press. At the moment of a small movement the hardware calibrates itself automatically, but you have to do that movement some times for the auto calibration to kisk in (maybe once after reboots, or once after DCS starts, I've not checked yet). If you configured everything properly then only have to move the pedals once DCS started in the main menu. If everything working well, then all the toe brake and full left pedal related issues should disappear.

I also had that max left rudder issue before my toe brakes started to unbehave (mostly in Mi-24 Caucasus Weapon range mission). Now that I did the actions I wrote the "starting with full left rudder" also disappeared, so if you did not tried yet, then give it a try. I had to learn this way that Thrustmaster is auto-calibrating itself upon slight axis movement. I do this when started DCS in the menu, just push all axes (rudder, toe brakes). After that calibration every issues disappeared.

It seem to be the auto-calibration feature of the Thrustmaster pedals. Check this out:

Managed to solve the issue, it was Win10 - TFRP driver related, not connected to the OB update. Anybody who experience the same with any Thrustmaster rudder, this is the solution: remove Thrustmaster driver uninstall device from Windows, then disconnect re-connect device, Win10 installs default driver WIN+R, then type in "joy.cpl" -> goes directly to game controllers, select the rudder -> properties, reset to defaults DO NOT CALIBRATE! now re-install Thrustmaster drivers, and check out the properties again the device should auto calibrate itelf upon a slight movement of toe brakes or rudder axis this auto calibration is done in DCS also at program start upon moving the pedals Thanks for the help!

Weird, someone posted the EXACT same problem years ago:

Double checked Windows 10 joystick calibration and TFRP own calibration tool. The rudder brakes are working properly. In DCS when in the main menu trying to configure controls can't attach any toe brake axis to ANY airplane because the axis command don't recognize the pedal push. If I attach manually by selecting it from the list then it woks, but controller starts from half the range. I'm pretty sure that this NEVER happened before the last OB patch. Shall I try some repair in DCS?

Started to investigate. It's surely rudder related, I'm using TFRP. It seems, that in DCS the brakes are half pressed initially, and if I want to configure my controls the axes reflects this. the total movement is sensed only in half. Interestingly if I delete the axis assignment then I CAN'T assign the brake axes again, because DCS can't recognize the pedal press... Strange. Meanwhile I tested it with F-16, the same problem. Can be windows calibration related, or TFRP calibration issue. Digging now.

After the latest patch I am not able to take off with an A-10C II in neither instant acition "take off" missions (Caucasus, Nevada). The thrust seems to be much lower than my wingmen's, my aircraft crawls instead of accelerating properly, so it is unable to reach take off speed before the end of the runway. I double checked my wheel brakes and other configurations. Never experienced such phenomenon before. What am I doing wrong?

Known issues: MiG-19. Communication menu doesn’t work. Refuel/rearm workaround using Alt ‘ What does it mean? How shall I use ATC or any other communications (like AWACS in the training missions)?

All we have now is that single "Multicore - Development report", and a statement, that Vulkan will not be available this year. Ohh, and some newer hard facts: the devs are making "good progress", as always, so maybe somewhere in the near future (January / February 2022) there will be something ready to test for someone. So to speak not for open testing, but for internal use for the devs. Or maybe not, because all this development is really resource-hungry (no joke). The hardest fact: NO ETA available on Vulkan. And no ETA will be available for Vulkan. Vulkan simply will be ready sometime. Somehow. But if it will be in a good enough state to share any more detailed infos then I'm sure they will. Somehow. Sometime. But surely it will be in the future. I can guaratee. During the wait check out the adventures of Vulkan in the past here: P.S. for the devs: please dont take this write as sarcasm. I am sure, that Vulkan will be marvellous, so we are waiting. Keep up the good work!

The current weapon release binding for the Mi24 cyclic stick is the following: one key for Weapon Release Button COVER open/close one key for Weapon Release which is not related to the previous cover opened/closed state The following would be much more sophisticated (the same as for Mi8): one key for Weapon Release which is not related to the RS cover opened/closed state one key for Weapon Release Button COVER open/close one key for Weapon Release Button COVER open one key for Weapon Release Button COVER close one key for Weapon Release Button (RS) which is related to the RS cover opened/closed state

Hi @BIGNEWY, Almost 3 months passed since reporting this really annoying bug without any improvements. Shall we expect a solution soon, or is it postponed to the new graphic engine's "Propellers and similar effects" development efforl as listed in the Multicore development report? Thanks.

Thanks for the idea, I was a total noob. Forgot to check the calibration in VKB software. After proper fresh calibration now everyting is perfect.

I'm using a VKB Gunfighter Mk III. base with curved extension and TM F16 grip. It's perfect for Mi8 but it seems that some curves for the Mi24 pitch axis is not correct. I always use linear assignment without curves and then check out the stick movement in the cockpit (VR only) to be in synch with my real stick movement. With the Mi24 the pich axis is really off-sync: when I try to PUSH the stick it moves much more in the VR cockpit than IRL (small movement of my real stick translates to very harsh push in the cockpit). The PULL direction is much better, but it's obvious that the assignment is not linear. I had to use some curve to be able to fly the chopper without constant pitching back and forth. The roll axis in linear setting seems OK. It seems a massive bug for me, but I'm not reporting it since someone can confirm. EDIT: It was user error, I should have checked the VKB calibration, which solved the problems. Now the Hind is a dream to fly.

@BIGNEWYBump... Can we expect some kind of regular report on the backend development also, please? Just some words. Because now everything is AH-64D related twice a week which is nice, but there could be some other interesting news also...