Munkwolf

Seems like an opinion stated as fact. I'd personally rather fly the early models over the versions we have. I would fly the A-10A over the C if it was full-fidelity and clickable. The content-to-price ratio also really has close-to-zero influence over what airframes I would purchase. Seems like an odd decision point.. like, you get more "systems", so you view it as a better value?

+1 for RealSimulator. I got the FSSB base, used it with TM Warthog, and it was good but I couldn't get it to attach as solid as I wanted. There'd be a slight pop moving vertically across center I couldn't totally get rid of. Got the RealSimulator grip, and then it felt great. The Viper is slowly becoming my main because of how great it feels to fly with the FSSB + RS F16 grip.

DCS\Mods\aircraft\A-10C_2\Input\A-10C_2\joystick, "F16 MFD 1.lua" and "F16 MFD 2.lua"

Got my shipping notice this morning as well. TCS Plus + SharKa-50 + Control Panel #1 on the way.

is it possible you just never noticed it launching it before? I'm using a G2, DCS standalone (not steam), and it's always launched SteamVR.

When similar things were happening to me (joystick gremlin deactivating), it was one of my USB devices disconnecting/reconnecting occassionally. Turned out to be a USB power issue. Got powered usb hubs, turned off the lights on my TM throttle and MFDs, turned off the "allow windows to turn off this device to save power" options in Device Manager, and moved some of my devices to a PCI-E usb card.

If you are open to external software, it's pretty easy to do. I use Joystick Gremlin to have the Warthog slider throw different button events at 0%, 20%, 33%, 50%, 66%, 80%, and 100%. Mainly to control the mixture lever in the P51 but use it for a couple of other warbirds, too. Or it might be possible to do in the VPC software? I used the VKB software to configure my MCG to have the analog hats work as an axis and throw buttons.

It's mappable to keyboard for me, running latest version of open beta

