sthompson

The dcs_variant feature works to let DCS find your saved games folder, but I thought your issue was with SRS. I suspect that the issue for SRS was the space in the folder name. You might want to replace that with a period to match the format for dcs.openbeta.

I don't understand this. What's the difference? I'm pretty sure that if you start DCS from an administrator account then DCS inherits those rights exactly as if it were running "as administrator." Perhaps you could add some detail to your explanation.

You obviously haven't read the license agreement. It is very clear that they have no obligations other than what is in the license agreement, and that doesn't include any promises to continue development of early access modules, or even to fix bugs. Any perceptions you have to the contrary are based on a good faith expectation. That isn't unreasonable, and I believe ED is well-intentioned in their front of store representations. But it's no contract. Personally, trying to get back on topic, I think the Chinook module looks cool and likely will be a good addition to the DCS eco-system. But I'll probably wait for some reviews before buying it. I have enough trouble finding time to use all of the modules I already own.

If you were a dev would you be more likely to abandon a module if (a) there was an ongoing stream of revenue from people who use the module to support further development, or (b) the only way to get new revenue was to work on something else? A subscription model (as in option a) might not be a complete solution, but it probably would help enormously. Money talks.

There is no combat without logistical support, SAR, etc.

If you run DCS in admin mode then it will create and reference files in the admin account's "saved games" folder, which usually is different from the saved games folder of an ordinary user. So if you switch from one to the other you may need to copy files accordingly. For years I've run DCS as an ordinary user with no problems. I also run VoiceAttack / VAICOM as an ordinary user. For that to work, VoiceAttack / VAICOM needs permissions to edit DCS files and also VoiceAttack/VAICOM files. If those programs are installed in the usual "Program Files" locations then you might need to adjust permissions since typically an ordinary user does not have permissions to modify files in the Program Files directory tree. Installing them in a different location where you as an ordinary user have permissions to modify, create, or delete files will solve the problem at some risk of security. But that's still better than giving these programs full admin rights in terms of security. You really don't want a trojan inadvertently inserted into DCS to start modifying your critical windows files, for example.

The usual advice is to start VoiceAttack (and VAICOM) first so that VAICOM can edit the DCS lua files before starting DCS. If you use the reverse order you will have problems after a DCS update or repair.

English. BTW, I tried again yesterday. I wondered if triggering the "lower, lower" message was the cause of not getting a mission complete. So instead of landing on runway 06 I crossed the beach to the north of the airport, that is opposite from the side where you get the message while crossing the beach, and circled back to land. However I still got the "lower, lower" message and no mission complete after parking the jet.

Taxied to parking at the original spot. Full stop. Shut down the engine. No mission complete score.

I did all of that, but when on final, just before landing I got the "lower, lower" call out, then after landing and shutting down I got no "mission complete." I received a score of zero, and 50 points, which isn't good enough to progress. I'm baffled.

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.