Sgt_Baker

Hi Sobe, Yes, a complex export.lua could very well be the culprit in this case. What are the specific symptoms of the problem you're experiencing? The way ultraMFCD interacts with the export file is something that is slated for testing/fixing in Beta 2. No point having it working nicely with novel export files if the core system doesn't work properly! In any case, I'll dig through this thread to retrieve your export.lua for future reference. B

Would the two of you kindly test for exactly these problems with Update 6, please? I have included an additional patch for Iku64's problem, but was unable to reproduce the issue with external views. Cheers, Baker

Update 6 is available at https://ultramfcd.com/Public-Beta-1 This release provides further fixes to problems encountered with Water Quality settings, in addition to enhancing the system for dealing with unusual resolutions.

Crap, that's the flipside to the Water Quality bug. Will fix asap. B

The ultraMFCD display will always immediately override those in the cockpit, so simply use the exported display during pre-flight.

It'll take some digging around, but I'm not entirely certain that DCS is capable of communicating which page is selected. Despite this, moving the rotary switches in uMFCD will always select the desired page since they operate in an absolute fashion as opposed to a relative forward/backward. Edit: In any case, it isn't what I'd call a high priority matter. :)

Update 5 is available at https://ultraMFCD.com/Public-Beta-1 This update fixes two major bugs: 1) Strange things happening when water quality not set to Max 2) Complete breakdown of the system when running DCS in some of the more unusual resolutions, such as 1366x720 Things to look out for: The fix for the unusual resolution bug caused another minor bug to appear while we were testing internally. For reasons known only to the inner workings of the graphics drivers, sometimes part of one MFCD would "leak" by a few pixels in to another display. While we've already patched this one, there's presently no way for us to tell whether this problem was limited to our graphics rigs, or might have been evident for all users. If you experience anything that appears to be the above, please let us know. Baker

OK. I'll get back to this specific problem once I'm back at the office in the new year. Weird that the 4th monitor should die altogether. Might be the unusual resolution thing, so will release the next update prior to tackling this specifically.

More technobabble alert: Ctrl-Alt-Delete, along with various other things like Windows's UAC prompt or another application going full screen, causes what DirectX calls a "lost device". Essentially, you lose access to the graphics card and have to rebuild your entire graphics pipeline from scratch once you've regained access. Crtl-Alt-Delete is simply the easiest way to simulate a lost device reliably. All DirectX apps should handle a lost device without crashing, obviously. :)

Could you be more specific, please? After all, on my rig DCS crashes entirely when I Ctrl-Alt-Delete with the 1.2.14 build - running no mods or uMFCD. :) Baker

The bug referenced in the previous post is now fixed in our internal builds and will be available in the next release. Now you can fly in weird resolutions with impunity. :)

Yep, it's the "unusual resolution" bug. The fix for this one will also be in the next release. Technobabble: DirectX, for reasons relating to the number two, goes a bit loopy internally with regards to how memory is allocated for certain resolutions. I'd already provided one fix for this, but recent evidence pointed to the problem not being fully resolved. This is #1 priority. B

The next release (which is already somewhat overdue) might fix this. Out of interest, what screen resolution are you running at?

FYI: Over the next week or so I'll be programming off the equivalent of a grass strip in the mountains with little in the way of logistical support. I can sometimes get a signal to the outside world, but it appears to depend on seemingly unconnected factors such as the phase of Jupiter and what the Prime Minister had for breakfast. Deeply frustrating, in other words. That explains the slowness in my responses at present. :)

It does that by design. F10 is the only view where DCS doesn't render the MFCDs. In all the other views the system is furiously rendering the MFCDs, even if you're not aware of it. It is technically possible - plucking out of the sky, here - to prevent this from happening, but then again you could always use the Max/Med/Min view system to good effect: I.e. set the min view of each display to somewhere small and unobtrusive. B

Yep, that's the "water quality" bug - which has already been patched and will be available in the next release.

Silly question.

There are indeed. We were playing with prototypes of exactly that as early as June this year. Additionally, the developer of iControl (MFCDs on phones/tablets) have already arrived at an understanding where our respective products will compliment each other: I.e. UltraMFCD will feed iControl's network stuff directly, thus removing the current obligation to have MFCD exports displayed within DCS in addition to the export to phone/tablet.

Yep. Have just added a "clear" to the MFCD rendering code which will ensure the displays switch off when they're supposed to. (There's a rule in DirectX which goes something like "clear as infrequently as possible". Perhaps "never" was a little too infrequent. :) ) Still looking in to the kneeboard thing. Essentially they render at the same time/place, which means I'll need some more clever detection code to separate the two. Interestingly, in a default setup, the kneeboard stops working altogether. Will definitely fix this one.

The video in the first post of this thread covers the basics: To move an MFCD, simply drag anywhere that isn't an OSB. To resize, a handle should appear in the bottom right of any given display when your mouse is over said display, which works just like dragging the bottom corner of any window.

I'll have to download and test it myself to determine exactly what's going on. That's all I can say for the moment. :)

Yes. A load of the work performed immediately prior to open beta concerned the mechanisms by which we add new displays to the system. The target was to make it as simple as possible on our end. The CDU? 48-ish hours to implement. This beta test series was more about validating the core technology, but yes, there are more toys inbound. :)

Just a quick update: The water quality bug was as simple as I anticipated it to be, and is fixed in the next release. Regarding the problems with unusual sim resolutions, it's a case of "we know what's causing it, and are pondering an elegant solution". This too should be fixed in the next build.

Update 4 is live at https://ultramfcd.com/Public-Beta-1 It specifically addresses the "Beta Expired" bug that has cast a long shadow over this entire test. Fixes for the problems with unusual screen resolutions and low/medium water quality are already inbound.

Come to think of it, this is almost certainly the same bug that I "fixed" previously. I'll get this one squashed for good in the next release, which should hopefully be out at some point in the next 48 hours. B