I know, right.lol - a whole day of people asking why the streamer hadn't been banned, how dare fdev not ban them, they were obviously cheating!
And when they get banned: How dare fdev ban them! They were doing the work of the righteous!
This place, reptilian brain in full effect
As I said our game also uses a p2p centric architecture, so I believe this would work well with ED. I was involved in the discussions that led us to choose BE but not in the technical work of integrating it in our game, so I'm a little fuzzy on the details. But as far as I remember it merely detects that someone cheats, and the actions taken against the cheater (kicking from the server, banning and such) are implemented at our discretion.happy to hear that. battleye was mentioned here a few days ago. given your experience, what is your broad view on an hypotetic implementation on a p2p centric architecture like ed? i would assume the only viable option to be to 'bunkerize' the clients (which is fairly aggressive, but yeah (and actually just high level guacamole! )), then again the little what i have read about battleye seems to point to server based control approach. maybe they can even rewrite part of stack specifically to make it possible?
this of course considering the little we actually know about this specific implementation, just what's your impression, based on what you've seen with battleye?
You put any form of process monitoring software on my PC and I'll disable it. End of story, no quarter given.Hello,
I fully understand that but I'd like to share some of my experience working on anti cheat measures in an open world game that I believe have a few things in common with ED, in particular reliance on peer to peer networking and giving a lot of authority to clients.
In the first installment of the franchise, we used what I'd call a "whack a mole" approach to anticheat.
We'd procure cheating tools that were sold for our games, figured out how they worked (most were standalone trainers built with cheateengine and I made a small tool to extract the .CENGINE file from them which I could then open in cheateengine. I could figure exactly which piece of code they were patching and in which way they changed it), and then figured how to prevent them from working anymore
We had an arsenal of tricks at our disposal, one of them was to wrap some values in such a way that they were crudely encrypted in memory, so that finding them with things like cheateengine wouldn't work. We did other things such as randomizing the location of pointers to singletons to try and defeat some tricks used to locate variables on the heap (that didn't have fixed addresses) by following pointers from static variables (which are at fixed addresses).
This approach was time consuming and not very effective. We'd spend days of work to analyze and block some cheats, it then took weeks for the patch to go live, and then only days again for cheaters to find new ways of cheating.
As you probably found out, just like we did, there isn't any way to prevent a process with sufficient privilege to read and write the memory of another process.
The only real way to block this is to proactively monitor other processes running on the computer to detect those getting a handle on your process. It's fraught with many pitfalls though, as many things have legitimate reasons to do so (drivers, overlays, antivirus software, etc), and cheating code could also be injected into such a legitimate process and work from there to avoid detection.
So, In the sequel of that game, we went for a completely different approach: we used a third party solution. We chose battlEye, and it works splendidly (It's certainly not the only viable solution, I'm not a BE sales rep). We have seemingly no cheating going on other than players exploiting bugs, which we can just fix.
Of course the downside is that these turnkey solutions are expensive. But if you are serious about cheating, you need to weight that cost against trying to develop anticheat solutions yourselves, especially considering that the whack a mole approach doesn't really work and that developing a solution similar to battlEye that monitors processes for suspicious activity towards ED, without creating problems for non cheaters, is really really hard.
More than likely, yes. However, in Solo, no one is affected by the fact that you're cheating. "Banned to Solo" means you're playing with yourself (no, not THAT way, dirty mind) so you no longer affect the BGS either.It just dawned on me, but if they’re banned to Solo, are they not still able to use the FSD cheats?...
I would assume any cheats would still work in Solo, and since you can still affect the BGS in solo, still get credit for first discoveries, etc... it doesn't seem like much of a punishment to me. You just can't annoy other CMDRs directly.It just dawned on me, but if they’re banned to Solo, are they not still able to use the FSD cheats?...
That monitors ED's processes.... you can't disable it without patching the code out (from my understanding when following the cheat forums). Which means if you are running ED without the watchdog check, you are using some kind of tool to patch out that check.... just like said trainer/cheat tool does.Watchdog is a 3rd party app.
Nope, in Solo you are still affecting the BGS, tagging and mapping systems that legit players can't reach, etc, etc.More than likely, yes. However, in Solo, no one is affected by the fact that you're cheating. "Banned to Solo" means you're playing with yourself (no, not THAT way, dirty mind) so you no longer affect the BGS either.