Sgt_Baker

And just to provide a certain "programmer's diary" impression of how the workload is distributed when supporting multiple operating systems: Inside DCS: Every time they add better features to the graphics pipeline, UltraMFCD might/will break. Windows: Code you wrote in Windows 8, and after 1,000,000 OS auto-updates, still works fine in latest versions of Windows 10 (and Windows 7 too). Android: Yeah whatever. Just your code can't have picture-in-picture or {list of unrelated features here}. Still runs off the bat if you've ignored it for a few years. iOS: (Updates from 13.0.0.0.0.1 to 13.0.0.0.0.2): "OMG! CODE BLUE! CODE BLUE! CODE RED! NUKES ARE COMING! CODE ORANGE! EBOLA! RADIATION! ASTEROIDS!" Raspberry Pi: See Android.

1) The only thing preventing DCS from running "Fullscreen" (this is a long and complicated thing. Nothing is truly fullscreen any more) is that UltraMFCD needs to run its displays in windows independent of DCS's "window". In the instance of exclusively running exports on external networked devices, DCS would indeed be fine running in "Fullscreen" mode. Handy if you, say, use some complicated SLI setup or other such esoteric stuff. 2) I hadn't actually considered, until now, Raspberry Pi at all. But good news! The design of the network streaming system is such that the client's (satellite) code base is as [ultra]lightweight as possible, thus reducing the human overheads of maintaining software clients on multiple operating systems. Additionally, it is designed with the idea that the client could be anything from an abacus to a supercomputer and will render as fast as possible up to its maximum resolution/FPS, even when different clients of vastly different capability are connected to a "server" instance of UltraMFCD. I've not touched software development on a Pi, yet can state with confidence that it can support streamed displays to exactly the same extent as phones and tablets. Edit: 1/1000th the complexity of your current setup.

That will likely be the next aircraft to gain support. It's no coincidence that back in the day I flew Jane's F/A-18. And then Falcon 4.0: Allied Force. Familiarity is rather helpful, as you might imagine, in determining how things ought to function.

It should/might work with VR once I get around to implementing that as an official feature. The reason it not at the front of the queue is that it's expensive, time-consuming and would detract from implementing features that are in greater demand.

Yes, that's exactly what it does. Zero configuration. Everything is 100% automatic. And it doesn't make any changes to your files, so if you decide you don't like uMFCD you simply forget about it. There's nothing to uninstall or undo.

A work in progress.... But where do all the calculators I mean Radio Messages go? There's a good reason for this. Maintaining one's kneeboard scratch pad is all fair and well until AI aircraft start freaking out during a furball and spam over the radio constantly, including over transmissions for you, until one side or the other is all dead.

The technical theory and groundwork for uMFCD + VR is already laid down and sound. Yet I'll be honest in that it's not a priority feature at the moment. For every person flying in VR there are twenty asking for this or that module support or these or those additional features. Oh, and the resources required - in terms of time and £££ - to implement VR support are probably about the same as implementing support for all sensible aircraft plus network streaming. Consequently the road map must follow a route of certain common sense. :)

UltraMFCD has never supported true full-screen mode (nor, for that matter, does Windows these days). Full-screen, borderless windowed mode is, however, supported. There's a very good reason for this in that a full-screen application is 100% greedy when it comes to the screen space and mouse clicks. So the unacceptable scenario would be that DCS minimises every time you attempt to interact with a uMFCD display, whether it be moving, resizing or clicking buttons. If you're having issues with non-fullscreen DCS perhaps there's some driver/setup/hardware issue somewhere else, as DCS (and uMFCD) runs normally on 2012 hardware (at 2012 FPS, obviously) in tests on this end. And yes to iPad. Edit: Although it should be fine with full-screen if you're on running exported displays on external devices.

Yep. Exactly what you see in the desktop version, except on the device(s) of your choosing.

It's interesting that you mention this. The financial model you're referring to is generally known as "Freemium" - one where basic features are available to everybody yet the advanced features are licensed for a reasonable fee. UltraMFCD is now, believe it or not, six years old. Its inception occurred almost by accident in the month following my finding myself homeless due to business deals gone wrong and poor decision making on my part. A royal cluster*$£%, if you will. UltraMFCD is, however, an extraordinarily complex piece of software. In order to extract displays from DCS demands that somebody (me) stare at The Matrix of numbers, detect patterns in those numbers, then program uMFCD to detect said patterns and extract the displays. This is a hideously complex process and the reason that uMFCD breaks down every time Eagle Dynamics adds new eye candy to their graphics rendering engine. Fast-forward to the present day and the business behind uMFCD is in excellent health and, indeed, extracting money from non-DCS-related customers whether it be cash, card-holder present or card-holder not present. So, for those wondering where I've been, that's what I've been engaged with during my multi-year absence. So this is what I'm suggesting: Implement a freemium model in UltraMFCD 3.0. The more people who purchase a premium license the more money raised. Offer to pay Eagle Dynamics - whom have historically been resistant to anything uMFCD - to mitigate the "staring in to The Matrix" element that breaks uMFCD with every graphics engine update using said funds. --Baker

