Sgt_Baker

Nope, the creators of SweetFX and myself need to have a conversation about "airspace issues". Fortunately this has already been initiated via Icemaker, who happens to have the appropriate connections. :) Edit: I have offered the SweetFX folk some of the non-invasive tech that uMFCD uses. Edit2: It would be easy to detect and kill SweetFX in order to prevent the hard crashing we've experienced... but that's just not cricket.

Have just had a brainwave (read: "Why is this excessively complicated?") that should solve problems with esoteric monitor configs and arrangements - something that has proven troublesome since the move to DX11 - once and for all. As of the next release, it shouldn't matter at all whether you have one screen or twenty set up in weird and wonderful arrangements. uMFCD, from now on, should provide pixel-identical exports regardless of your setup. Additionally, this brings back the opportunity for low/normal/extreme options where export quality is concerned. Should you wish to render a display at 4096x4096, that would be supported as a result of the latest changes.

In the very near future, yes. It so happens that I was testing with all the FC3 aircraft the other day. All I really need to do is set up all the tedious supporting infrastructure, such as UI elements, as opposed to anything really complicated within DCS's bowels.

I'd have to look at this in detail. I want to say yes, given that I exert extensive control over the manner in which DCS operates, yet I think it would be better to arrange for uMFCD to explicitly pass the integrity check with the cooperation of server admins. I.e. Knowingly bypassing anti-cheat mechanisms, while entirely possible, is just not cricket. :)

Maaaaybe in the next release: Viva Las Vegas! :)

Yeah, I'm surprised there isn't more visual evidence of this within the game, given that DCS itself is presumably having to rebuild its rendering pipeline every time this happens - something that probably accounts for the micro stutters. That said, the fact that it's taking down the graphics drivers for completely unrelated apps is serious in and of itself.

EDIT: Have found a way of mitigating this. A quick note regarding DCS 2.0 alpha: Unfortunately it transpires that under the covers, the new terrain rendering engine in NTTR is super, duper unstable. It's so bad in fact that it hangs the graphics card drivers (on my machine) every 20s or so, despite everything appearing to run relatively normally. The consequence of this is that it's not currently practical to run any DirectX 11 application alongside DCS 2.0, let alone one that does complicated stuff with DCS. On the upside, when the gfx drivers aren't drunkenly stumbling all over the place, uMFCD works with 2.0! :) Here's the output from a super-simple diagnostics app that does nothing more than render a colourful triangle. When DCS isn't in a mission, it's fine. As soon as NTTR starts running: Device hang at 24/09/2016 11:23:26 Device hang at 24/09/2016 11:23:49 Device hang at 24/09/2016 11:24:10 Device hang at 24/09/2016 11:24:14 Device hang at 24/09/2016 11:24:56 Device hang at 24/09/2016 11:25:12 Device hang at 24/09/2016 11:25:15 Device hang at 24/09/2016 11:25:37 Device hang at 24/09/2016 11:25:52 Device hang at 24/09/2016 11:25:56 Device hang at 24/09/2016 11:26:06

Well... now we're more or less (as of next release - already done, just awaiting some beta feedback) back at the point we were with DCS 1.2.6, we can once again look at expansion as opposed to catching up. :)

I'll put it on the list. :)

Are you running SweetFX perchance, Boberro? I'm yet to get uMFCD and SweetFX to play nice together, and this looks a lot like what happens when they, well, don't. --Baker

In the next build... guess who's back!

Right! From now on, bug reports as per my sig, please. Utterly impossible to manage effectively when they're all bunged in to this one thread. :)

Roger that. This behaviour means there's still some slight finessing to be done with the detection code. The minor issues with labels sometimes getting gobbled up by uMFCD is evidently something more of a major one for you, since it ignores the actual displays altogether. I'm just in the process of (finally and boringly) setting up a forum so we can keep track of these bugs individually.

Ah, yes. OK. Fingers crossed, as this would prove a relatively easy fix compared to some of the (painful) sleuthing that's gone in to uMFCD. :) Edit: DirectX in general is notorious for its "helpful" InvalidCall error.

Yeah, that kinda makes sense with the Crossfire setup. Considering the likely location of the crash within the code, I thought it might be because I'm not being specific enough about which graphics card to set up all the rendering on... but that doesn't explain the GTX 1080... unless it does something funky like present itself as two cores... I'll try jamming another card in my dev box to see whether it reproduces the error.

There is, but not in the immediate future. What's required is to implement /all/ display functionality in DX11, including full 3D models of the displays etc. It's on the TODO list, but obviously is a rather large effort in and of itself.

That's not one I've seen before. Could you copy/paste the error description from the Windows Event Log along with generating a diagnostics package within UltraMFCD itself? Generate Diagnostics Package 1. Go to uMFCD settings via the cog icon on the main screen. 2. Enable "Gather Diagnostics Package". 3. Run DCS until the problem manifests 4. Send us the resulting diagnostics package generated in the System Messages area.

Coming very soon in uMFCD 2.2: The return of all the "missing" displays, including those for the KA-50. After a little bit of debugging, of course...

UltraMFCD 2.1.0.0 for DCS 1.5.4 is available Following the development of a completely new rendering engine, I'm pleased to announce that UltraMFCD 2.0 is ready for a public beta. Previous users of UltraMFCD will be familiar with its functionality and what to expect. If you're a new user, please consult the documentation for UltraMFCD 1.0 at https://ultramfcd.com. The purpose of this test is to verify that the new rendering engine is stable and works as expected. Please post any bugs you may encounter either here or in an email to ultramfcd@ultramfcd.com. Download link: https://ultramfcd.com/ ** UltraMFCD requires .NET 4.6.1. If you have trouble starting the program, please download and install .NET 4.6.1 from here: https://www.microsoft.com/en-us/download/details.aspx?id=49981 2.1.0.0 Caveats/things we already know: 1) Lots of displays are missing as they're still being converted to DX11. Happy flying! --Baker --------------

Potential 2.1.0.0 (for DCS 1.5.4) release in the very near future.

Thanks, Roger and Wilco.

While the current UI is coded such that you only get one instance of any given display, everything beneath the clicky-boxes level doesn't care whether you have one or one-hundred of any given display on screen. Would also help free up some space in uMFCD's small screen footprint, given that you no longer need a checkbox for every display in every aircraft - think of it as a plus/minus dialog that allows you to choose only the ones you need. I'll probably schedule this, prospectively, along with sorting out the keyboard/joystick/mouse binding effort, which is also a 95% UI-fixing effort. As always, guinea pigs are welcome... providing you don't mind the occasional electric shock. ;) --Baker

A breakthrough which so happens to additionally have fixed the issues with the "pretty" graphics settings, such as lens flares, depth of field, HDR etc.

Just made a breakthrough and fix with regards to this bug. How? Changed to testing methodology to one where I fly in to the middle of a full-on battle where EVERYTHING is shooting at EVERYTHING, which show up behaviours in DCS's rendering engine that aren't evident when you're merely flying around calmly. Durr, Baker, Durr!