sthompson

Yes, that's really annoying but it seems to be a problem with Windows as much as with DCS. I recommend the following to recover, assuming you still have a backup of your config\input folders from before you started having trouble. Backup your original input folders Make a copy of the backup. You will do some editing here in later steps. Delete the current input folders, then start up DCS and make some controller assignments for one module. You don't need to make a complete set. A few assignments for each device will do. Then exit DCS. You will now have new lua files in your config\input\<module name>\joystick folder. Look at the names of those files, and make a note of the new device numbers here. Edit the names of the lua files saved in step 2 so that the old devices have the new device identifiers. If you have a lot of modules this can be somewhat time consuming. But you can use cmd scripting to speed this up so that you don't have to rename each file manually. (A combination of the "for" and "rename" commands of the cmd command shell does the trick.) Edit any modifiers.lua files in the archive from step 2 to revise the device numbers for any modifiers that use those devices. If (like me) you use the same modifiers in all modules then you can do this once and then copy the modifiers.lua file to all of the other directories where a change might be needed. Copy the edited archive back to the original location in Saved Games. My understanding is that Windows assigns device IDs when it detects a "new" device. Unfortunately that might include an old device plugged into a new USB port, or some other hardware change. So to avoid these changes, try not to move your connected devices around.

The reply suggests that I wasn't clear, so let me be more specific about what I was wishing for. Right now I can display all file types, or just one file type, but I cannot filter to any subset in between those two extremes. That's what I'm looking for. Seems like coding this would be a trivial exercise. One approach would be to have a set of check boxes for desired file types instead of a drop down "choose one" list.

While I'm a big fan of the User File section of the website, I wish Eagle Dynamics would make it easier to navigate. The big problem is that the user files are dominated by skins. For example, if you filter to files related to the hornet there are 2276 hits (as of a few minutes ago), but more than half of those are skins. Overall, as of this morning there were 21,076 items, and over half -- 12,126 -- are skins. That's more than 4 times the number of single missions, which is the next largest category. This makes it hard to find other content. When I search I'm not interested in skins typically, but would really like to know what else there is. I realize I can filter by Type, but if I want to see everything except skins that requires 12 separate searches for each of the other types that appear related to the Hornet. Some more flexible filtering would be very welcome.

I'd rather not do that. However the camera is mounted at the top and center of my 27 inch monitor, and level with the hatclip when I'm sitting in normal position. The distance from front of hatclip to camera is also about 27 inches.

"MOD" was an example from my setup. Yours would be different. For example, if your modifier was called JOY20 then you would see a line in the "Camera Transpose Mode" segment that read [1]="JOY20". Your approach of deleting the "Camera Transpose Mode" segment will probably work, but would have to be done for every potential reference to a modifier that is no longer valid. Also, it's possible that the issue is in one of your other *.diff.lua files for the module. Glad you got it fixed but it's going to be painful to recreate mappings for every DCS module!

As nearly as I can tell the red exclamation means there is an invalid or conflicting mapping. If it's a conflicting mapping then hovering over the exclamation will display more information about the conflict. In your case, the problem most likely is not a duplicate mapping but rather the entry is invalid for some reason, usually because it references a modifier that DCS can't find. Unfortunately, unlike the case of duplicate mappings, hovering on the exclamation gives no information about the problem, and since it won't display the invalid mapping there is no way to see what the problem is from within DCS itself. Here is how to fix the problem. Go into Saved Games, then your DCS folder then config\input then your module then "joystick." You should see a *.diff.lua file for the binding in question. Open that lua file in a text editor and find the entry for the problem binding where you see the exclamation. It should be somewhere in the section with header ["keyDiffs"]. I don't have the F1 module so can't find the exact string you pointed out, but here is an example from one of my modules: ["d10077pnilunilcdnilvd0vpnilvunil"] = { ["added"] = { [1] = { ["key"] = "JOY_BTN15", ["reformers"] = { [1] = "MOD", }, }, }, ["name"] = "Radar Range Switch - SHORT", }, Note that even though no keybinding is being displayed within DCS, there should be such a keybinding in the file. The name of key binding comes at the end of the entry. Note the [1]="MOD" entry. That indicates that this keybinding uses a modifier named "MOD." This is the modifier definition you need to recreate. Until you do that, DCS will not display the existing binding that is causing the problem. Once you know the name of the missing modifier you can recreate it. Go into the controls page for your module and click on the link at the bottom to add a modifier. Now define a new modifier and make sure it has exactly the name of the missing modifier. The invalid entries should now be valid and should reappear. If you use the same modifiers in other modules you can copy the modifiers.lua file from one module to the others in order to fix the problems in those modules without having to recreate the modifiers again for each one separately.

