Sgt_Baker

1) Have you tried all of the above with antivirus disabled? 2) Additionally, which AV are you running? 3) Does it make a difference if you navigate to DCS's bin folder and attempt to launch the DCS.exe directly (This error could be coming from the autoupdater not being able to launch DCS.exe)? 4) Is the account your running under definitely a member of the Administrators group, and does explicitly launching uMFCD with "Run as administrator" make any difference? 5) Finally, if you have 1.2.6 still knocking around, does uMFCD v1 still work there? --Baker

Have just published v2.0.0.6 to address the urgent bugfix mentioned a few posts above. Please visit https://ultramfcd.com/ for download.

So let me get my head around this. As it stands, with uMFCD already running, DCS refuses to launch point blank?

This is directed at a number of you: Are you all starting uMFCD before launching DCS? I urgently need to code in a system** that prevents uMFCD from executing fully if DCS is already running. This wasn't an issue with 1.2.6, since uMFCD ignored the GUI and caught DCS every time a flight was launched. **Done. This oversight on my part might explain a whole load of the issues we've been having. On the other hand, it might not, but will certainly eliminate a whole tonne of random bug reports as of next release.

Are you still running version 1?

OK. Upon examining what might cause this error, there appear to be significant indications that something is blocking a large proportion of uMFCD's functionality prior to mission launch. In order for the system to function at all, it needs to look at a bunch of files (monitor setup, options etc). In turn, based upon what it finds therein, it configures itself accordingly. The "null exception" along with the absence of anything useful in the diag pack (it simply repeats what you have in plain text) is a clear indication that this hasn't happened. That said, this is a slight conundrum since this exception cannot happen unless the whole system has suddenly sprung to life - albeit far too late. Given that somebody else reported silent problems with uMFCD and their AV software, would both of you mind attempting a run with antivirus disabled, simply so we can eliminate that as a cause prior to proceeding with something more detailed (see spoiler below). --Baker

Hard to say without seeing a diagnostics log. I'll be releasing a new version over the next couple of days, which will contain a number of bug fixes and updates to the diagnostics system tailored to look at the types of errors we're presently receiving. Until such time you could send me a diagnostics pack from the current version (click "Generate diagnostics pack" in the UI, launch a mission (or crash) then post whatever is output to the UI once DCS has closed). Additionally, could you paste the error as it appears in the Windows Event Log too, please? Edit: DURR! See that they're already attached to the original post. Sorry! Edit 2: OK. I think I know what's going on there. Let me have a quick look at the code.

I've actually studied this rather extensively, as you might imagine. One of the key variables - and often the most overlooked - in a sim is the angular resolution of what you're looking at compared to real life. In this instance we're talking about in-cockpit displays, but the same applied to everything rendered outside the aircraft. F.ex. I calculated that observing the A-10C TGP expanded to "full screen height" on my 24" HD displays is approximately equivalent to what you'd see in the actual cockpit in terms of real-world resolution, give or take. Furthermore, I think the TGP is presently modelled on an approximation of the Litening II/Litening G4, so no matter how large you make the export, it still renders world-imagery at a maximum of 1024x1024. Having worked rather extensively with IR cameras in the past, it's true that the IR views are somewhat different (thinking mostly of 1.2.6 here) to what one would expect in real life, as they appear to be based on an image processing technique as opposed to modelling actual thermal emissions. Edit: The reason a certain fruit-related manufacturer refers to some of its displays as "retina" is that the perceived resolution of those displays actually approaches the visual acuity of the MkI Eyeball, which is what I'm waffling on about here.

Finding the target is all the fun. Actually doing something to it is rather elementary once you've got that far! :)

Yeah, that's a right pain in the arse. Can you imagine how many times I've launched/quit DCS while developng uMFCD over the past ~18 months? Sometimes, when I'm not paying attention, I launch DCS as a reflex instead of whatever I was supposed to be doing.

Those are shaders, so deal specifically with visible graphics. The laser, I think, is what you observe through NVGs when ground forces are painting a target for you. I've not played with it, so could be wrong.

