Sgt_Baker

Starting here. For reasons unknown, mods locked the most recent uMFCD thread.

Not in a million years. Nice try, but you're going to have to start from scratch. :)

You're perhaps referring to "the codes" that inspired UltraMFCD to begin with. There were clearly plans on ED's part to implement something approaching that which uMFCD provides.... back in 2008. That code path died, yet remained within DCS for any curious person to discover. Unfortunately I'm no longer going to pay particular attention to UltraMFCD nor DCS or the furtherment of the former. To position this within some form of understandable perspective, I've been programming since my childhood. However, it wasn't until the mid 2000s that I learned the art of server-grade programming. That is, for the uninitiated, software that is uploaded to a server which runs, unattended and without fault 24/7 for years at a time. Indeed the most famous of these pieces of software have only ever been shut down in order to move them to more modern servers. Years and years of flawless service. Remember that part. Now allow us to consider UltraMFCD. It amounts to a system which invades DCS, bypasses any semblance of "anti cheat" systems and begins not only pulling imagery from DCS's core, but also manipulating the resolution at which said imagery is rendered. UltraMFCD can pull 4K display renders from a system running DCS at 720p. So why, suddenly, with all of this marvellous technology, throw in the towel? Simple answer is it requires a vast effort to maintain the functionality of UltraMFCD while DCS are constantly moving the goalposts. Why are ED moving the goalposts? Because they don't care about Ultra-effective mods! Oh, and having to pay £££££££ just in order to check whether any new module is appropriate for exports to UltraMFCD? Yeah, no. So, folks, that's it. Game Over. Insert Coin.

Small twist of the wrist!

After all this time, Eagle Dynamics et al could have rendered uMFCD immediately obsolete with a small twist of the wrist. It is time they do precisely that. ED should implement uMFCD functionality natively.

CORRECTION: Screw it. Somebody else can start from scratch. So long and thanks for none of the fish :). I've had six years of this bullcrap and not a moment more.

For absolute clarification: UltraMFCD 3.0, which supports DCS 2.5, is essentially in the bag bar a few non-gamebreaking glitches - i.e. there's the occasional GPU frame or two every few minutes at worst or never at best (in terms of GPU FPS - so two frames of 60FPS every few minutes) where it momentarily glitches out. However, given circumstances globally, there are various people and businesses whom have, perhaps foolishly, come to rely on my talents in order to see their own businesses through the consequences of SARS-CoV-2. As such I cannot de-support those people/businesses, to a lesser or greater extent, in order to concentrate on finishing uMFCD 3.0. I am, however, directly now downloading a clean install of DCS against which to assess uMFCD 3.0 with a view to determining precisely how close to release-grade we are. If 3.0 appears to be 95% functional, even if you're required to avoid certain graphics settings, then I will release it under that proviso. Ideally uMFCD would be 100% functional and fool proof, however the increasing volume of correspondence would indicate that people are prepared to deal with the odd non-game-breaking glitch. Let me know what you want below. --Baker

The quick lowdown: UltraMFCD 3.0 exists and works. Currently concentrating on pulling quagmire businesses out of the mud. How not to butt heads with forum mods again.

Hello folks.

The point is that after paying £££ it is somehow expected that bug reports be backed by "tracks and video" - the sort of thing that would be produced by a normal in-house QA team.

"lol"

DCS tracks are non-deterministic - that is to say that every time you replay a track, DCS rolls different dice. Asking again and again for the person whom paid £££ for software to bother themselves with recording a track is, in this instance, going to get you nowhere.

While we're here, and speaking in terms of professional software development, "could not reproduce" is absolutely, in no uncertain terms, NOT synonymous with "bug doesn't exist". I don't know about you lot, but my professional decorum is based entirely on finding and fixing the most evasive and elusive of bugs. Not for a second would I even consider telling the client that their bug report was somehow imaginary. And if my software can pull imagery directly out of DCS's rendering engine, that should grant you an insight in to the "level" of software engineering at which I operate. A level at which one doesn't suffer fools gladly. You can "waaaaah" all you like. The bug exists and it, given rather comprehensive descriptions thereof, is yours to find and squash.

And you should all be aware that a DCS Track is non-deterministic. You'll run the same track multiple times and get a different outcome every time.

Wow, do I have disappointment for you.

Yet "LA LA LA LA CAN'T HEAR YOU". How /very/ military of you all.

The ground-based search radar is swapped with the airborne search radar. OBVIOUSLY!

I repeat:

Fly straight and level. Put the RWR in to OFFSET mode and it arbitrarily swaps contacts. How difficult is this to understand?

Nope.

All Western RWRs behave that way.

I have, although most of my jokes concern erectile dysfunction.

Now, as for the "attitude". You don't pay people money only to perform the horse-work yourself.

Yeah, this attitude. I can't imagine that many people use the F/A-18C Lot 20's "OFFSET" button given that it's hidden behind the in-cockpit joystick (unless one uses the "remove joystick" function). If "lit up" and fired upon by an S-300 site, you're being "painted" by three radars; all on the same bearing: Two search radars and one fire-control radar. You might possess four AGM-88 HARMs per aircraft with which to counter this action. However, since you've blundered in to the catchment area of an S-300 battery, how do you most effectively shoot back? Self-Protection mode. In Self-Protection mode, you can fire the AGM-88 HARM at any given emitter detected by your RWR apparatus. Yet how does one ensure that one places one missile on each of the detected emitters? Or even know there are multiple emitters (other than education regarding S-300 sites)? OFFSET MODE! OFFSET mode allows you to fire an ARM at each of the threatening emitters without the guesswork. * * * * * * * * * * * * That's why and how I know OFFSET mode is broken. The screen symbols go out of whack, while in OFFSET, and swap this or that or the other emitter. Yet the missiles and underlying sim are unaffected. It's easiest to reproduce if you set obviously-different radar emitters at great distance from each other then click in and out of OFFSET mode. The F/A-18 will frequently swap emitters at random.

It's more that people are clamouring to pay. I'm quite happy to carry on as is. The least of my interests is to introduce a complicated - both to conceive and maintain - freemium model in terms of that which already exists in uMFCD. So what to do with monies hypothetically paid by those whom insist? The best, any only idea, I've considered generally viable is to use funds to persuade ED to pay a tiny bit of attention to uMFCD. A day's work of a single developer on their end removes 100 days of a single developer on this end. Or, with the pending apocalypse, could just spend it on hookers and crack. Although I hear bad things about both of those. * * * * So when optional payments are implemented (which I could set up today, independently of any "crowdfunding" platform) what to do with the pot of cash? Start a hedge fund? In which videos are posted online of people admiring hedges? Help me here! :) --Baker