That was my experience when I moved to a new PC. Apparently DCS will not display a mapping that uses a modifier that no longer exists and instead shows the red exclamation with no useful tooltip to indicate what is going on. The solution is to recreate the missing modifier.

Having gone through this recently I can tell you that this is (almost) the solution. But by "rename the devices" I think that @Lange_666 really meant to rename the *.diff.lua files in your backup (or a copy of your backup) before you copy them into the active Saved Games folder. It's possible to write a *.cmd file script that will automate the editing of the filenames, which saves a lot of time if you have many modules. But there is another step if you use joystick device buttons as modifiers. Then you need to edit the modifiers.lua file in each input folder to edit the device names to match the new device numbers that Windows assigned. Unfortunately, there is a separate modifiers.lua file for each module. And since you need to edit the file, not the file name, this is harder to automate via a command script.

Pretty sure this is a TrackIR problem since I've turned off G effects and Head movement by G effects in the DCS settings. The issue is that when dogfighting and doing a lot of looking up and back to keep my eyes on the bogey my virtual head seems to sink into the seat. When I look forward I get the view below. This screenshot was taken from the A-4E community mod, but I have the same problem in official modules. If I try to reproduce the view with TrackIR paused I find that my virtual head position is somewhere just north of my virtual navel. I'm using a hat tracker in case that matters. I'm wondering if anyone knows a fix.

Are you running the server program on the same machine as the client for this approach? Or do I need a separate server PC?

The only way I've found to stop it is to disable the VAICOMPRO kneeboard, then restart VoiceAttack.

It gets created when you use the original installer. If you reinstalled Windows or copied DCS from another system then those keys won't be present. They aren't needed by DCS itself as nearly as I can tell. But programs like VAICOM PRO look for them to find your DCS installation.

I don't understand this comment. What do you mean by "pointing?" To be clear, I have this issue but VoiceAttack starts in its own folder "C:\Program Files (x86)\VoiceAttack" It isn't clear to me how a VA plugin "points" to anything.

Depending on how you installed in the first place you may have a registry key pointing to the installations. If you delete one you should delete that registry key as well. My recollection is that it is under HKEY_CURRENT_USER\Software\Eagle Dynamics. Some add on software looks there to find your installations.

Reinstalling isn't going to help if the anti-virus software is still blocking the file. Your error message almost always means that the anti-virus has quarantined the file in question. And reinstalling isn't needed in the first place. A slow repair downloads and reinstalls any missing or corrupted files without a need to download and reinstall everything. So you need to add an exception for the file to your anti-virus and then do a repair. In my experience you actually need two exceptions for each file caught by the anti-virus. The first would be for the temporary file in a downloads folder. The second would be for the final installation location. You should be able to get the details by looking at logs from the antivirus, which should report what was blocked and where. You also said that you are having trouble reintegrating your logbook and input settings. I can only speculate about that. Possibly the merge of stable and openbeta means that a new installation is using a different saved games folder than before.

I do not use Steam. But in the standalone version, MT.exe is in the bin subdirectory, and you should be pointing to the root directory of your DCS installation, not the bin subdirectory.

