Sgt_Baker

Wow, yes. To quote one Jamie Hyneman: "Well there's ya problem!" I've been looking at this issue very closely all day. Mean and Median values for Export Time are in the order of 5x what they should be under Full FPS. Given there is such a huge difference between the Export times and the MemCopy times, I'm beginning to suspect that your gfx card isn't communicating with the rest of your machine properly. Would you mind terribly taking a look inside your machine to verify that your Radeon 290 is indeed connected to the bright yellow PCIe socket and none of the brown/black ones? The reason I say this is that the difference between Export and MemCopy is almost exactly that which you would experience if the above were the case: The large black PCI socket on your motherboard is about 4 times slower than the yellow one. Other that that, your system is evidently quite nippy indeed. Edit: See the "Expansion slots" section of http://www.asus.com/uk/Motherboards/Z87K/specifications/

OK. First update to Beta1: https://ultramfcd.com/Public-Beta-1 Possible fix for "floating mouse" issue Added profiling to export mechanism to investigate FPS issues Added explicit message regarding DCS in fullscreen mode Slow FPS: If your FPS is waaaaay off what would be expected, please copy/paste the output, which is generated once every 1,000 frames, from UltraMFCD's System Messages section to this thread along with a brief description of your system specs. The following screenshot is taken from my system. The mean and median times have rocketed from ~3ms to ~9ms in response to recent modifications to various aspects of the rendering engine. This is clearly undesirable, so I would appreciate your posting times here in order to provide a baseline against which to measure improvements in this area. B

Actually there is something we could clarify in this instance: What exactly do you mean by "exports not working when using uMFCD"?

Thanks. :)

@IceMaker & G00dnight Yep, it doesn't save export positions between sessions at the moment. There's no impediment to doing so - it is simply that the code driving that functionality is presently in the middle of an upgrade in response to new requirements brought about by features we're adding to things like the CDU. What I didn't want in this release was displays mysteriously vanishing (i.e. buggily being displayed offscreen somewhere), so it presently defaults to a set of precalculated positions. The "mouse floating" issue, however, is one of a category of bugs I personally chalk up as "profoundly annoying". As you can see from the absence of this occurring in the videos, it's clearly an unusual and unwanted behaviour. I have some ideas as to why this might be happening, but I may also contact you both directly for specific feedback if that's OK.

OK... that's sort of good news. As mentioned previously, I will add some output which will give us some stats for specifically this issue on your machine.

Re: Keyboard bindings not working You are all quite right. I managed to disable this functionality in Beta 1. It will reappear in the next release.

Thanks for the report. This is actually one that I was semi-expecting. Without getting in to further nitty-gritty, when you say your displays are in "surround" mode, would that be the surround mode offered specifically by nVidia cards? The screenies you posted are symptomatic of uMFCD literally half working, and I anticipated trouble with said "surround" technology.

Hi folks, Thanks for all the feedback. It's all very useful stuff, so please keep it coming. I'll respond to the specific problems reported over the weekend over the course of the next 24h. Baker

Roger that. Will make the next release more vocal about stuff that's going wrong. There should be an error report in the Windows Event Log. Mind pasting it here or emailing it to dcsmods@fe23.co.uk?

Each window has three size/position memories that can be selected by clicking one of the three icons that appear in the top-right of any exported display. Additionally, future versions will definitely have options allowing you to specify exactly which displays to export.

Here's that link again: https://ultramfcd.com/Public-Beta-1

Now this is why we have beta tests. You should be getting waaaaay more than 10/15fps given your specs. Kindly check that you have the correct drivers installed for the AMD 290. If the problem persists, I'll add some debug output which will give us an indication of exactly where the massive drop in FPS is occurring. uMFCD's "design goal" is 30FPS on a "wheezy" system - which yours is not.

This is almost certainly something preventing UltraMFCD Beta 1 from contacting ultramfcd.com on startup. The "phone home" thing is only implemented in the Beta versions - such functionality would be an abhorrence in any live product. Check and re-check that your firewall isn't silently blocking network comms.

Is anybody else getting this message?

That probably means that your uMFCD isn't able to contact the server for beta verification. Are you allowing it to access ultramfcd.com?

Give her hell: https://ultramfcd.com/Public-Beta-1

While we (I) are engaging in acts of patience regarding this datacentre issue, here are the goals of this particular beta test: Caveats: This test is aimed squarely at the A-10C. This is merely on account of this being the aircraft on which I personally have the most hours. UltraMFCD should make an objection known and do nothing more if you launch with a different aircraft. For pilots of other aircraft: Don't worry. Work is well under way where your plane/heli is concerned. Additionally, this version requires that you run the sim in Windowed Mode. Instructions: Launch UltraMFCD.exe prior to launching a flight in the A-10C. That should be it. If you're feeling adventurous, you can try breaking the settings, which are accessed via the cog icon. What to expect: Beta1 should export both A-10C MFCDs and the CDU. Given that the CDU is only a few days old, you should expect some bugs when it comes to its functioning. The direct-entry keyboard mode is not supported in this beta. You should be able to drag the displays to any connected monitor, and clicking areas associated with OSBs/LSKs should have the desired effect. Goals: Does it run? We may have overlooked something deal-breaking, and aren't afraid of utter failure. Does it work as expected? Programmers are notorious for not anticipating the needs/actions of the end user. Is the framerate acceptable? Most internal testing was done on last-generation gaming hardware, yet we may have overlooked something. Note: You can adjust the overall rate of exports from UltraMFCD's setting screen in real-time. What to do if something goes wrong: Please let us know! Take a screenshot. Even better: Try to record a screencap video. Look at the Windows event log in the event of a crash.

It is speculated to be some sort of Black Friday-related internet meltdown.

I'm pleased to announce that beta testing with volunteers from this thread will begin today. As I type this, Murphy's Law has swung in to action rendering the entire datacentre where ultraMFCD and its shenanigans are hosted offline.

Yes, it will. The groundwork that enables the export of any video-based display is complete, so you can expect to see all the other systems in the very near future. (Perhaps we're simply not showing off ones that are already in development ;) ) While it is relatively easy to send the displays over a network to be displayed on another computer, the bulk of the rendering must, by definition, be performed by the sim itself. The TGP and Shkval, for example, are each a complete render of DCS's 3D "world" from the perspective of whichever bit of the aircraft the system is attached to. To have a different computer perform the rendering would require that computer to be running a full copy of DCS in lockstep sync with the machine you're flying on. In other words: A massive and daunting task that is well beyond the scope of uMFCD.

Precisely that, yes.

We should invest in better radios. :) uMFCD doesn't modify or overwrite any aspect of DCS, ever. While funky stuff in Export.lua could potentially affect its functioning, the system is designed from the outset to work alongside other mods. While I'm not going to say there'll never be a conflict between uMFCD and other mods (as I can't see in to the future), it the very nature of uMFCD's design render it comparatively easy to resolve on this end. Not sure about the radio frequencies. Will have to check. B

You make a very good point. The release is expected to... <radio static> :smilewink:

Sweet :)