St4rgun

That's why I'm not interested in Apache so much as long as ALL my modules (about 20) looks so much differenct in VR that in 2D. Unfortunately I fly only VR, so I'm pretty much only interested in Vulkan+Multicore, but I don't care about future plans about integrated maps etc. As long as the BASIS of the visuals in VR is still not ironed out there's nothing we can speak of. And by the way hopefully we should see some serious progress in Vulkan+Multicore in the near future (originally "planned" to be deployed by Q3 2021).

If I make the assumption, that ED is somewhat profit oriented firm and not a buch of hobbyists it's highy unlikely that no roadmap exists. It's a must to know how to use the funds for the programmers, just to name one important topic. I'm pretty sure that the so called "plans" are indeed roadmaps (=plans with milestones and assigned resources), just ED doesn't want it to be public if they miss a milestone date. That's normal, but only if they doesn't treat their ordinary software users as "stakeholders". I have no idea how ED can have the right amount of financial resources to make such an enormous development. The price of each module could seem high at first glance (80 USD i.e.), but how many buyers they have? That's not a big budget concerning the number of months/years of hard development each module needs... If ED have professional users (military, firms etc.) then maybe the income from those sources can be enough to get the bussiness rolling. When we, the "armchair pilots" are NOT the highest priority customers for ED, then all we can do is wait for any development to be complete, no matter how long it takes. It doesn't matter if they "planned" something to be ready in two weeksTM, if it will take 3 years in reality, that's OK. Who cares? We can do NOTHING against it. I already asked if the Vulkan development could be speeded up by injecting extra funds in the system. I would PAY for the Vulkan (the new graphic engine in a whole) to be ready earlier to help the developers to assign more human resources. But what if it's simply impossible, like the limited human resources can't be expanded because the lack of competent programmers? According to the last and only "Multicore development report" I assumed that Vulkan and Multicore can be delivered not sooner than Q2 this year if we are optimistic, but in reality Q4 would be more realistic. But seeing the progress I would not be surprised if we should wait for 2023. We'll "DEAL WITH IT".

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.