Actually you have to move your head closer to the HUD to see more of the projected image! The HUD glass is essentially a mirror, and like any mirror you get a wider FOV of the reflected image when you are closer to the mirror. I have gone back to the A-10A recently, and am finding that I can't see the entire HUD image unless I move my camera very far forward, towards the HUD. But then I can't see the instruments at all unless I look down, and then I'm viewing them at an angle. Alternatively I can zoom out to a wide FOV, but then I get fisheye distortion. I know my head is far forward because when I turn around I see my head is very far from the seat headrest. It's as if the HUD image is too large. I compared it with the A-10C II and did not have the same issue in that module. Note that this is a comment/problem associated with viewing the image projected onto the HUD, not the glass itself. I can see the entire glass easily enough with the camera moved all the way back, but then I can't see the tape at the bottom or the IAS or altitude numbers on the sides. All I see is the middle part of the pitch ladder.

If the mission creator uses the FLIGHT / PREPARE MISSION feature of the mission editor then a copy of snapviews.lua gets added to the mission. And then if you create another mission by editing that one the file is inherited. There may be other ways this could happen, but that's the only one I've found.

The problem is that mission files can have a copy of snapviews.lua embedded within. If these conflict with the copy in your saved games folder then the view settings in the mission file take precedence. Because mission files are just zip archives you can check this easily. Make a copy of a "problem" mission and rename it to be a *.zip file. Then open it. You will probably find a file config\view\snapviews.lua in there. Delete the view folder from the zip archive, then rename it back to *.miz and test. I'll bet the problem is gone. So how does this file get in the mission in the first place? One way is if the mission creator uses the FLIGHT - PREPARE MISSION feature of the mission editor. That causes a copy of snapviews.lua to be copied from your saved games folder to the mission file. And once the file is embedded, any other missions that use that mission as their starting point will inherit a copy too. A checklist for mission/campaign makers should include as a last step to open the mission file as a zip archive and make sure that there are not any unnecessary files included.

Then the controls are axes, not rotary encoders. The approach you tried first is for rotary encoders. They basically generate a button press each time you move the dial.

It is built in to the plugin, but you have to enable it through the VAICOM configuration widget (Left control-alt-C to activate that once VAICOM is running), and then restart VoiceAttack. There is a checkbox on the extensions tab. Be warned that it causes DCS to fail integrity checking on MP servers. So does the ARIO extension.

Yes. The trial version of VoiceAttack only supports 20 commands. The VAICOMPRO profile tries to install hundreds or more than 1,000 commands, depending on the extensions you enable. A VoiceAttack license is very inexpensive at $10.

You only need either the MSI file or the ZIP file, not both. It appears that your download of the MSI file did not finish. Suggest you try again. Alternatively download the ZIP file and unpack it into your VoiceAttack apps folder. Then you can find the manual with installation instructions in apps\vaicompro\documentation.

You can find an MSI installer for the current version of VAICOMPRO here: https://github.com/Penecruz/VAICOMPRO-Community/releases/tag/v2.9.2.3. All the MSI does is unpack files into the VoiceAttack apps subdirectory. After you run it, find the VAICOM manual in the apps\vaicompro\documentation subfolder of your VoiceAttack installation folder. READ CAREFULLY AND FOLLOW THE FURTHER INSTALLATION INSTRUCTIONS IN THAT MANUAL. They are important. BTW, you can get help with VAICOMPRO this DCS subforum: https://forum.dcs.world/forum/329-vaicom/ And the Community Development team answers questions and maintains help resources at their Discord: https://discord.gg/7c22BHNSCS

You might take a look at Bailey's profiles, available at Bailey's profiles have a different style from the VAICOM approach mentioned in another reply, and I find them less immersive. VAICOM, on the other hand, focuses on communicating with the AI without using the comms menu, and has much less in the way of commands for operating the aircraft itself. Both are worth considering.