jubuttib

That's an odd change, why not the LS-6-100, which is more of an SDB equivalent?

I mean, technically you can, it's your SDK, you could make it opensource if you wanted to (unless part of it is using licensed closed source stuff I guess, or something similar). But of course you don't want to, which is entirely understandable.

The Mi-8 is great, but it's smål. Tiny. Need big ups! Mi-26 is mandatory. Ka-27/29 is indeed just a perversion of mine, I like coax-contrarotating helis. In a month! I get Christmas, but do people take such a big false start for Easter?

Some of the European ones would be fun, though I have this perverse desire to get the Ka-27 (or 29)... Or of course the Mi-26, because we need big lift.

In theory I love this, but I'm not sure I've seen a single time a dev (1st or 3rd party) that has said "year 20XX" and it's actually been that year for release... I really hope you didn't just jinx it. Regardless, I am really looking forward to the Bo-105!

Cheers!

Oh yeah I do intend to back up! I am a datahoarder anyway, but I'm also a game developer, and have learned that sometimes the nuclear option is the best option. I'm almost 100% certain it's not the controllers, because as I said all the inputs (push buttons, encoders, etc.) work perfectly fine in MSFS, Windows test screen, VKB test software, etc. It's only DCS that has issues, and even there they work in the controls screen just fine. I do have the quaggles controls injection mod installed (I consider it mandatory for most modules honestly), so might be that over time something with how that has been updated and how it interacts with the game has gone awry.

FWIW the issues with these buttons and encoders persist in other planes too, it's not just the Viggen. Hence why I'm considering nuking everything.

Hmm, OK something weird is going on on my end, and it isn't to do with the Viggen. For whatever reason certain buttons work perfectly well in Windows (buttons get triggered when checking functionality under USB game controllers), they work perfectly in the controls binding screen (easy to bind, get highlighted when pressed/engaged), but they don't work in-game. Like for example on my DIY UFC (using a BBI-64 from Bodnar), the push-in on the right encoder (which is where L MÅL is) doesn't work, but if I map the same function to another button, even the push-in on the left encoder, it works just fine. Also neither the left or right encoder's turning does anything when mapped to for example brightness and contrast knobs. And it's not just the UFC, my STECS also exhibits this weirdness. I can easily bind the STEM module's EN1 encoder's push in function to anything, but it never works, but the EN2 push in works. The left and right rotate bindings also don't seem to be working in-game, but again test fine in VKB's software and bind just fine in the controls menu... Meanwhile the encoders on the grips work perfectly fine when bound to anything. I'll mark this as solved and edit the title, but yeesh this is now even more mysterious... Might need to wipe my saved games folder from anything to do with controls and try that way... EDIT: And just to sanity check, all of the inputs work perfectly fine in MSFS, so it's an issue in DCS specifically, probably over time my controller settings have gone to garbage... Anyone know what are the files I need to delete to really clear the deck?

I have the L MÅL button bound in the control settings, and it works there (I press button, the indicator jumps to the correct place), but when I press it in the cockpit nothing happens, don't even hear the button press sound. The button works fine if I click on it, so at least there's that.

Oh, I thought those are already in, at least CTLD allows you to pack in a mortar squad. Haven't actually used them at all yet so no idea whether they do anything.

Bah, James May eats Spam all the time, and he's doing just fine!

What I want/need is the ability to have all of the exports as new windows, so that I don't have to deal with the godawful garbage system they currently have... Yes, I have 3 monitors. No, they're not all the same size, and I don't want to use all of them for the game. Yes, the center one is biggest, and I want that to be the game display. No, this does not mean that I want my left monitor to also be black to get the viewports exported. I built MFDs with displays and set them up really nicely, but I haven't used them for over a year because it's just unforgivable that I have to have one of my displays completely black to get the viewports enabled. EDIT: Sorry, this is not OH-6A related, I apologize. Really looking forward to the AH-6J, or the MH-6J, or whatever else you guys are cooking.

Semi-related, I guess: Could anyone point me towards where I would go to adjust the weaponry on the OH-6A? I would like to add some (possibly colored) smoke rockets to the Cayuse for spotting purposes. The colored grenades are good in and of themselves, but due to the unique way the BBC is funded... I mean DCS works, it's pretty hard to get close enough to an infantry unit to drop a smoke on them without being shot to bits.

I have worked in the game industry in a few companies, making some very complex games, mostly simulators, and talked shop with many colleagues, and operating like this, even on an early access product, would just not fly in any of them. If a new update broke an existing feature in a major way, significantly affecting the usability of a given vehicle or somesuch, AND it was caught by our testers, that part of the update would not be allowed to go out, even if other updates did, until the issues were solved. A couple of those kinds of slip ups and you'd seriously risk getting fired. This is specifically new stuff breaking old stuff AND being caught before release. If no-one caught it before release, fine, mistakes happen, and quite often those issues aren't 100% pervasive through the userbase. If you introduce a new feature that's partially broken, and issues with it were caught, also not that bad, it's a new thing that's under development. But pushing updates that knowingly (i.e. QA caught them, and they're known about before pushing the update) break old systems and majorly impact the functioning of those systems, that is just immensely poor form. It's always preferable to roll back and withhold those updates until they are actually working. Mistakes happen, absolutely, and I'm very sympathetic to development woes. Making games is damn hard, but it sounds like you're making things even harder and more stressful for yourselves operating like this.