jubuttib

Wasn't quite as thorough as I should have been properly: What I was saying is that you put work above life in your list (and below family), so I was wondering if in a hypothetical case where your work was ruining your life, would you prioritize work over life? Since work > life in your list. I wasn't implying that work is actively ruining your life or anything, just that if it were, would it still be priotitized.

Wait, so if work is ruining your life, you'll prioritize work? I guess this is kinda neither here nor there in this thread tho...

FWIW, when using and external flight model, what DCS is built to simulate kinda stops mattering (based on what ASC head said, and other discussions about EFMs).

OK, second question: Why the biggest 500 kg one instead of the 250 kg one? Regardless, fun stuff, thanks! EDIT: And there is the GBU-39B/B, which has the option for terminal laser guidance...

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.

None of the following is to say that "it's good", it's really really bad vs. the Hornet ones, but I am still able to use them: I have been using MT, but I guess I had this vague memory of the range for the transmission being something like 100 km, or 54 nauts, so I guess I hadn't been trying my luck quite as far as you guys. Below 50 nauts the terrain is rendered just fine, but trees aren't, which is definitely a problem. However testing just now I could get target and building (normal residential ones on the map, not hand placed, but low poly LODs) rendering at distances in excess of 80 nauts, though terrain was just a greyscale mush. I feel fairly certain there was terrain there though, but I need to test this in a much more hilly area to make sure. It's also wild how different the view is in narrow and wide FOV, you can see so much more so much better in narrow, and bumping gain by 4-6 clicks made it even better. Cut-off at ~50 nauts is pretty obvious, but targets are rendered beyond the texture rendering limit: Low LOD buildings and ostensible terrain + water (the white part in the distance) being rendered at over 80 nauts away:

I wouldn't say "unusable", I have used it to good effect, but certainly very tough to use.

Interesting, I was recently playing Pretense and, being the aspiring young man that I am, loaded up with 10 000 kg of supplies (some 22 000 pounds...) on roughly one third fuel, and set about crossing the Caucasus mountains in 10°C FAT conditions. This did not go very well. I got pretty much stuck at around 9000-9500 feet, after cranking the FADEC RPM to max to try and get some extra out of the Hook, but yeah, RPM was dropping as did the torque, and I couldn't really find a balance between moving fast enough to avoid OGE hover conditions, and maintaining altitude, let alone gaining it. But again, this was with nearly maxed out load, took something like 75-80% torque just to get into IGE hover in the first place, I would expect a more lightly loaded Hook to easily handle that situation. Thankfully I did manage to find a path through the valleys to get where I was going in the end...

Does DCS even support actual contrast locking if you (or another 3rd party) wants to implement it? Most of these kinds of weapons lock on targets, not contrast, to the extent that they won't lock on destroyed targets that show up with MUCH higher contrasts.

FWIW I don't ever recall having it pointing at the target in the Jeff, only with the Hornet MITL missiles. But it might have been longer ago than I've been playing...

Also with the Jeff, the GPS guided weapons are less accurate when used by the Red side, Blues are pretty pinpoint.