Sgt_Baker

There's clearly a bug in our KA-50 support that we've yet to track down and isolate. You're not the only person experiencing this. The beta testing in terms of the KA-50 has been underway for less than a week, so we should expect some difficulties at this early stage. Please check back periodically (or allow uMFCD to tell you that there's a new version available) while we solve this one. B

Yep, that's pretty straightforward... and in fact is precisely what UltraMFCD is designed for: Not needing to worry about a lua file ever again. :)

Then again, Sith, there are people who are very serious in the "making mods" field. It is entirely appropriate to voice opinions regarding what one perceives to be the seriousness of any given proposition.

Apologies, but that image was a naughty little teaser. It is possible to implement the F15C's radar overnight, should there be demand for it, but the rest of the displays require a rather different approach in terms of how we get the displays to render. Following the pattern set by ED, most of our effort will go towards implementing the high-fidelity aircraft first, followed by the FC3 series. I know this must frustrate the supersonic fly-boys (I'm an A-10 pilot ;) ), but us low-level bods have gotta take the power back somehow! :)

Still in R&D-phase, yet clearly not a pipedream. :)

Yes, this has been asked a few times now. There's no technical reason why it isn't possible beyond my checking that I don't enforce the aspect ratios in code somewhere. One good suggestion was that it should be possible to alter the aspect freely while shift-dragging the resize handle. This, IMO, is a rather good idea. Will look in to this and implement at the earliest opportunity.

I took a screenie as soon as we hit that "eureka" moment. Once you know where something renders, you can change how it renders.

OK. Will keep this in mind.

Thanks for trying all that. We'll go with the diagnostics tomorrow. :(

OK. So just to keep things clear: What exactly are the symptoms at present? (They changed with the .50 build, right?)

Ah ha! SLI being a very important clue there. Will have to do a whole load of research as to how SLI affects the rendering pipeline. If it's not too much trouble, and in order to properly isolate the issue, could you attempt running with a single gfx card? If then it runs, we know precisely where to look at applying the fix.

Roger that. You're not running your gfx card in nVidia Surround or ATI Eyefinity mode, are you? In any case, this is an important and interesting test case. I will be in touch (likely tomorrow) with a diagnostic build of uMFCD. Hopefully that will shed light on what is happening. Regards, Baker

Much appreciated. As it stands we have managed to isolate all the F-15C's displays, incuding the HUD, but rather needed to concentrate on making the A-10C/KA-50 support "weapons-grade" prior to getting stuck in to other aircraft.

Ok, cool. If anything, try reading up on exactly how the HD7990 (I run an HD 7970, which is precisely half of it) behaves when not being specifically driven in Crossfire mode. It could be that each of the two GPUs in the card are running a monitor each. While I've tested this kind of setup successfully with separate gfx cards, AMD's x2 both-in-one are known to behave strangely.

:) Free plague of locusts with every install? We're already working on it. F-15C is a bit different to other aircraft, so requires a slightly different approach. A lot of the "under the covers" stuff that is in recent updates is geared towards the implementation of support for F-15C, Su-27 etc without breaking the code associated with the A-10C and KA-50. You've all been testing it without knowing! :D Another case of watch this space.

You're welcome, and thanks for testing! :)

Roger that.

In that case it really should be running properly. Thank you for taking the time to re-download DCS. Beta testers, such as yourself, who go the extra mile to try to figure out problems really do solve issues for the large proportion of users who are "silent". If running uMFCD against a virgin install doesn't work, might I contact you via PM so I can issue you with some builds which have much more verbose diagnostic output? If it does work, I believe the DCS installer will save any modified files in a backup folder, the examination of which should point us in the direction of where things might be going awry. Best regards, Baker

OK, phase II: Did you check that FRAPS is /really/ gone? As I mentioned in the previous post, one of our users has reported that it leaves something running in the background, even after you've quit it. We do intend to patch the FRAPS issue in an upcoming release, by the way. Secondly, are you using or have you used a custom monitor config (manually exported displays) in the past? If so, could you please send me (or paste here) the lua associated with that config?

Hi Watar, There are a couple of things to check off the list before we start looking at the code: 1) Are you running DCS in fullscreen? Presently, in order to use UltraMFCD, you need to be running in Windowed mode. 2) Are you running any third-party apps or mods that might interfere with uMFCD? FRAPS, for example, has a habit of breaking things, and is also known to hang around in the background (check for fraps.dat in task manager). 3) Are there any messages in UltraMFCD's System Messages section (see image below)? Regards, Baker

It's quite possible there's some connection here. What I changed in both Update 8 and 1.0.0.50 was the methods used for positioning windows and querying their width and height. It sounds like Windows (capital W) might be having some sort of struggle with your gfx driver, which could certainly explain some of these spurious results. Just to be clear, when you're outside DCS doing "normal stuff", do you use the lower monitor as an extension to your main desktop? Can you drag, say, Chrome (which is heavily hardware accelerated) to the lower monitor? Edit: We dealt with a situation recently (see post #8 onwards) where uMFCD, on account of being all-DirectX, was enough to push somebody's gfx card over the edge since they were running a huge desktop resolution across four monitors. Yours, at 2 x 1920 x 1080, isn't going to be the same problem, but having issues only appear when running multiple DirectX apps isn't unprecedented.

G00dnight and fenmonster, I've made some subtle alterations to the dragging code. Could one or both of you check build 1.0.0.50 (https://ultramfcd.com/Downloads/UltraMFCD.Beta.1.0.0.50.zip - ignore the "new version available" message) to see whether the windows remain at the proper size while dragging, please? Many thanks, Baker

As in way back at 1.0.0.8? Edit or Update 8 (see page 30 of this thread)? In that release we fixed an issue where windows weren't visible while dragging on Windows 7 systems. If you can confirm that this started to happen with that release, I'll take another look at that section of code. Regards, Baker

The configs are now automatically upgraded, keeping as much as possible from the previous version. Should just be a matter of making sure you're running all the files from .49.

That's pretty weird. Did you get rid of the old uMFCD install completely? And was this purely with the KA-50 or the A-10 too?