132 Replies
Try running without telemFFB first, both devices should have identical effects loaded
Do you want screenshots with TelemFFB running too?
Generally a few things to try first:
* Issue
reset command on both Joystick and pedals
* Reboot PC
* Try swapping to different USB ports
* Mobo USB drivers updated?I will try all those things and report back.
(BTW, joystick has worked perfectly since you sent me the firmware update for the motors)
until plugging in the pedal unit.
DCS has some unreliable FFB code when handling multiple devices it seems, so sometimes it's hit or miss depending on hardware
And by reset, do you mean "Reset Motors" on the Debug page or "Factory Reset" on the main page?
no, just enter command "reset" and hit enter
it will reset the controller
Maybe delete the export.lua and let it rebuild?
I mean for the “sometimes DCS has issues” part
Sounds dangerous (mostly because I don't understand and have a tenuous relationship with DCS stability!). What does it mean to delete and let it rebuild? (I'm familiar with a 'repair' if that' what you're talking about. Could I lose something by deleting the export.lua?
I don't think it's related to telemetry in this case, since DCS sends FFB commands only to pedals device instead of joystick
Pedals appears first in the DCS.log so maybe that's the reason
But it should send to both devices simultaneously
Did all four things above. No joy. (And USB drivers are all up to date, as is MOBO firmware)
One interesting observation: when I press the "trim release button" in the huey, it releases the spring force on the pedals. (Still no feedback on the stick, but that's what is supposed to happen to the stick when you press that button)
When the trim release is released, the spring force returns to the pedals
So I wonder if it is sending signals to the pedals that are intended for the joystick.
That's what's happening most likely
Could it be because the device ID is lower than the joystick (2052 vs 2055)
Try changing pedals to 2054
That’s actually a pretty good idea
I have both devices running as well and never had any such issues, but my pedals have a higher number than the Joystick I think.
still testing, but resetting device ID to 2054 appears to have worked!?! It appears later in the controls list (I had to remap controls like it was a new device)
OK, now the stick is working properly, but the spring setting I have applied in Configurator to the pedals (55% for warbirds) is not applying any spring pressure.
In configurator it says "Controlled by Application"
when I exit DCS, the spring force returns to the pedals.
Spring force to the pedals should be controlled by TelemFFB as I recall
I was running without it just now. Let me try to start it up with TelemFFB
correct
Is there a setting where to control the pedal spring force in TelemFFB? When I have (for testing purposes) 65% spring applied, I can feel the spring pressure very strong before I start DCS. Then I start DCS with TelemFFB started and jump into a P51. The stick forces work as expected. The pedals go lvery much softer with almost no spring pressure applied (and no recentering force, which was present before starting DCS)
I see an override DCS spring, but wouldn't that override both the stick spring input from DCS and the pedal spring? I don't see anywhere to enable only rudder spring DCS override
in telemFFB you configure pedals and joystick settings separately
Ah. Show child instance!
Didn't see that
I think this was the answer. I will continue to test.
Thank you, thank you!
I think maybe Kalktori's instructions should be changed from setting device ID 2052 to 2054 (or maybe even 2056?). But it appears that 2054 was the trick for me.
I assume it isn't the actual number but simply the fact that you changed it. Somehow DCS got Stuck on the old ID.
But that's just guessing of course
I very much appreciate both of your time. I'll continue my testing with various modules. Hiob, I saw your posting about curve settings for a strong center detent. How does that interplay with the TelemFFB settings? I'm not sure I fully understand when I should be using the configurator versus TelemFFB
And separate question, is there a way to set up aircraft specific endstops (and rescaled axis) per aircraft profile? For example, I like my FBW jets, like the F-16 and F18 to have a shorter overall throw than my warbirds and helicopters. The way I've been doing it is to apply Configurtator endstops and then just applying the settings before starting DCS. Is there a way to accomplish something like that with TelemFFB?
It doesn't. TelemFFB just provides (mostly periodic) effects like guns and stall shudder or ground rumble.
The settings in VP config adjust how the stick feels, how strong the spring is (unless it is controlled by the application, but you set the maximum spring strength here) and how damping and friction and so on feels.
I thought I saw a post in the Crosswind pedal post where you had posted about curve settings to have a strong centering feelling on the pedals. But maybe I was misunderstanding.
You can setup and save several VP configs and have them loaded by TelemFFB according to the Aircraft you fy
No, that is correct. DCS actually doesn't fully support FFB pedals. So you can use your own curve (set pedals to static vs dynamic in TelemFFB)
TelemFFB fills in the gaps so to say
Ah, I see. Lots to learn and play with. Where are the profiles to set up multiple VP Configs if I wanted to play with that?
Import/Export?
Suggest having a look at the manual for TelemFFB.. Here's a direct link to the dynamic configurator profiles section: https://docs.google.com/document/d/1YL5DLkiTxlaNx_zKHEYSs25PjmGtQ6_WZDk58_SGt8Y/edit?tab=t.0#heading=h.hlw8w12wb0nz
Google Docs
VPforce Rhino Manual
VPforce RHINO FFB User Manual Version 0.81 (WIP) Table of Contents 1. Welcome 1 2. Getting Started 3 2.1. Technical Specifications 4 2.2. Physical Setup 5 2.2.1. The VKB Adapter 6 2.2.2. The WinWing Adapter 6 2.2.3. The RHINO Throw Limiter Adapters 7 2.3. Initial Connection and Updating ...
Just save them (export) to different names and assign them in your TelemFFb
Awesome.
Thank you! (But also, I've spent several hours reading that manual...and don't understand most of the stuff in it.)
RTFM is always an option of course! 😂
(I don't think I knew what dynamic configurator profiles meant.) For a RTFM to work, there needs to be a baseline understanding! I've made it pretty far with the manual but still a lot I don't understand!
Don't worry. It needs some messing around and trial and error to fully wrap your head around the possibilities.
Definitely. I get something new out of the manual every time I look at it.
Everybody had the same learning curve. Me included of course
LOL, next to try IL2. Not sure I'm brave enough for that today! Appreciate everyone's help on coming up to speed. Maybe I'll be able to help the next guy!
I've spent a lot of hours writing the manual for TelemFFB, but I'm not a professional document writer 😅 If there's something that doesn't make sense, feel free to ask.
I'm certain it's a "me problem" and not a "you problem". Thank you for your efforts...and I will definitely ask for clarification if I can't figure something out from the manual!
Be aware though that Il-2 is not as well supported as DCS. I certainly can't help you there
Noted. DCS is where I spend 85% of my time anyway. Hoping to try MS2024 when more of the VR stuff gets figured out. My main excitement over the FFB pedals is the ability to change the springs, damper, and feel without having to crawl under my desk and change things out...which was possible but still annoying in DCS. This appears to be a great solution for that. (And I hope more in the community learn about it and experiment...I'm the first one in my 'group' to take the plunge on both the joystick and the pedals)
That was my motivation to design the Crosswind mod. To quickly and easily switch between fixed wing and helicopters. But changing the feel and having effects is very welcomed bonus.
People like you and Walmis (and others) amaze me with how much you are able to give to the DCS community. Using your expertise not only to figure out cool shit for your own use, but also for others. Much respect.
Oh well, I just designed them for myself…..😄
And cudos to walmis, because without the VP Rhinom eco system I‘d never thought of doing something like this.
@Hiob or @walmis , do you have any suggestions for keeping DCS from continuing to do this? I haven't identified when or why, but after a couple of days testing, DCS will occasionally appear to revert to the original problem I was having. If I change the USB Product ID (I've been alternating between 2052 and 2054), it always seems to go back to working. But interestingly, I've noticed that it doesn't matter where DCS puts the pedals in the log. For example, attached is a DCS log from the most recent time when I "fixed" it and it was working, and you can see that the pedals initialize first. It's annoying to have to change IDs (because I have to re-configure TelemFFB too), but at least its working. Have you had reports of this happening to other people? I've done a recent full, slow repair of DCS but I'm open to continuing to help troubleshoot. The problem is, my understanding of most of the technical stuff is pretty limited.
BTW, I've experimented with waiting to power on the pedals last when booting my computer, powering on the joystick last, etc. That didn't seem to affect anything.
https://www.uwe-sieber.de/usbtreeview_e.html
Can you show your usb topology using this utility?
yup, let me see what I can do.
You'll see that the devices are now plugged into my powered USB hub; that's so that I can individually enable or disable them from my cockpit seat. When I was testing before and we were troublehooting, I had both the pedals and Joystick plugged directly into the PC to eliminate that being a problem.
(And it was still doing it). When I reconnected everything after we originally identified the problem, it all worked just fine on the USB hub too. So I don't necessarily think it is an issue with using the USB hub since it was also doing the error when plugged directly into the PC.
Not sure if that's helpful, but maybe
I cannot yet figure out what "triggers" it, because it has been fine after reboots, fine after restarts of DCS, and then all of a sudden it won't work. So I'm still trying to identify the pattern of when it stops working.
Uhh, that's a lot of devices that potentially can cause conflicts
Surely not more than most simmers. Throttle, stick, collective, pedals, switch panel, microphone, bass shaker, and VR headset. A pretty common setup in DCS, I'd think.
Windows input subsystem sometimes works on mysterious ways
A lot of folks' setup is way more complex than mine (although, probably not two FFB devices)
Can you unplug most of it and test DCS - both pedals and joystick should receive same trim signals
Without telemFFB
I can probably unplug the panel and the USB microphone, and the bass shaker, but much of the other things would be required to test it (like the VKB grip, collective, Pimax, etc). And it's working right now (after re-numbering the ID). Should I wait until it stops working again?
Like right now, even without TelemFFB running, the stick is providing the correct force (trim release on the Huey works). I don't know how to trigger the "incorrect" condition, but I know it happens as soon as I spawn into a mission.
My simplistic way of thinking about it is that DCS become "confused" because the "guidFFDriver" is the same for both devices. I'm not sure what that means though! Is there a way to disable "ForceFeedBack: yes" on the pedals? That's not required, right, because TelemFFB handles the FFB for DCS.
So, like if DCS only saw one FFB device, the problem might not exist?
You can also try putting both devices on different usb branches, might reduce chances of resource conflicts
I also tried that for a while--I tried it with only the pedals plugged into the hub (so I coudl control when they are turned "on" to windows with a touch of the button on the hub), while having the joystick connected directly to the PC.
Did not appear to change the behavior, at least to my notice.
Hey, I’ve never experienced such behavior, so I can’t really help. From my general experience/expertise I would agree with Walmis that the issue is most likely caused be the amount of input devices and windows being dense as always. Probably an interrupt issue. Or one of the USB controllers raised the white flag. You are probably using USB hubs, no? Try to plug them in a different controller (check your Mainboard manual to see which ports are managed by which controller)….
Other than that, currently o ideas, sorry.
I will see what I can do about improving my "USB hygiene" and trying different controllers. If there was a way to do this all without hubs, I would definitely try--but high quality powered USB hubs are often the only answer (I've learned the hard way that good powered hubs are required for simming peripherals). What do you think about DCS only needing to "see" the joystick as an FFB controller? Like is there any way to keep it from seeing the RhinoMFG pedals as a FFB device and have it listed as "ForceFeedBack: no" like the other devices?
(And I wish I was sophisticated enough to find a manual that whowed which ports on my motherboard are managed by which controller--I've actually looked for a detailed manual for my motherboard so I could better understand when I installed an additional SSD. I found the documentation, um, lackluster at best--at least what I could find on the Gigabyte website. Maybe there's a technical document that I didn't find or, more likely, didn't understand.)
But I think that app that Walmis pointed out will probably help me understand the USB architecture better.
At least try to plug in the Rhino devices individually (without hub) in your front usbs and see if the fault persists. At least you can close in on the culprit.
Roger that. When the error first occurred (and was fixed by re-numbering the Device ID in the Configurator software), one was plugged into the "front" USB on the PC, and one was plugged directly into the back of the PC on the motherboard, which I presume are different controllers.
But I will continue to test and monitor to see if I can narrow in on the trigger. Between Windows issues and DCS spaghetti, I understand that troubleshooting this is difficult. I swear I've spent more time troubleshooting and fixing (Pimax, buttkicker, etc.) than actually playing DCS!
I do know (for anyone else who may follow this thread now or in the future), changing the USB Product ID in the Configurator on the pedals has fixed it every time...so alternating between 2052 and 2054.
@Hiob @walmis I wanted to update you on this and see if you had any other ideas. I spent the weekend and completely revamped my USB setup, removing one hub and several unnecessary devices. As suggested, I also directly plugged both Rhino devices directly into the PC, one on the rear motherboard and one on the front port so there is no hub in between. None of this helped, and every time I reboot the computer and start DCS, the Rhino joystick is not recognized by DCS as the "first" control. I have to start DCS, quit DCS, manually re-number the RhinoMFG pedals, restart DCS and then it works. I've also searched for this in the DCS forums and can't find anything that seems relevant. I tried disabling "hot plug"; I tried connecting only one device at a time while in DCS; I tried having all devices disconnected except the Rhino Joystick and then adding the devices in. Nothing seems to help except re-numbering the USB ID.
(I should add: the joystick base works totally completely normal when the pedals are not connected.) As a possible interim imperfect solution, is there a way to use the pedals without connecting them via USB, with the two pot dials being used to adjust spring pressure and damping without input from the games? Yes I would lose the additional effects that I'm really excited about, but the two main things for me are quickly adjustable spring and damper rates.
Sorry, I can't really help, because I haven't had anything similar happen to me. And currently I can't think of any other thing to try. I hope Walmis has more ideas.
Rather than just changing the PID and resuming as you have been, have you tried to change the PID to "something else", then change it back to the original value and then see if it starts working again?
That should give some more data as to whether the issue is on the DCS side or maybe something corrupting in the device config. I.e., is it the actual changing of PID that resulves it, or simply the re-flashing of the config on the device.
Good thought. I tried that, and that didn't help. I am virtually certain it is a DCS issue and it has to do with the fact that DCS "sees" both devices as FFB and sends all axis input to whatever it thinks is the first device and no input to the second device. I'm almost contemplating a clean install of DCS if that wasn't such a huge, huge hassle (dozens of modules and single player campaigns--I don't want to tediously re-import all of the device mappings. I wish I knew what was different with Hiob's settings that he doesn't have this problem. I also wish I understood a little more about DCS's "guts" to see if I can just disable DCS from seeing the pedals as a force-feedback device (since there is no reason for DCS to send input to the pedals since everything is done through TelemFFB). If DCS didn't see the pedals as FFB, I think the problem would be solved.
The thing is, when it works, everything is awesome. And when it doesn't work it is super frustrating! Typical DCS.
Do you think starting a thread on the DCS forums would be helpful?
I think this issue is somewhat deeper, maybe the OS and hardware level coupled with bad DCS input system regarding FFB. Which Windows version you're on btw?
It's Windows 11.
I can give you more specs on the system, but it is basically one year old--pre-built NZXT system with high-end specs. 4090, etc. It has been rock solid and this is the first input issue I have had. I basically only do flight sims on it, and almost exclusively DCS these days. My peripherals are as follows:
Joystick: VP Force Rhino with VKB Gunfighter grip (and adapter/black box); 2 USB
Pedals: Crosswind MFG with VP Force conversion (parts bought from Walmis and Kalktori) 2 USB
Collective: Virpl Apache Grip and Collective; 1 USB
Throttle: VKB Stecs Standard; 1 USB
Control/Switch Panel: VKB GNX-SEM; 1 USB
Wired Keyboard: 1USB
Wired Mouse: 1 USB
Bass Shaker: Buttkicker Gamer Plus; 1 USB
Haptic Pad: Ushake-6; 1 USB
VR: Pimax Crysal (OG); 1 USB
Microphone: USB voice mic; 1 USB
UPS: Cyberpower UPS; 1 USB
The Rhino Base, VP Force Pedal Base, Mouse & Keyboard, Pimax Crystal, and U-Shake6 are each connected to USB ports directly on the PC; the other devices are connected to two different powered USB3 hubs.
Problem with that is, that plenty of people use more than one (Rhino-) FFB device without issue.
You mustn’t bind the original crosswind axis btw. Make sure that the rudder axis is ONLY bound to the FFB device.
Yup, the original crosswind axis is not bound (the pedal brake axis are bound, but not the pedal movement axis).
I just realized that even though the drivers are all up to date, the MSI Motherboard bios is a couple of revisions old. I'm going to update the bios and cross my fingers that it doesn't cause my system not to boot!
That could indeed help with USB-controller issues. What does the changelog of the bios say? Any word about USB?
I thought I was crazy that I couldn't find the changelog. Turns out, MSI doesn't really publish a detailed one. It just basically says "fixes". It's a MSI Z790 Gaming + Wifi. I now have the latest bios (released in October 2024). I hadn't updated the bios since February 2024. I'll continue with the testing.
Initial testing after firmware update shows no change. For now, the only thing that works after a PC reboot (this is my current process): Open configurator, open TelemFFB, open Loopback; Start DCS; Launch instant mission (to confirm no FFB forces on stick); close DCS; close TelemFFB and Loopback; use Configurator to change Pedals to either 2054 or 2052 (depending on what was last set); apply changes; store changes; Open TelemFFB to change Device ID; restart TelemFFB; Open DCS; Launch instant mission and confirm that FFB on stick is working. As you can see, that is a lot of steps, but it appears to work consistently--but I have to do it every time I reboot my PC or if DCS crashes (which only happens occasionally, but more freuquently since the last DCS update)
(that was the text that was in Red in discord, which I'm still not sure why it was red and didn't post. Sorry)
Not sure if this file is helpful, but it is the full report from USBTreeView. I don't see anything weird, but I also don't know what I'm looking for.
Can you for example open and control both pedals and joystick center point using FEdit:
example here:
https://discord.com/channels/965234441511383080/968208779084701716/1301548730805260418
I will check it out and report back.
@walmis, yes, I used FEdit as you showed and controlled both axis in the joystick and the axis in the pedals. I also updated firmware (x3) and updated configurator. Have not seen a change in behavior. I still need to go through the re-numbering every time I start DCS after a reboot, and occasionally at random like after a DCS crash.
Well, crap. I spoke too soon. I just remembered: I updated the firmware and Configurator software last night after a successful play session and hadn't tested. Just logged onto DCS and now, after the firmware update, the "trick" is not working. Even after re-numbering the pedal USB ID, now no forces are felt on the stick at all. When I'm out of DCS, the default spring force returns. But something in the firmware or software update appears to have un-done whatever allowed my workaround to work consistently.
Confirmed. I cannot seem to get any stick input into the joystick from DCS. When I use TelemFFB to "Override DCS Spring" it works, albeit without any of the force control DCS provides. It seems to work OK for fly-by-wire jets and helicopters (where there is no real stick input) but things like the F-14, F-4, and warbirds it is definitely sub-optimal. I sure would like to figure this out; the only alternative seems to be to scrap the idea of FFB pedals (because everything works just fine when the pedals are disconnected).
(Note, for anyone who doesn't read the whole thread, this is a change--in that I used to be able to get FFB from DCS after closing DCS, resetting the pedal USB ID, and restarting DCS. That no longer works.)
Seems unlikely, but what if you revert the firmware? https://discord.com/channels/965234441511383080/968208779084701716/1353845694615781448
Have you tried backing up your save games folder and trying with a new folder? Just bind the basics and let TelemFFB install itself in export.lua?
This is extremely weird. Many people here run two or 3 rhino devices with no issue.
I'm not sure I understand what you mean by trying with a new folder and just bind the basics and let TelemFFB install itself in export.lua
Have you tried using devreorder to alter the order in which DCS enumerates the devices? See if you can alter the behavior?
Interesting. Never heard of devreorder. Is it an app? I have wondered if there was a way to change that (and have experimented with keeping the pedals off until after I boot DCS to accomplish this).
Rename your save games folder and restart DCS. It will create a new folder. No mods or device input profiles or export script will exist.
TelemFFB will reinstall itself.
Just bind the basic axes and critical button bindings to fly enough to try to reproduce.
If it doesn’t change the behavior, you can just delete the new savegame folder and rename the original.
TelemFFB will reinstall itself.
Just bind the basic axes and critical button bindings to fly enough to try to reproduce.
If it doesn’t change the behavior, you can just delete the new savegame folder and rename the original.
I’m not %100 Sure it works for DCS but I think it will. It’s more commonly used for IL2 which has an 8 device limitation. But you can set the enumeration order or even hide devices. Might take some sleuthing on the DCS forums to find the right places to put the files.
Here’s a start. https://forum.dcs.world/topic/166716-hide-delete-input-devices this is an IL2 post, But it links the GitHub repository and explains how to generate the base file and create the ini file that determines the order and /or visible devices. https://forum.il2sturmovik.com/topic/72473-so-you-went-and-bought-too-many-peripherals/
Here’s a start. https://forum.dcs.world/topic/166716-hide-delete-input-devices this is an IL2 post, But it links the GitHub repository and explains how to generate the base file and create the ini file that determines the order and /or visible devices. https://forum.il2sturmovik.com/topic/72473-so-you-went-and-bought-too-many-peripherals/
ED Forums
Hide / delete input-devices
Hey, beside i like flight sims, i also like race-sims. I use my Simseat for flying and driving. Because of that i have multiple devices plugged in, f.e. a H-Pattern shifter, wheel and pedals. It happens that i have REALLY alot of devices in the DCS>settings and its really annoying to scroll to...
IL-2 Sturmovik Forum
So you went and bought too many peripherals...
Il-2 supports up to 8 devices. It's possible to exceed that limit, either because you have multiple vjoy devices, have racing gear attached in addition to your flight hardware, or maybe you just went a little wild building your home cockpit. This is a short guide to fixing that problem. If You On...
I will definitely try this. And also google devreorder...is that a specific DCS thing or more of a Windows utility?
Ah, got it. I'll read those.
It’s a GitHub project. As I understand it, it intercepts the directx calls for device enumeration
Do you think it's a good idea to downgrade firmware too? (When I first got my joystick base Walmis sent me a beta version of a FW because I was having disconnects...which went away. I'm not sure which version it was.) Also, I presume you want all the VPForce devices to have the same version of the firmware, right?
If you know what version you were running where it was partially working, you could change the “force” build number in the URL for that post I linked. If you change the version number, hit enter and then refresh the page manually to get it to actually load the build in the web installer.
Only with a few specific features does telemffb actually care what version is running.
Different versions should generally be fine unless you are making use of the dynamic configurator profile push feature (older configurator may fail to push a profile to a newer firmware, etc)
Only with a few specific features does telemffb actually care what version is running.
Different versions should generally be fine unless you are making use of the dynamic configurator profile push feature (older configurator may fail to push a profile to a newer firmware, etc)
Got it. I'll go back and look at my messages and try to figure it out. Thanks for your help. I'll report back. I'm going to step away from my computer so I don't get too frustrated!
Before you do anything too drastic, try disabling the pedal trim setting in TelemFFB (doesn’t exist in helicopters). That setting sends the axis position over IP into the export script which then gets fed into the game via the LUA api. Some people seem to have some internal firewall issues with that feature.
Would not cause the previous behavior you were seeing, but could be a cause of “no longer working at all” As I said though, it shouldn’t affect helicopters.
But then I guess your current issue is with the joystick not working….
A quagmire for sure. I’m sure we can back into the root cause with enough prescriptive troubleshooting.
Would not cause the previous behavior you were seeing, but could be a cause of “no longer working at all” As I said though, it shouldn’t affect helicopters.
But then I guess your current issue is with the joystick not working….
A quagmire for sure. I’m sure we can back into the root cause with enough prescriptive troubleshooting.
Preliminary testing after renaming Saved Games folder is promising. I still need to try some things, but I'm not sure where to go from here, in terms of re-building all my settings (like everything from my "Special" settings, all mappings, etc.)
First thing I would do is dump
<old>Saved Games\DCS\Config\Input back into the same location in the new save games folder. That should give you back all your bindings.
Test
Then start re-introducing other things that add themselves into the export script (shakers, SRS, motion platforms, etc).
Test after each
Then start introducing mods that are installed in the save games folder.
Eventually you should find the culprit, or, you will rebuild a clean and working save games folder (🤞 )Where are the graphics and other non-input configs saved? I'll do this methodically! Thank you
Not sure where everything is. Hopefully things like the graphics settings and “special” settings shouldn’t be too hard to recreate via screenshots. (You could swap names for your save games folders and load with the old one to grab the screenshots).
I know there’s a way to tell DCS which save games folder to use but it’s probably easier just to use the rename method
I know there’s a way to tell DCS which save games folder to use but it’s probably easier just to use the rename method
Good thinking
Well, I copied the Config/Input folder over from the old to the new. And it initially looks like none of the bindings are recognized, even though all the folders are there. Not sure what that means (and I sure hope I don't have to remap 20+ aircraft and 5 devices!). I also tried copying the contents of the Config folder to see if that would help. Still not recognized. Hmmm.
Did you make a full backup of the
saved games/DCS dir ?yes
And based on what Number481 said, I tried copying just the Config/Input folder from the backup to the "new" fresh one (to restore my mappings). The problem is, it's still showing no mappings for modules (except the small handful of basic things I mapped for initial testing)
Hmm, I don't see a reason why it wouldn't work
Me either, based on my online reading. I'll try again tomorrow.
First, I led you slightly astray initially yesterday, hopefully you understood what I was trying to say. You don't want to duplicate the whole 'Save Games' folder, only the 'DCS' or 'DCS.openbeta' subfolder.
Depending on where you started with your install and what you've done since they unified the release and openbeta branches, you may have multiple save games folder. What does the file structure look like under save games? In the root game directory, there may be a file called
If this exists, the text in that file will dictate the save game folder that DCS will use.
If the file does not exist, it will use the "DCS" folder under save games. For example, I still have the openbeta file structure because I never bothered changing it. So my
Depending on where you started with your install and what you've done since they unified the release and openbeta branches, you may have multiple save games folder. What does the file structure look like under save games? In the root game directory, there may be a file called
dcs_variant.txt.If this exists, the text in that file will dictate the save game folder that DCS will use.
If the file does not exist, it will use the "DCS" folder under save games. For example, I still have the openbeta file structure because I never bothered changing it. So my
dcs_variant.txt says openbeta. This means DCS will use the DCS.openbeta folder.
Lets make sure we understand how your file structure is setup and what is in use
No, I definitely understood what you meant. I'm on the new branch of DCS, so I have everything under c:\users....\Saved Games\DCS. I just renamed the DCS folder in Saved Games to "DCS-Original" and let a new one be created.
However, I think I see why when I copied the "Config\Input" folder, nothing appeared to have worked: in the "new" version, the input IDs aren't exactly the same as in the original version. Like specifically the Rhino FFB Pedals number in {} is different and some of the other file names are different. I'm still troubleshooting, but I figure it MUST be related to this.
And I have no explanation for this, but on my test module (I'm using the Huey for ease of testing) when I copy "LEFT VPC Rotor TCS {F5E252C0-1572-11ef-8001-444553540000}.diff.lua" from Original to New (and there is a "LEFT VPC Rotor TCS {F5E252C0-1572-11ef-8001-444553540000}.diff.lua" file already in the New 'Input\UH-1H\joystick' directory), and then restart DCS, the Original mappings aren't recognized and DCS creates a new LUA file. I really don't understand what's going on.
Original:
New:
(Note, in my testing, I opened DCS and tested the Original at 9:34 this morning; it was not 'working' as described...all mappings worked but no FFB. Then I renamed the folders and started DCS with the New saved games folder and set up test mappings, only pitch, roll, rudder, collective, and trim release. It does work with FFB.)
Note, the {} ID numbers and LUA file names appear the same in the Original and New folders, with the exception of the Rhino Pedal device. I would expect that I could copy the LUA from Original to New and have it work and pick up the mappings associated with Original, but that's apparently not working.
OK, now this is getting weird: I just reverted back, renaming the folders, so my Original folder was the active DCS in Saved games. Started a free flight with the Huey and got no FFB, but I also noticed that the controls were jumpy, so I went into the control mapping menu. Sure enough, all the other devices were as I left them (with their intended mappings) but the "default" assignments were added to the VPForce pedals (so a bunch of buttom mappings and several different axis). That definitely was not there the last time I booted with the Original folder. So I "cleared" the inputs on the pedal device and just re-mapped only the pedal axis to the FFB pedals and saved. It then created a new set of LUAs (one for each device with the time of the save); however, the new LUA for the pedals has the same ID number as the LUA in the "New" input directory. Except then when I closed DCS and opened it again, FFB still did not work. Here's a screenshot of the "Original" input folder after what I just described. You'll see that there are now two RhinoPedals LUAs and everything else looks the same, except with a new time stamp.
As a test, I went back to the New install and in the Huey, for each input, selected the "load profile" option for each input (except the FFB inputs) and selected the LUA in the Original folder. That appears to have successfully imported the button mapping for each device and it appears to work. However, that's not a great solution because of how tedious it is to manually load the profile for every module in every device...because of all the clicks involved it would probably take hours. But does any of the above give clues as to what is going on?
Also, as a rueful, humorous aside: I just booted up IL2 for the first time since adding the FFB pedals. It works perfectly, TelemFFB is working beautifully, and everything just worked with no tinkering. Such a frustrating comparison to DCS.
Well, changing either the PID or the Device Ident in configurator will generate a new USB device ID and DCS will se it as a new/different device. While it should generate the same USB device ID for a given PID/Ident pair, changing them will make DCS see it as a different device. This would explain why you have multiples for the same device in your old folder.
Not sure how python handy you are... in theory you could use this script with an empty "DCS/config/input" folder after having started DCS once to import all your bindings profiles using the current USB name into the new folder...
https://github.com/bobmoretti/dcs_input_restore
GitHub
GitHub - bobmoretti/dcs_input_restore: Restore your DCS bindings af...
Restore your DCS bindings after reinstalling windows - bobmoretti/dcs_input_restore
Well, that's kind of what I was saying. Copying the LUA files over doesn't appear to work for some reason (even with the same device IDs and the same LUA filenames)
That's the part that doesn't make sense to me. I would think that if the filename is identical, it should work. But for whatever reason, it doesn't.
during any/all of this have you done a slow repair on DCS? Just to make sure the game files are clean?
At the beginning of my problems I did. I'm not against trying it again. Have not done so since this week's patch.
I'm going to run my daughter to swim lessons and come back and tinker some more. Also, re: changing the PID...I did not change the PID or Device Ident between starting DCS in the "new" and "old" config. That's what's confusing. Yes, I would expect different file names if I changed that in configurator, but I hadn't done so.
(I should have mentioned, for my testing purposes, in my "Original" DCS UH-1H folder, I deleted several old LUAs that were days, or weeks, old...just to make sure that wasn't somehow interfering with things. There were, in fact, old LUAs from when I had changed FFB device and Ident names...so I deleted those to see if they were what was causing the problem. They weren't.
But I'll try a slow repair when I get home and see if that helps.
Also, just FYI, I don't have anything super weird in my DCS install. Mods in OVGME, the Way, SRS, OpenKneeboard. A bunch of stuff that I think is pretty standard in most players' installs. Thought I'd just mention that.
Just finished slow repair. No change to behavior. I'm still trying to figure out why copying a LUA with the same file name does not work in the New folder, but loading the profile (from the same file) does work.
OK, I have no explanation for this, but after doing the slow repair I just changed back to the New folder to do some further testing. In the controls folder, the Huey is the only aircraft with any mappings. I just launched the Huey...after making no changes, computer still powered up from before, no USB or Ident changes, no changes other than the slow repair. And now, for the first time since trying the Saved Games\DCS rename, the FFB is acting the same as in the Original...meaning no FFB at the stick. There are no additional LUAs created, nothing. I'm seriously don't understand what's going on nor do I understand how a slow repair could have caused this.
Did you make sure to re-enable FFB globally in the settings? That would have been cleared probably with the new savegames folder
It was enabled. At least before the slow repair. Checking now, but I can't imagine the repair unchecks that. Also rebooted my PC to see if that changed anything.
Yes, FFB box is checked in Misc. settings.
God dang it. I think I figured it out!!!
This is a wild one, and I don't know the "fix" yet, but it has to do with SimHaptic, the application that provides haptics to my buttkicker and Ushake6.
As mentioned above, after my testing this morning, I launched IL2 for the first time. IL2 auto-launches SimHaptic (SimHaptic also auto-launched with DCS in the Original install, but after I renamed Saved Games, it did not). I noticed that in the New export.lua, two lines had been added that weren't there before:
--[[RKAPPS_REFERENCE]]dofile("D:\SimHaptic/Plugins\DCS\rkApps_Export.lua")
--[[SIMHAPTIC_AUTOSTART]]os.execute('start "" "D:\SimHaptic\SimHaptic.exe"')
When I deleted those two lines from export.lua in the "New" folder system, FFB came back.
So then, I restored the Original saved games folder and removed those two lines from the export.lua there too. Bam: FFB working in the "original" install.
I see they haven’t fixed it yet…. https://discord.com/channels/1134464276808093766/1268033958168498288
WHAAAAT?!?!?
I told them exactly how it was failing (at least as far as can be seen externally)… doesn’t look like they investigated it further.
The Simhaptic auto start breaks FFB.
The Simhaptic auto start breaks FFB.
OMG
I cannot believe it was that.
Is there any way to have both? I don't care about autostart
AFAIK it works fine without the auto start.
so like literally just turn off auto start?!? OMG.
Can confirm, it was actually just the second line. I just opened SimHaptic and unchecked auto-start. It added the following line to the Export.lua (that I had deleted):
--[[RKAPPS_REFERENCE]]dofile("D:\SimHaptic/Plugins\DCS\rkApps_Export.lua")
Restarted DCS and now I have haptics and FFB in the Original install.
Yeah.. I dont know if its a DCS bug or a SH bug.. but using the export script to launch an EXE that way somehow conflicts with DCS starting its FFB effects
In the last few minutes I've tested 3 modules and all appear working. I can't believe how long I banged my head on that and it was literally that simple. Wow. I hope this might help someone else! Wow.
yup, F14, native trim works
Thank you so much for all of your help and time.
I think I learned a thing or two about DCS, but I just discovered that one on accident!
🤘 hopefully things smooth out now
Really, really appreciate it.
One other weird thing that's been happening: sometimes when I turn on my pedals for the first time in a session, the motor kicks in and sends the pedals all the way to one side. I have do do an auto-recalibrate and that fixes it. Any idea what might be going on? That's a small annoyance regardless, and I just have to do it every once in a while.
I looked back through the screenshots to see if any show your calibration values but dont see any
If your calibrated values exceed either 0 or 4096, you should adjust the belt so that the entire range is within 0-4096.
If it is out of range when it starts up, the motor might think "Center" is in the wrong direction from where it is.
I think this is what's happening. How do I adjust the belt so it's right? I thought I followed Kalktori's installation directions but I think something wasn't right. I definitely get calibration values outside of 0-4096. Is there a way of telling how much I need to rotate the small cog? (I assume that's what needs to be done? Loosen the motor and rotate the small motor cog?)
Thats almost a half rotation out of center I think...
Easiest thing to do is to
- take off the belt
- Manually set axis min max to 0 and 4096 (and apply)
- Enable spring effect at %100 (and apply) (this will center the motor)
- put belt back on with pedals centered
- then re-run the auto-calibration
It doesn't need to be perfect, but the center should end up near to 2048.. but ultimately all that matters is that the entire throw is within 0-4096
got it. Thank you.