Sgt_Baker

Hey Wilbur, Are you certain your Windows install is fully up to date with latest patches etc via Windows Update? --Baker

The good news is that I've just been able to reproduce the cause of the "Monitorsetup" error and "SharpDX.Desktop.dll" errors. It transpires you need a different machine than mine in order for it to actually cause a crash. :D Working on a fix as we speak... EDIT: Frikkin. Solved. Will release patch (and F-15C TEWS) ASAP. Explanation for the technically inclined: Multithreading shenanigans were biting us in the arse. --Baker

Possibly releasing the F-15C TEWS update in to beta tomorrow. --Baker

Yep, see how that makes no sense whatsoever? Given certain other bug reports, I suspect Windoze/AV may be blocking certain actions at the OS level, whether AV is enabled or otherwise. Notice how you have to agree to the whole "Untrusted download" thing? First action on this end: Sign the EXE with an expensive yet invaluable Code Signing Certificate and perhaps 50% of these problems with mysteriously vanish overnight. --Baker

Hey Sobe, The D:\ stuff isn't the issue. I run DCS from E: without issue. What is strange is that error you posted previously. It's complaining that it can't find two particular elements (Monitorsetup and SharpDX.Desktop.dll) which are definitely included in the download zip. You can check this for yourself by looking in the folder where you extracted uMFCD for SharpDX.Desktop.dll. Is it there? If so there's no easy explanation for why uMFCD is throwing a hard error about not being able to find it. The monitorsetup thing is unrelated to your actual monitor setup. That's unfortunate internal uMFCD jargon. I should probably rename it to something else to avoid confusion with your actual monitor setup. I'm still investigating this issue. One thing I suspect is that uMFCD may be subject to false-positive anitvirus activity, so I need to get a code signing certificate asap. You'll know more when I know more. --Baker

No awards for spotting a bit of uMFCD "added value" :) ...

(in my broken Scandiwegian) Og hvem betaler for det, nettop? Onkel Skrue? :)

Well... seeing as everybody and their dog are requesting a TEWS export (and everybody seems to create one too), it's only fair that I get in on the act.

Great work! :) Worth pointing out how to set up an additional mod key such that fully-saturated joystick/throttle setups such as the Warthog HOTAS can easily utilise this.

I dunno. Something about bears in The Vatican, along with details of their sanitary systems? :)

Haven't forgotten about you regarding the sensible testing setup. Does appear that you're pulling your hair out right now. Might be wise to take a few steps back? For your own sanity? :) --Baker Edit: What I mean is that nobody should spend $4000 making a $400 component work.

Hi all, Worth noting that 26 months after the fact, and my completely forgetting all about this, somebody did PM me and the files are merged (including recent radio fixes courtesy of Capt. Zeen and certain other optimisations). Results available here: https://forums.eagle.ru/showthread.php?p=3115904#post3115904 Thanks to WARonWAR for his epic Googling effort, finding this post and dropping the PM! --Baker

You would still be able to resize the displays dynamically (think making the TGP really large for finding that gnarly hiding target) using the joystick bindings - which I will also upgrade in parallel.

Will do tomorrow. It's something of a long-winded write up with screenshots, idiot-proofing etc, but worth following the rather easy method to remove the human factor as much as possible. It's interesting to note that I've re-plugged** my entire system and clean-installed the Windows Creators update since my last attempt at using TrackIR with DCS. Thus, the TrackIR camera might not be plugged in to the same USB port/internal hub/controller as it was previously. I'm also now using the default Windows drivers for chipset, USB etc, whereas previously I was using those provided by AMD. --Baker **So it turns out that my VERY EXPENSIVE case from Corsair wasn't grounded properly. I record music quite a bit, so RFI/EMI is something of a concern. What they had done was paint all the case parts before assembling them, which left pretty much everything not directly in contact with the power supply completely ungrounded. Spent a day manually scraping off paint and creating a mixture of hard-soldered and removable earth wires to provide low-impedance paths to ground for every external panel and mounting... and BANG: 20dB reduction in interference from the box. That means it's spitting out 1/10th the amount of noise in real terms. :)

A quick update: In a monumental shift from the status quo regarding UltraMFCD, I am seriously considering enabling full-screen support in the immediate future. Some uMFCD features, such as clicking displays, might be unavailable, but indications on my end are that MS and/or ED are finally hammering the nails in to the coffin of true fullscreen mode (Which hasn't /really/ existed since Win7 due to the DWM). A lot of thinking and testing will be required, but hopefully we can finally remove that particular caveat for uMFCD users on certain OS versions. --Baker

I've just run a series of tests using a Special Scientific Method™, including the legitimate use of a brown envelope, and unfortunately the problem appears to have gone away since I last tried TrackIR with DCS. There's a standard 1-frame input lag between TracKIR and DCS due to the way DirectX queues up frames before displaying them, but other than DCS's craptactular texture/geometry loading causing stuttering (which I eliminated as a variable by panning around completely to preload all visible textures etc) everything else was fine. Hurmph. It honestly was borked! If you're interested I can detail the testing procedure. At least it removes the human subjectivity variable. --Baker

It has just occurred to me that in addition to a "stuttering" issue there may also be one where latency is concerned. If memory servers - and I'm rather inclined to run some tests - I do recall noticing a degree of "rubber banding". Will get back to you. Edit: Scrap that. Nothing that can't be cured with the Smoothing setting.

+1 Verification as per your description of the issue. Don't use TrackIR with DCS for precisely this reason. It performs poorly enough to be more of an irritation than anything else. Always thought it was merely my setup not coping, and thought little more of it.

Does this work? --Baker HeliosRadioFix_CDUipad_Export_Merged_Sgt_Baker_MkI.lua

Now this is something I can test in short order. I tend not to use TrackIR with DCS, as the low FPS I get with my aged 7970 tends become an irritation when glancing around. However, and for once, all of the hardware is in place to test directly. :)

Hi folks, Will check the latest bunch of Diag Packages soon. Been off working on other things, amongst which are obtaining a more practical setup for working on uMFCD-related affairs. --Baker

And you're still getting the "Run as Administrator" thing when launching uMFCD and saying "Yes"?

Conversely, this indicates a major problem with the base technology that uMFCD uses to negate needing to mod DCS. You're not the first person to have mentioned this. Out of interest, have you checked the logs of your anti-virus software so see whether it is intercepting and blocking uMFCD? --Baker

Has this only just started?