It's from some commands being defined or not in the device-specific LUA files for the modules you're having the issue with. Using A-10C APU Off as an example... Go to your DCS install folder, then Mods\aircraft\A-10C\Input\A-10C\joystick. In there you should see a bunch of LUA files. Open up 'default.lua'. Do a find in there and you should see the definition for 'APU Off'. That'll make it available for binding by joystick devices... unless there is a device-specific LUA available for the module, like... Open up 'Throttle - HOTAS Warthog.lua'. Do a find in there for 'APU Off' and it won't be in there (Thus it's not available to be assigned a key, thus being disabled in the controls screen) Possible easy solution for you is to just delete the 'Throttle - HOTAS Warthog.lua' file, then the throttle would fall-back to using the default.lua that has those bindings available. Or you could edit the Throttle lua to add the APU Off command into it. If you start doing custom binds by editing the files, I definitely suggest using Quaggles mod, which allows you to put your custom binds in your saved games folder so your edits don't get reset when updates are released. https://github.com/Quaggles/dcs-input-command-injector

It's updated now, with all the previous keybinds going into the new pilot seat. I haven't put any custom binds into the new operator seat controls yet. Latest version of keybinds also has a few random fixes like getting the SPUU Adjustment Knob bindings fixed up (with different speed options).

Ordered May 14, paypal charged July 5. Latest email I got was the one 2 weeks ago saying it'd be shipping the end of the week after that.

edit (not delete) the default.lua in DCS\Mods\aircraft\Mi-24P\Input\Mi_24P_pilot\joystick you can copy the bindings for the selector over from the keyboard default.lua, search for "Select Weapon Pilot". for custom binds it is good to use Quaggles mod so they are defined in your Saved Games folder and don't get lost during updates: https://github.com/Quaggles/dcs-input-command-injector also, for other binds, the keybinds project has pretty good coverage for the Hind: https://github.com/Munkwolf/dcs-community-keybinds it's structured for use with Quaggles mod, here's the Hind binds in it: https://github.com/Munkwolf/dcs-community-keybinds/blob/main/InputCommands/Mi-24P/Input/Mi_24P_pilot/joystick/default.lua

I definitely agree that it happens frequently and it's not dcs-specific. People expressing opinions. I don't understand how that is "entitled". At least in my job.. customers, internal stakeholders, team members, my bosses, etc, all voice the same kind of business model opinions to me every day. I don't understand why it bothers you.

I think most, or at least the most vocal, are fervently opposed to such a thing. I'm for it. Seems like it'd incentivize more core development and perhaps more attention paid to older and/or less popular modules vs solely relying on sales of new modules. Also seems more sustainable and stable long-term. What's better (for ED *and* the users), all revenue being dictated by the popularity of specific modules coming out every year? Or at least some percentage of that revenue being a more stable and recurring stream from people wanting to invest in the overall vision.. the World part of DCS World? Don't get me wrong, I'm really excited about the Apache, Corsair, Mossie... really all the upcoming modules. What module would jump to the top of my list though, even if they were $100 or more? "DCS: AI Upgrade". My (completely speculative) read on it is core stuff like AI, etc, drop down the priority list because they aren't direct revenue generators. Putting more resources towards new modules will generate more direct revenue. Resources are eventually directed to those core things like AI when they get to a near-emergency point where something has to be done else it affects sales of those new modules that directly make money... which feels like where we're at to some degree. It's the way that's incentivized by the money. Imo: $10 monthly subscription (for access to the shared services, not required to play purchased modules), end the frequent 50% sales, and halve the prices of modules (to account for the subscription, and the fact that customer base is already trained to pay 50% already by the frequency of the sales). A racing simulator I've invested a lot of time and money into takes the subscription + selling cars and tracks approach, and has done quite well with it imo.

I've read in other threads that at least the Israeli Air Force runs harms and guided bombs off 4 & 6? There are valid points on each side of this debate - no need for the snarkiness. Restrict the module as a whole to the USAF ANG version being specifically modelled? Or provide flexibility so that it could be used (still in a realistic manner) as other countries have employed the Viper? Similar to the recent AGM-65 restrictions for the Harrier (that were rolled back). In both cases, on one hand, yes, these restrictions are realistic for the specific variant being modelled for the specific timeframe it's being represented in. On the other hand, it provides more flexibility, and is still realistic, if that view is broadened a bit to include how the airframe in question was employed by other operators in other times. Then put the restrictions in by what country the airframe is being flown under, or at the content level with the campaigns/missions/mp servers.

im not aware of an official story-driven training campaign for it, but the single missions available for it are good and cover a number of scenarios. i use those a lot. the DCAT one is great air-to-air practice. then the individual weapon-focused ones for air-to-ground. ideally, imo, all modules would have those qualification missions like the hornet, the qualification campaigns of the a-10, and the training structure of the harrier (full missions + specific sections + night / weather versions, very well done).

Imo, that's kind of the root issue here. Afaik, the change was made because the specific USAF version of the block we have didn't use them. Imo, that should be a mission or server restriction, not a module restriction.

Update.. added more buttons.. VKB MCGU and F16SGRH... Virpil collective will hopefully get here in a week or two.. also strapping stuff to my legs. Front x-keys pictured in "Ka-50/Sabre/MiG mode", with the top left 24-key rotated for, using Ka-50 as example, the datalink panel. Able to map a good number of modules fully without using the layer modifiers on the side 80s, so every control is one button away, and pretty close to where the controls are in VR. It's rad.

Throwing a different option out... have you looked at X-keys? the 80-key has worked really well for me with every module I've thrown at it. old pic of my rig, with the 80 in landscape between MFDs

with VR being where it is, and only getting better.. the quality and variety of periphereals available (plus the DIY options, 3d printing, etc).. and of course titles like DCS... we're entering a new golden age of sims like we haven't seen since the 90s

Same. I don't remember it happening, but jumping into the P-51 for the first time in a while it's happening. I feel like I've tried almost everything too. Seems like a bug. My experience.. Comms menu pops up and then out at around 5s intervals, like experienced by others. I haven't checked every plane, but the Hornet is fine and doesn't have the issue, where the P-51, P-47, Spitfire, and F-86 do. This is what leads me to think there might be a bug here, because it's airframe dependent. I've tried all the recommended advice. When it happened to me months back, deleting the export.lua in Saved Games fixed it. Doing so now yields no difference. I've been doing most of my testing with P-51. It's only happening with cold starts. Once I turn the battery on and switch the radio from Off to channel A it stops happening. The VoiceAttack log window shows the initialization block when it happens. Every 10 seconds or so. It's like the initialization is thinking it's borked in some planes and triggering a re-init that isn't necessary. In VAICOMPRO.export.lua, if I delete the LoSetCommand and performClickableAction for the planes I'm having the issue with in the flush function, then it doesn't happen. Likewise, just removing the whole call to flush when purge is true fixes it (obviously). I haven't played much since making that change (and Vaicom often resets that LUA, so the change has to be repeatedly made), but so far it seems to work without any ill effects.

Got an email from Virpil this morning mentioning my TCS Plus should be shipping out next week... excited to join the collective club

^ This. Reminds me of the PD 0.5 + SteamVR SS 200% thing all over again. I immediately noticed more shimmering and blurrier textures with the stock settings. Bumping the resolution multiplier up to 1.5 and 2 I could tell it looked better, but also less performant - probably not too much different than if I cranked my SteamVR SS back up. I do like how the sharpening looks though. Similar to the reshade approach and lumasharpen filter. Gonna keep going with this route for now, running res multi at 1.1 and sharpening tuning at 1.0.

Apologies for the late reply, just seeing this. It's formatted for use with Quaggles mod: https://github.com/Quaggles/dcs-input-command-injector Using that mod, you can put custom binds like these in your saved games folder so they don't get reset when updates are applied. There's a blank folder structure included with Quaggles mod, that's the same as the _Skeleton version in the keybinds project. Or you can download the whole package: https://github.com/Munkwolf/dcs-community-keybinds

Yup. Whatever will cause the device to pull a new GUID. If there are several devices with the same name, same buttons, and new/different GUID's, not really a reliable way to match things up. Not anything ED can really do about it afaik. It's more of an issue with Windows device handling and/or device manufacturers who lock in devices with the same device name.