It does indeed. Your having modified those files will not break uMFCD, mind. Will have to think about about the 32"er. :)

That's a clear indication that the "FPS preservation" system is kicking in. Ironically, the colour CCD stuff is achieved by removing certain render calls, thus removing strain on the GPU.

T+24h Update So there are bugs. Lots of them! :D Fortunately, during the development of uMFCD 1.0, we had the foresight to develop and incorporate an automatic diagnostics system ("Gather diagnostics package" in the UI), which collects a tonne of data, logs etc. that would otherwise have to be manually gathered and posted by the user. Said system, while very effective, isn't much use unless we know what sort of problems we're looking for. Thus, the information you're providing at the moment will be used to modify the diagnostics system so that it's looking in/at the appropriate areas. uMFCD 2.0.0.6 will contain those updates, and will allow us to gather useful information 100x faster/more easily than explicitly asking each individual user to describe their problem. Watch this space. --Baker

Roger that.

Thanks for testing, Virus. The issues you're experiencing appear related to two separate suspected bugs. As mentioned previously, I'm going to take a few days to "gather datapoins" regarding the debugging (and sleep). At that time I'll be in touch with both a new build and requests that you might generate a diagnostics package with said new build. :)

Haha! This is the type of thing that irritates the hell out of me. Thanks for the good catch. Yeah, unlike uMFCD 1, version 2 will aggressively cut its framerate in order to preserve smooth flight in DCS. GPUs are composed, broadly speaking, of a number of different types of processing capability strung together in weird and interesting ways. On my system, with all DCS settings maxed out, my AMD 7970's control panel reads ~90% utilisation, yet uMFCD is detecting that the texture units are being slammed, so eases up accordingly. Said system is still far from perfect, and in fact lots of work has gone in to making it less aggressive, which is surprisingly difficult as it so happens - finding a good balance etc. Contrary to the early days of uMFCD 1 (~25% CPU use, severe strain on the graphics pipeline), uMFCD is now so efficient that it's a struggle to persuade Windows and/or the GPU that it's doing any real work at all. That said, I'd prefer uMFCD drop frames than being blamed for flying in to a skyscraper on account of a horrendous FPS drop in-game. Out of interest, the colour view renders normally, right? Edit: Additionally, the exports are rendered at much higher resolution with uMFCD than they are in the cockpit, which accounts for a large amount of the processing overhead. Although not yet available in the UI, there is already a system whereby one can choose to render the exports at a resolution closest to one's requirements - anything from (in the case of A-10C MFCDs) 512x512 up to 8K resolution on both axes. See Iku64's post for an example of that system breaking itself completely. Oh the joys of ealy betas. :D

Very useful info. We had this once before with uMFCD 1 - it simply went away when I recompiled, since various blobs of data within the EXE and DLLs are encrypted with random keys, and sometimes those sequences of bits and bytes look, presumably and coincidentally, a bit like some known virus or the other.

OK. Ironically, somewhat better than a spectacular crash. :) I'll get back to you over the next couple of days, at which point I'll request a diagnostics package.

Roger that. I'm going to take a day or two to gather my thoughts (a bit knackered - an insane amount of work went in to this over the holiday period) and then start asking for Diagnostics Packs.

That's a bit strange. It shouldn't be possible to start more than one instance of uMFCD, so something must be going wrong very early on in the process. Given that rather little has changed with regards to that code between uMFCD 1 and uMFCD 2, I suspect this is again something to do with .NET 4.6.1. Leave it with me and I'll analyse the possibilities.

Roger that. This is exactly the same problem as that identified by Iku64 earlier in this thread, and is already chalked up as a high-priority fix.

Roger that. There's little I can do about the issue this evening. Do you mind if I PM you over the next few days to investigate further?

So you're in-flight and getting displays?

Just a couple more things: 1) Launching from a shortcut created on the desktop results in an error, but launching the EXE directly does not? 2) You're running this against DCS 1.5, not DCS 2.0 or 1.2? FYI: If uMFCD doesn't switch to "DCS Detected" the moment you launch the sim (I.e. main menu, not flight), then it'll most certainly not work at all, so you can save a little effort there.