Sgt_Baker

That could be done with a minor (few lines of code) modification to uMFCD, yes.

Thanks all. The first order of business is to fix two major bugs that were introduced with the move to DX11: 1) Displays frequently messed up on screen resolutions other than 1920x1080. 2) Intermittent/permanent fullscreen/unmovable displays. Some people have been reporting a crash on start, although I'm not presently getting that on this end. If this affects you, please send a diagnostics package. --Baker

Fingers crossed. Things can only get so silly...

Hello again. :)

Hello folks. Not been temp-banned again. As intimated above, real life does take precedence. It's pointless to attempt to provide you guys with long-term service unless there's a solid backing. Normal service will resume within/around a month, assuming they can plumb the proper internet wires by that point. :)

And these days, for reasons owing to the moving-3D-map research, I know MUCH MORE than is healthy regarding regarding efforts to quantify our planet in 3D. :D

Yes, that's still an active line of development, although fixing the three-ish major bugs with 2.0.0.6 is obviously a priority.

OK. The screenie you referenced there is actually quite useful. I've just noticed that uMFCD is still saying "Cofiguring..." when in fact there should be a green tick and "Running". This tells me quite a lot about where the problem is occurring.

The licence validation thing is fixed. The HTTPS certificate on the server expired. Whoops! Just renewed and reinstalled, so everything should be working again.

That's precisely why those controls were provided. :) However: If any of you (apart from .mil who are already there) get the opportunity to play with either near, middle or far infrared cameras, I suggest you snap it up. Things look very, very different in the IR field.

FWIW, we went through all of this with uMFCD 1. It's a natural part of charting out, on this end, the intricate nature of how DCS's rendering engine works... all without seeing a single line of its source code. The technique that eventually resulted in 100% reliable performance in DCS 1.x.x isn't available in DCS 1.5/2.0 in the same way, so have had to start from scratch on that front. Still attempting to figure out which is the best of a number of options - and each strategy takes time to develop, debug and test, even before it gets anywhere close to a beta release such as this. It could be, based on diagnostics info collected by the upcoming 2.0.0.7 build, that we abandon this approach and choose a different one. This concerns a very small, yet critical, aspect of the system, so these statements are not to suggest that "everything needs to be redone" in that instance. This is because "what works for most people" doesn't necessarily work for "all people", so it's very much a matter of picking up on and analysing the outlying cases, and adapting accordingly. :) --Baker Edit: The "technique" changed, in terms of that available to the public, three times over the lifetime of uMFCD 1 (and many more times internally). uMFCD 2 is presently at the point where we've not yet investigated alternate techniques, in a meaningful sense at all, just for clarity.

Interesting. This is why we have beta testers. Would never have thought of that myself. :)

You're not the only one. We'll have to go down the diagnostics package path regarding this. 2.0.0.7 will contain numerous enhancements to said system, specifically targeting a few known bugs for which there are presently no known fixes.

There is actually a fix for this in the works, which will simultaneously solve the issues people have been having with large/novel screen setups. What's happening is that uMFCD is currently rendering the MFCDs very large and then scaling them down in the front-end. This is what's causing the gfx-related stuttering - simply being forced to draw the TGP at very high res. The update will allow you to choose a "fundamental" export size that most closely matches the size you intend to use uMFCD exports at, and the front-end will scale up/down as required. That new feature should, in turn, prevent the separate yet interconnected FPS system from kicking in at all. Its intended purpose is really a last ditch effort to prevent massive degradation to the controllability of the aircraft itself. Edit: The reason we didn't see any of this with uMFCD 1 was that DCS itself was FPS-limited by god-knows-what somewhere else in the rendering engine, so never really got close to properly stressing all but the most basic graphics cards. Now that limitation is removed, the gfx subsystem is actually something I have to compete with DCS for. The issue with large/novel screen setups was merely a mistake on my end. Fortunately the one fix solves both problems. Edit 2: Come to think of it, there's nothing preventing me from dynamically adjusting DCS's internal rendering size of the camera-type views based on the exact size requested by the uMFCD export, so perhaps we'll see that as a further update at some point. (I like to use the size/position memory feature to quickly expand the TGP to full-screen when I'm looking hard for targets hiding is bushes. In fact, I have no idea whether I'm the only person to do that. That system was included very much as a birthday present to myself.) :)

Actually, if you pay careful attention, you'll notice that uMFCD automatically sets itself to "high" when a flight is started, then downgrades to "normal" once you exit flight. Something has changed, at least in Windows 10, with the way threads are dynamically scheduled, which is presently causing me certain headaches, as you can see. :)

This is currently a work in progress. Essentially what's happening is that Windows looks at uMFCD, which is superbly efficient processing-wise, and says "There's this computationally-expensive DCS thing running over here. You don't seem to be doing much. I'm downgrading you to a background process."

This too is exactly the same bug as Pipe is experiencing. To cut a long story short, display exports are now rendered at resolutions and sizes independent of DCS's screen size/res. Put quite simply, I forgot to implement 50% of the system that tricks DCS in to doing that, which particularly affects novel screen setups.

Known bug and entirely a mistake on this end. Although a bit convoluted. I can state with 100% certainty that this will be fixed in the near future. (forgot to carry the v1 screen code over to v2)

OK. That too is good information, yet obviously not "functional"-good.

Wow. Excellent piece of debugging there! You're absolutely correct to assess that fix as extremely strange - uMFCD shouldn't (and hasn't hitherto) interact in any meaningful fashion with the user accounts system other than storing its text file of settings in C:\Users\<you>\AppData\Local\fe23, which is a system that utilises near-total automation provided by MS and the .NET framework. WTF?

Well that's some semblance of progress, although I'm not entirely convinced it's solved for good. uMFCD and AV software operate on sufficiently similar principals that, when they end up at loggerheads, more or less all evidence of a war is utterly invisible. "Configuring" is, as you'd expect, much more useful in terms of debugging that "nothing at all". I'd expect useful data in the diag package. I'll try to look at it tomorrow, but do pester me if I forget. Given the fact that its already getting a little difficult to keep track of whose bug is doing what, I'll be setting up forums on ultramfcd.com so at least we can post bug reports in their own thread. Finally, thanks again to each and every person helping eliminate problems with uMFCD both with v2 and historically with v1. Without your efforts and attention to detail, this system wouldn't work at all (apart from on my PC) :D

That's how it's supposed to work. The bug you're experiencing is nothing to do with settings, and everything to do with my having made a mistake somewhere in the code. :doh: Edit: They're stored in C:\Users\<your username>\AppData\Local\fe23

I agree with you entirely. Remarkably little has changed with the code that executes that early on, so this is a bit of a conundrum at the moment. Presumably, since it's not even getting to "DCS detected", attempting to generate a diag pack renders absolutely nothing of use, too. Is there anything potentially indicative in the Windows Event Log now that we've removed the possibility of the "late launch" bugs from happening?

Understood, and thanks for testing. This is a bug which evidently affects some people but not others. If you've been following this thread, you'll have seen me going on about updating the diagnostics system. Well, this is precisely the type of thing I need to detect. Watch this space for v2.0.0.7, which will contain said code and allow you to quickly generate a diagnostics package to help us understand exactly where the rendering system is breaking. --Baker