Don't buy them until the facility is formally announced. :)

Yes.

Hi folks, It's been a while, eh? In any case work is now underway on UltraMFCD 3.0 with promising results. What to expect: Works with latest builds of DCS :thumbup: (I find this really helps a lot) Support for new aircraft. F/A-18C first with more to follow (Mirage, Viggen, AV-8B, F-16C, F-14) as time permits and in order of which aircraft benefits most from enhanced displays. Expect eventual modelling quality in line with the A-10C CDU MkII. Aircraft/ground object labels within DCS now work again. Very important for new/learning pilots. Radio message log (potentially) Other special sauce (dust off those old Android/iOS phones and tablets, they might enjoy a second life at some point). Getting rid of the dependency on a live internet connection to ultramfcd.com in order for the app to run. Auto-update system. Better in-app clarity as to which specific versions of DCS/Aircraft are and are not presently known to be supported. Every time DCS or an aircraft is updated there is the potential for those updates breaking uMFCD, so said system should alert you to whether it's a problem with the system in general or just that we've not yet caught up with any particular update. More to follow. In the mean time, some eye candy: --Sgt_Baker

What's stopping them? Other than prior art.

I would like to get rid of the super-hacky parts of the system. It would literally take Eagle Dynamics half an afternoon. I should know! I actually did it!

It presently costs $1672.45 (USD) to purchase the entire DCS ecosystem. And that's not including money spent on associated hardware, such as joysticks, pedals, or full-on custom cockpits (which I will get back to in a moment). If this were an open-source title and I were merely some random bloke demanding changes, I would understand ED's dismissive approach. This is not the case. People pay more to use DCS, and by a large margin, than 99.9999% of all other recreational software. Meanwhile people are getting their knickers in a twist regarding EA's latest DLC debacle on a $60 game. I have recently stated that ED are continually dismissive of any notion whereby UltraMFCD might transition from being non-cooperative to cooperative in its relationship with the DCS system. But here's the thing! Due to UltraMFCD's function, I happen to be able to collect metrics. Its users have purchased well in excess of $1,000,000 worth of software from ED. This thread is absolute evidence that a literal megabuck doesn't matter in terms of requests for change. UltraMFCD is used by a wide variety of people, but the most interesting of their cases concerns the simpit builders. They spend $10,000s ON TOP of whatever DCS costs in order to create as faithful a sim experience as they can. Continued refusal to entertain UltraMFCD as a going concern is no only a middle-finger to me. It is a middle-finger to a userbase that has already furnished ED with seven-figure sums in USD. Nostravia!

No, not directed at users. If anything, UltraMFCD was developed with a view to keeping you lot out of my hair. Low-maintenance, if you follow. Notice that it's the only "mod" not to arrive with the ominous "back up everything in case things go wrong" disclaimer. Why? Because it doesn't change anything in terms of physical storage or files associated with DCS. But now I'm just stroking my own ego.

Hi NineLine, Sorry. I didn't mean to post this publicly. I'll get back to my contact within Eagle Dynamics at the earliest opportunity. They will certainly address the issue with immediate effect. Furthermore, congratulations for your service to dimwittery. If only more moderators were as vocal as you. --B

Dear Eagle Dynamics, UltraMFCD is not dead. However, and understandably - I would be too - Eagle Dynamics aren't too pleased with some random bloke coming along and tugging at the brain stem of their custom rendering engine. Pleas have been made - up to and including healthy offers where potential revenue sharing is concerned - in order to resolve the perceived brain-stem-tugging conflict. I would like nothing more than NOT to have to fiddle around with DCS's internal plumbing in order to make uMFCD do what it does. Yet here we are, years in to the "we can't stop each other" conflict, and no closer to amicable resolution. People want UltraMFCD on account of its obviously beneficial functionality. I want to provide UltraMFCD users with the functionality they desire. And they constantly request more and more and more. Is there any way, means or method by which we can meet in the middle? Best regards, Sgt_Baker

It's not only uMFCD: http://www.bbc.co.uk/news/technology-43288497 :D

Thanks for all that effort in working out the quirks, Holton181. In a stroke you've made life much easier come the next update. :)

For all of you who are wondering, development is sitting around in its staging area awaiting DCS World 2.5. All of these vacuum packed rations. Day after day... :) --Baker

Me neither, despite a lot of trying. I believe these two are the exact same problem manifesting in different ways. In internal builds I'm now detecting 2.1.1 and automatically disabling the colour LITENING before it gets anywhere near DCS. This seems to solve both the no-maps error and the retry/cancel dead loop. Am presently looking in to this one. Enjoy! :) --Baker

The distance of a degree North/South is always 60nm regardless of where you are on the planet.

Looks like this is down to the Colour LITENING/Shkval option. Will auto-disable in 2.1 until things with the rendering engine have settled down.