Jump to content

Sgt_Baker

Members
  • Posts

    915
  • Joined

  • Last visited

Personal Information

  • Flight Simulators
    DCS A-10C, DCS BS2, DCS CA, FFAF
  • Location
    London, UK
  • Website
    https://ultramfcd.com

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Starting here. For reasons unknown, mods locked the most recent uMFCD thread.
  2. Not in a million years. Nice try, but you're going to have to start from scratch. :)
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Wow, do I have disappointment for you.
×
×
  • Create New...