jubuttib

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.

Saw this on the Github, but no download yet, anyone know what's up? null

Cheers! I guess where I got confused was that I'd only ever seen the Antenna Stick _axis_ bindings before, wasn't even aware that the buttons were there before I went looking yesterday.

Wanted to ask about this before I go and make a full bug post, in case I'm missing something: I'm trying to get to grips with dropping GBU-24s onto command centers when flying solo. My problem currently is that when I tell Jester to start tracking a spot on the ground with the context button, he initially establishes a good track, on the left I get a solid bottom bar and a solid top bar (or sometimes flashing top bar if I do it too far), but after either pulling up from the dive (12-vis designation) or trying to move the cursor myself with the extra bindings (Pilot's temporary [WSO] hand control bindings) they both start flashing, indicating that he has stopped lasing. Pressing the context button again in this situation boresights the pod, so I have to turn around and start all over again. So far the only way I have managed to get a solid track with lasing is by hopping to the backseat myself, and doing the trigger full action to command tracking and lasing. So the process ends up being like this: 1. Fly plane towards the target, with everything set for a TGP drop. 2. Dive towards the target, hit Jester Context Action to initiate tracking. 3. Pull out of dive, settle into level flight on autopilot. 4. By now the bars are both flashing, so I hop to the backseat and command trigger full action, and maybe finesse the aim a bit. 5. Hop back into the front seat, hold pickle and follow guidance until drop. 6. After drop trim the plane for level flight on autopilot again. 7. Hop back to the backseat and make sure the laser is firing, finesse the aim (if I finesse the aim from the front, it tends to stop lasing). Clearly this isn't how it's supposed to work, any ideas what I could do to solve this? EDIT: Or is the incapability to keep lasing expected, and I just need to map more of the [WSO] commands? EDIT2: Quickly tested mapping the [WSO] challenge and trigger commands too, and this seems to be the way to go, not using Jester context at all.