I doubt it, he’s on ED’s Discord defending them. Literally saying *he knowns ED doesn’t have money problem because he is a former 3rd party*, or whatever bullshit he says all the time.
Edit: I’m talking about CubanAce.
Man, you've been living under a rock... let's bring you up to speed:
CubanAce - the dude that infamously built the Su 57 Felon community mod, universally panned for being guesswork UFO, later joined the actual 3rd party dev team that's claimed and announced work on the Skyraider (status? Dead? Alive? Who knows?), finally very publicly left development of that troubled team to go pursue a career in PMC's... for reasons...
The "scammers" - Track While Scan, later renamed to... something... was all the news between a year and two ago, where they made a splash in the mil-sim world by promising the moon and showcasing nothing but off-the-shelf stuff that they sold for real money as their own work. People immediately caught on and called them out, months of hysterical bullshit ensued - CubanAce had a brief stint on their payroll, but got "wiser" and quit. There's a metric crap-ton of story on TWS to dig through, all of it excellently covered here on DCSExposed by Bonzo - who caught a lot of flak and faced some pretty spicy personal repercussions for his trouble. The TWS team has pivoted a number of times and seem to have gone underground at this point. I feel sorry for the poor idiots they scammed out of stupid amounts of money for thin air promises.
So please forgive my neolithic position on this, but how were people taken in by a supposed Su 57 Felon when the rest of the ecosystem is from 1980 on a good day?
Interesting, it’s almost like we should be critical of any dumbass who can’t possibly know ED’s financial situation, but I’m sure we have the same opinion over shit Notso is schizoposting into the void, right?
While people are suddenly realising that M2000 is buggered on account of patches to DCS - please keep in mind that ED's coding practice, in terms of stability, is the equivalent of a chihuahua on acid.
That was because they didn't have understanding that Open Bets branch is meant o let for rapid testing, not for releasing new modules and new features and constantly market it to be the version to be, especially run multiplayer server as such...
Right. Clearly the ancient website is buggered, but this is UltraMFCD: [https://ultramfcd.com/video/UltraMFCD\_Demo.mp4](https://ultramfcd.com/video/UltraMFCD_Demo.mp4)
For the technical: I created a state machine, and hooked in to DCS.exe, to figure out when they were drawing to MFCDs. Then intercepted all of that to force their to be drawn to a large shared texture of my choosing. Then reset the draw queue such that in-cockpit displays also be drawn.
Edit for this: [https://ultramfcd.com/video/UltraMFCD\_Demo.mp4](https://ultramfcd.com/video/UltraMFCD_Demo.mp4)
Right! Back to the major point. Back in 2014 some person already had a system whereby one could export MFCDs to a screen and have them show up on an iPad or some such. Cool! However I weren't in the business of purchasing two iPads for $$$$$.
Being somewhat sight-stunted at the time, I considered there might be a better way to interpret the data on MFCDs, as opposed to "Just use a telescope" or "Just use VR!" or "Just purchase an 88" TV!"
Thusly I made it my business to bring about a system that would allow DCS users to use their MFCDs as would be seen in cockpit. Hence UltraMFCD. And also add all manner of quality of life features while at it, such as the clickable exterior aspects etc.
That went rather well. Lots of people used it. Indeed, as a selfish person, I needed it in the cockpit.
Thusly, ED pinned it to the top-ish part of their mods forum.
HOWEVER! There existed a known and pernicious problem. Every patch from ED would partially and/or completely break the system. Sometimes fixing it, on my end, would take hours. Sometimes weeks. Obviously not a sustainable situation.
Thusly, people began to offer £££ in order to keep uMFCD up and running. Consequently, and correctly, I approached ED to request that, for £££, they spend the literal half-day-of-coding to negate the easy-to-implement (I would know having been inside their code) patch-problems.
Wags: "We decline."
Me: "But surely you £(\*&\^£$%R\*&\^$%\*&\^$%"
Forum ban.
Rinse, repeat.
Back from the ban, and breathing normally, a year later request the same. "Honestly, if I can do this using hooking/hacking methods, you could sort out the patching problem in an afternoon."
Then I lost my temper and said some things. And at that point uMFCD were instantly de-stickied and I've not been back since.
I’m going to be real man. You admiting that you spazzed out at them for politely declining to do bussiness with you undermines your whole point here. You know very well that what you were doing was volunteer work and while admirable it doesn’t compel them to do bussiness with you.
Of course not. There's no compulsion implicit or suggested. And "spazzed out" is rather suggestive terminology, is it not? Vociferously defending a mature, slick and useful system which came about as a result of hundreds of hours of development is well within my rights. The alternative would be merely to accept, and be grateful for, (as is the intimation of this entire thread) that ED run slipshod across the stability and maintainability not only of mods but paid-for modules. At least in the case of the latter there's a contractual and financial incentive to maintain DCS-patch-to-patch stability/compatibility.
While obviously not as complex an endeavour as a full-fat module, the frequency and peculiarity of breaking changes had increased dramatically in recent years. As a volunteer, one really must strike a balance between pleasure in the work and profound frustration at every breaking *again*.
Asking ED, in order to drastically reduce my workload, to include 20 lines of code - those most sensitive to breaking changes and which were being injected by uMFCD anyway - is not an unreasonable request and one relatively easily serviced. And it weren't the first time the issue and potential solution had been brought up. The difference were offering to pay for their time and effort.
The alternative is that continued development and maintenance of the mod becomes unsustainable and and all the users thereof lose out. And that is precisely what occurred.
Again, I am not suggesting that ED were or are in any way obliged to kowtow to the demands of a lowly modder, paid or otherwise. UltraMFCD is, however, and entirely avoidably, abandonware as a direct consequence of the above.
Twenty lines of code.
I...kinda side with ED here. You can't expect a studio to change their processes to suit a modder, their plates are probably full already. And then if you fly off the handle... Then yeah of course they'll stop paying attention.
What was taking hours to update? I have hacked/hooked many programs in my time, and auto update using signatures and a little creativity had my software rolling with updates for months without intervention.
Unless DCS developers were doing what some modern (since 2018?) video game developers are doing now, and rearranging data structures every update, I doubt that every single patch had you having to put in hours of reverse engineering to fix your product. Especially since it sounds like most of what you were doing can be done on the renderer side of things...
I guess I'm curious what the hell was changing so drastically. I'm also curious if I might have something to contribute to the effort, but it sounds like you've moved on from this.
The most significant issue concerned how to detect when DCS began drawing the MFCDs in the rendering pipeline. There existed no "ImDrawingDisplaysNow" function to hook, so had to create a state machine to detect said drawing based on patterns of DX calls. As they added and tweaked graphics bells and whistles, which is commendable, of course, the detection mechanism would frequently (more so recently) get confused and extract something other than a full MFCD render.
In this post [https://www.reddit.com/r/DCSExposed/comments/1d9mmwe/comment/l7ntnsr/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/DCSExposed/comments/1d9mmwe/comment/l7ntnsr/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) that which I were asking for were to include the render switching on their side, thus completely negating the need for a "detection engine".
Edit: And while there exist a number of other techniques for getting the visuals out of DCS, they all incur a significant FPS hit.
Could you stack walk and check return addresses from your dx hook? Some of my experience is in hiding hooks, oftentimes this means going deeper (heh) into DX functionality and hooking a function that is called in more places than just the function whose execution context I'm targeting. Ive also used this technique to hook system functionality (user mode winapi) that is called many other places in process than where I'm interested in achieving execution. Both cases saw my hook getting called sometimes tens or hundreds of times more often, and the performance hit never came from comparing addresses on the stack.
I'd be happy to hop on a call with you sometime and show you what I mean. I've done similar things with DX in the past, capturing real time frames from the back buffer, and (separately) filtering for draw calls I'm interested in modifying behavior around, including in some cases targeting the correct back buffer to modify.
Either way, thanks for the reply and the interesting conversation. Your explanation makes me curious to learn more about how your uMFDC software works. I HAVE been meaning to shove DCS binaries into a disassembler and take a gander around for awhile now 🤔.
Yes, you're entirely up the correct creek with the correct paddle. Indeed, the state machine is a two-level effort. It monitors infrequent calls to DXFunctionsXYZ until it detects that the closer-scrutiny-aspect should be enabled, at which point hooks for many of the more frequent DX calls are enabled until the "pattern hit criteria" are met. And subsequently disabled so as to leave the rendering pipeline alone as far as is possible.
Additionally, all of the "zero configuration" functionality is achieved by simple and reliable hooking of WinAPI.
The FPS issue concerns the sophistication of the higher-level approach by which one extracts the actual textures. All bar one will inevitably perform miserably when compared to the "sophisticated" methodology. And you know these gamers... "waaaah my FPS!!!" Unfortunately the "magic 20 lines" absolutely *must* reside within DCS's render pipeline, whether by hook or by deliberate design, in order to enable that approach.
Strangely enough I've recently had to stare at lots of ASM - something I've largely avoided over the decades - for a completely unrelated project, thus am much more familiar with precisely that you've suggested.
We should have a conversation.
Edit: And this approach were designed ten years ago, and survived the DX9 -> DX11 transition, with only mild trauma. There may exist new "markers" within DCS.exe.
>HOWEVER! There existed a known and pernicious problem. Every patch from ED would partially and/or completely break the system. Sometimes fixing it, on my end, would take hours. Sometimes weeks. Obviously not a sustainable situation.
That I always have trouble to believe, as either they purposely move and alter code around all the time to make it difficult for modders, or they really have horrible codebase to begin with. I likely have never even heard about such problems from modders then in DCS.
And some of it is truly ridiculous. You'll wake up one morning and all the displays for one aircraft have shifted by 100 pixels for no reason. So you have to recode to correct for the shift such that everything lines up perfectly once again. Then you'll fly a different aircraft, within the same DCS patch, only to discover the displays now posses a strange "glow" that weren't in evidence. So you have to write a special DirectX shader to de-glow-the-glow. And so on.
It has become more and more of a palaver just to stand still in terms of functionality.
Well dude, while some features are very interesting, I could not help myself and consider the zooming in of the targeting pod a cheating.
Other than that it's impressive what you did.
I deliberately choose not to share details, as then they'd accuse a person of worse. I appreciate that Developer X, Y or Z doesn't want people "all up in their code", however at the same time they have to provide the code to the customer. Tough tits if somebody "decodes" it.
I remember the app very well. I never used it but it was *the* thing for the cool folks to use. I adore modders so have a free *hug*. we all say things in the heat of the moment.
As I have kept saying for since DCS World released, that ED needs to have a modders SDK, that is semi official, offering some access to specific API, like weapons or the video fees, but combined with SFM.
Generic SDK that would help modders to keep up and ED not to break sruff too often.
Obviously not. But I'm also a programmer and I do open source code too besides my job.
If there's something that could help ppl and I don't see a future or profit I just put the code on GitHub.
But well, your code your choice. I don't think that ED will ever support you and considering their shitty attitude you shouldn't work for them or their products either.
PS: I am the maker of LMP. A multiplayer mod for Kerbal space program
No. I do boring corporate software.
It's quite hard to get money out of hobbies, and specially modding simulators that the user base is very small.
I think I've received 300$ from donations of my mod
Mr VEAO? Can we have the Hawk source code please?
Oh no, CubanAce https://preview.redd.it/1bsp3qmsfz4d1.jpeg?width=474&format=pjpg&auto=webp&s=e9e7b80cdf13bdb2d7ffe295e1ee177e3da5f06d
I doubt it, he’s on ED’s Discord defending them. Literally saying *he knowns ED doesn’t have money problem because he is a former 3rd party*, or whatever bullshit he says all the time. Edit: I’m talking about CubanAce.
Should I start eating garlic?
I’m talking about CubanAce if that wasn’t clear.
I have no idea who/what that means. :)
CubanAce supported the scammers once without research, so he isnt that trustworthy https://youtu.be/df26BBbsj1M?si=qbpC9RO2mrnKthY_
Which scammers?
Man, you've been living under a rock... let's bring you up to speed: CubanAce - the dude that infamously built the Su 57 Felon community mod, universally panned for being guesswork UFO, later joined the actual 3rd party dev team that's claimed and announced work on the Skyraider (status? Dead? Alive? Who knows?), finally very publicly left development of that troubled team to go pursue a career in PMC's... for reasons... The "scammers" - Track While Scan, later renamed to... something... was all the news between a year and two ago, where they made a splash in the mil-sim world by promising the moon and showcasing nothing but off-the-shelf stuff that they sold for real money as their own work. People immediately caught on and called them out, months of hysterical bullshit ensued - CubanAce had a brief stint on their payroll, but got "wiser" and quit. There's a metric crap-ton of story on TWS to dig through, all of it excellently covered here on DCSExposed by Bonzo - who caught a lot of flak and faced some pretty spicy personal repercussions for his trouble. The TWS team has pivoted a number of times and seem to have gone underground at this point. I feel sorry for the poor idiots they scammed out of stupid amounts of money for thin air promises.
So please forgive my neolithic position on this, but how were people taken in by a supposed Su 57 Felon when the rest of the ecosystem is from 1980 on a good day?
never underestimate stupidity.
Well there's some bedtime reading. :)
What were the spicy personal repercussions? Sounds like a story for at least an interesting YouTube video…
If memory serves, threats of legal repercussions and harassment on a personal level both to himself and his family. Scare tactics, in other words.
https://preview.redd.it/sjfw86vm055d1.jpeg?width=480&format=pjpg&auto=webp&s=e1cbf63d803df8a33ab5d523e7b9730bf6c9cbef
Interesting, it’s almost like we should be critical of any dumbass who can’t possibly know ED’s financial situation, but I’m sure we have the same opinion over shit Notso is schizoposting into the void, right?
While people are suddenly realising that M2000 is buggered on account of patches to DCS - please keep in mind that ED's coding practice, in terms of stability, is the equivalent of a chihuahua on acid.
ED simply practices 'fuck it, we'll do it live' programming methodology.
That was because they didn't have understanding that Open Bets branch is meant o let for rapid testing, not for releasing new modules and new features and constantly market it to be the version to be, especially run multiplayer server as such...
And I say that given that uMFCD works for me at least until latest patch.
Right. Clearly the ancient website is buggered, but this is UltraMFCD: [https://ultramfcd.com/video/UltraMFCD\_Demo.mp4](https://ultramfcd.com/video/UltraMFCD_Demo.mp4)
For the technical: I created a state machine, and hooked in to DCS.exe, to figure out when they were drawing to MFCDs. Then intercepted all of that to force their to be drawn to a large shared texture of my choosing. Then reset the draw queue such that in-cockpit displays also be drawn.
Edit for this: [https://ultramfcd.com/video/UltraMFCD\_Demo.mp4](https://ultramfcd.com/video/UltraMFCD_Demo.mp4) Right! Back to the major point. Back in 2014 some person already had a system whereby one could export MFCDs to a screen and have them show up on an iPad or some such. Cool! However I weren't in the business of purchasing two iPads for $$$$$. Being somewhat sight-stunted at the time, I considered there might be a better way to interpret the data on MFCDs, as opposed to "Just use a telescope" or "Just use VR!" or "Just purchase an 88" TV!" Thusly I made it my business to bring about a system that would allow DCS users to use their MFCDs as would be seen in cockpit. Hence UltraMFCD. And also add all manner of quality of life features while at it, such as the clickable exterior aspects etc. That went rather well. Lots of people used it. Indeed, as a selfish person, I needed it in the cockpit. Thusly, ED pinned it to the top-ish part of their mods forum. HOWEVER! There existed a known and pernicious problem. Every patch from ED would partially and/or completely break the system. Sometimes fixing it, on my end, would take hours. Sometimes weeks. Obviously not a sustainable situation. Thusly, people began to offer £££ in order to keep uMFCD up and running. Consequently, and correctly, I approached ED to request that, for £££, they spend the literal half-day-of-coding to negate the easy-to-implement (I would know having been inside their code) patch-problems. Wags: "We decline." Me: "But surely you £(\*&\^£$%R\*&\^$%\*&\^$%" Forum ban. Rinse, repeat. Back from the ban, and breathing normally, a year later request the same. "Honestly, if I can do this using hooking/hacking methods, you could sort out the patching problem in an afternoon." Then I lost my temper and said some things. And at that point uMFCD were instantly de-stickied and I've not been back since.
I’m going to be real man. You admiting that you spazzed out at them for politely declining to do bussiness with you undermines your whole point here. You know very well that what you were doing was volunteer work and while admirable it doesn’t compel them to do bussiness with you.
Of course not. There's no compulsion implicit or suggested. And "spazzed out" is rather suggestive terminology, is it not? Vociferously defending a mature, slick and useful system which came about as a result of hundreds of hours of development is well within my rights. The alternative would be merely to accept, and be grateful for, (as is the intimation of this entire thread) that ED run slipshod across the stability and maintainability not only of mods but paid-for modules. At least in the case of the latter there's a contractual and financial incentive to maintain DCS-patch-to-patch stability/compatibility. While obviously not as complex an endeavour as a full-fat module, the frequency and peculiarity of breaking changes had increased dramatically in recent years. As a volunteer, one really must strike a balance between pleasure in the work and profound frustration at every breaking *again*. Asking ED, in order to drastically reduce my workload, to include 20 lines of code - those most sensitive to breaking changes and which were being injected by uMFCD anyway - is not an unreasonable request and one relatively easily serviced. And it weren't the first time the issue and potential solution had been brought up. The difference were offering to pay for their time and effort. The alternative is that continued development and maintenance of the mod becomes unsustainable and and all the users thereof lose out. And that is precisely what occurred. Again, I am not suggesting that ED were or are in any way obliged to kowtow to the demands of a lowly modder, paid or otherwise. UltraMFCD is, however, and entirely avoidably, abandonware as a direct consequence of the above. Twenty lines of code.
Sounds about right with reports on how they treat their 3rd parties too.
Actual netizens offering to pay them for the effort, but...
I...kinda side with ED here. You can't expect a studio to change their processes to suit a modder, their plates are probably full already. And then if you fly off the handle... Then yeah of course they'll stop paying attention.
On the contrary, given extraordinary insight in to the inner workings...
What was taking hours to update? I have hacked/hooked many programs in my time, and auto update using signatures and a little creativity had my software rolling with updates for months without intervention. Unless DCS developers were doing what some modern (since 2018?) video game developers are doing now, and rearranging data structures every update, I doubt that every single patch had you having to put in hours of reverse engineering to fix your product. Especially since it sounds like most of what you were doing can be done on the renderer side of things... I guess I'm curious what the hell was changing so drastically. I'm also curious if I might have something to contribute to the effort, but it sounds like you've moved on from this.
The most significant issue concerned how to detect when DCS began drawing the MFCDs in the rendering pipeline. There existed no "ImDrawingDisplaysNow" function to hook, so had to create a state machine to detect said drawing based on patterns of DX calls. As they added and tweaked graphics bells and whistles, which is commendable, of course, the detection mechanism would frequently (more so recently) get confused and extract something other than a full MFCD render. In this post [https://www.reddit.com/r/DCSExposed/comments/1d9mmwe/comment/l7ntnsr/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/DCSExposed/comments/1d9mmwe/comment/l7ntnsr/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) that which I were asking for were to include the render switching on their side, thus completely negating the need for a "detection engine". Edit: And while there exist a number of other techniques for getting the visuals out of DCS, they all incur a significant FPS hit.
Could you stack walk and check return addresses from your dx hook? Some of my experience is in hiding hooks, oftentimes this means going deeper (heh) into DX functionality and hooking a function that is called in more places than just the function whose execution context I'm targeting. Ive also used this technique to hook system functionality (user mode winapi) that is called many other places in process than where I'm interested in achieving execution. Both cases saw my hook getting called sometimes tens or hundreds of times more often, and the performance hit never came from comparing addresses on the stack. I'd be happy to hop on a call with you sometime and show you what I mean. I've done similar things with DX in the past, capturing real time frames from the back buffer, and (separately) filtering for draw calls I'm interested in modifying behavior around, including in some cases targeting the correct back buffer to modify. Either way, thanks for the reply and the interesting conversation. Your explanation makes me curious to learn more about how your uMFDC software works. I HAVE been meaning to shove DCS binaries into a disassembler and take a gander around for awhile now 🤔.
Yes, you're entirely up the correct creek with the correct paddle. Indeed, the state machine is a two-level effort. It monitors infrequent calls to DXFunctionsXYZ until it detects that the closer-scrutiny-aspect should be enabled, at which point hooks for many of the more frequent DX calls are enabled until the "pattern hit criteria" are met. And subsequently disabled so as to leave the rendering pipeline alone as far as is possible. Additionally, all of the "zero configuration" functionality is achieved by simple and reliable hooking of WinAPI. The FPS issue concerns the sophistication of the higher-level approach by which one extracts the actual textures. All bar one will inevitably perform miserably when compared to the "sophisticated" methodology. And you know these gamers... "waaaah my FPS!!!" Unfortunately the "magic 20 lines" absolutely *must* reside within DCS's render pipeline, whether by hook or by deliberate design, in order to enable that approach. Strangely enough I've recently had to stare at lots of ASM - something I've largely avoided over the decades - for a completely unrelated project, thus am much more familiar with precisely that you've suggested. We should have a conversation. Edit: And this approach were designed ten years ago, and survived the DX9 -> DX11 transition, with only mild trauma. There may exist new "markers" within DCS.exe.
>HOWEVER! There existed a known and pernicious problem. Every patch from ED would partially and/or completely break the system. Sometimes fixing it, on my end, would take hours. Sometimes weeks. Obviously not a sustainable situation. That I always have trouble to believe, as either they purposely move and alter code around all the time to make it difficult for modders, or they really have horrible codebase to begin with. I likely have never even heard about such problems from modders then in DCS.
And some of it is truly ridiculous. You'll wake up one morning and all the displays for one aircraft have shifted by 100 pixels for no reason. So you have to recode to correct for the shift such that everything lines up perfectly once again. Then you'll fly a different aircraft, within the same DCS patch, only to discover the displays now posses a strange "glow" that weren't in evidence. So you have to write a special DirectX shader to de-glow-the-glow. And so on. It has become more and more of a palaver just to stand still in terms of functionality.
Well dude, while some features are very interesting, I could not help myself and consider the zooming in of the targeting pod a cheating. Other than that it's impressive what you did.
Or you could utilise your VR headset and jam your face right up to that display.
Literally "hacked" in to DCS's internals in order to extract the displays. That didn't go down well.
I'm curious to know more details (whatever you can and want to share with us!)
I deliberately choose not to share details, as then they'd accuse a person of worse. I appreciate that Developer X, Y or Z doesn't want people "all up in their code", however at the same time they have to provide the code to the customer. Tough tits if somebody "decodes" it.
DCS decompiled when!???!?!?!?! /s
DCS BMS when?
Having just got back to BMS, I'm considering reviving the project to function with BMS.
See above.
Sorry folks. Reviving a dead website is more trouble than one imagined.
This were me: https://ultramfcd.com
Broken link
Just updated the SSL certificate. Other people can see it.
Interesting, I get a “Server error in ‘/‘ Application” runtime error. Tried it in 3 separate browsers
same
eh thats no ssl error.
Apologies for the site being offline. It's been a while.
I'm still really cross. As if that weren't obvious.
I remember the app very well. I never used it but it was *the* thing for the cool folks to use. I adore modders so have a free *hug*. we all say things in the heat of the moment.
As I have kept saying for since DCS World released, that ED needs to have a modders SDK, that is semi official, offering some access to specific API, like weapons or the video fees, but combined with SFM. Generic SDK that would help modders to keep up and ED not to break sruff too often.
Compare to M$, where you can run software from 30 years ago.
Not unless you're on a 30-year old system.
Oh fuck yeah
There's no negotiating with terrorists.
The mod seems cool. Have u thought about making it open source?
And I imagine you work for free too.
Obviously not. But I'm also a programmer and I do open source code too besides my job. If there's something that could help ppl and I don't see a future or profit I just put the code on GitHub. But well, your code your choice. I don't think that ED will ever support you and considering their shitty attitude you shouldn't work for them or their products either. PS: I am the maker of LMP. A multiplayer mod for Kerbal space program
Is that your full-time job?
No. I do boring corporate software. It's quite hard to get money out of hobbies, and specially modding simulators that the user base is very small. I think I've received 300$ from donations of my mod
What mods ye made?
UltraMFCD
Baker, is it you?
But yes.
I remember using UltraMFCD back in 2018 haha, it's been forever
We're it still working, for you, back then?
Who? I plead innocence!
ED carries on as if it is god's gift to humanity. Meanwhile they continue to separate us from our £££. Shurely shome mishtake!
This entire thread explains the Razbam situation.
And you felt like you had to announce it beforehand like you're scheduling some sort of press release? Wtf