• [Plea] Allow us to cover outdoor deployables until you get hacks under control
    13 replies, posted
There's a guy (maybe several) on our server that uses jump hacks to get over all defenses and loot every single running quarry, pumpjack and furnace on our server. Over and over and over again. Near as I can tell, he makes the rounds through the server 3-4 times a day and has been doing it for weeks. People have quit because it's nearly impossible to mine or smelt. On our server (Facepunch Texas PVE), stone is pretty much end game because of how hard it is to get armored. I caught him in my compound once but there was nothing I could do but watch him fly out of sight. And since you have to be right in front of someone's face in order to see their name tag, I can't even report him. With the new importance of operational quarries and the rarity of HQM, this one guy has completely fucked over the end game for an entire server. Please shrink the no build zone around quarries and allow us to cover them until you get this nonsense under control.
I dislike "hackers" and cheaters as much as anyone else, but in a game like Rust they will never be "under control". As long as Rust is popular and has people playing, there are going to be people who feel the need to cheat. They can throw all the anti cheats they want, they eventually will get circumvented as most scripters don't just give up when VAC/EAC/etc eventually pick up on them. I might sound a bit pessimistic, maybe a bit asshole'ish, but what I say is fact as its the case with a majority of online games.
[QUOTE=SteakStyles;48476142]I dislike "hackers" and cheaters as much as anyone else, but in a game like Rust they will never be "under control". As long as Rust is popular and has people playing, there are going to be people who feel the need to cheat. They can throw all the anti cheats they want, they eventually will get circumvented as most scripters don't just give up when VAC/EAC/etc eventually pick up on them. I might sound a bit pessimistic, maybe a bit asshole'ish, but what I say is fact as its the case with a majority of online games.[/QUOTE] it's pretty much true due to how massively skill/grind based the game is
How hard can it be to design a game where the server says, "Yeah, we're not going to let you jump 1000 feet in the air"? I readily admit I know nothing about programming, but I've played shit tons of online games and setting something like that as an absolute impossibility seems plausible to me. While I agree that hacking will always be a thing, the point is that Rust is currently really really bad in this regard. This statement is not bitching or whining. It's just a statement. I understand Alpha, so this is something I understand is incomplete. When I say "under control", I don't mean "eradicated". I mean "playable". Currently, the hacking in Rust is out of control to the point where one person can hold hostage the progression of an entire server. This is not "normal" for an online game. I have no doubt that the anti-cheat systems will eventually get to the point where hackers are few and mostly unnoticeable. In the meantime, there are gameplay changes that can be made to mitigate their effect. I'm also open to any suggestions on how to handle this situation. I've thought about letting my quarry and pump go dry for a few days in hopes that he'll take me off his list. I've also thought about baiting him with an open door and just sitting there for hours to see if I can trap him inside and get his name. Neither of these solutions are fun, but they're all I've got.
The anti cheat does detect jumping too high, or running to fast, or flying. The problem is distinguishing a player from an admin. I know shit about shit about programming, but the only way I see possible of hackers circumventing the anti hack detectors is if they've tricked the scripts into thinking they are admins. Even if you rewrite the code, if admins still have those abilities, hackers will find a way to access them. That's my theory anyway.
[QUOTE=jumonjii;48476352]The anti cheat does detect jumping too high, or running to fast, or flying. The problem is distinguishing a player from an admin. I know shit about shit about programming, but the only way I see possible of hackers circumventing the anti hack detectors is if they've tricked the scripts into thinking they are admins. Even if you rewrite the code, if admins still have those abilities, hackers will find a way to access them. That's my theory anyway.[/QUOTE] if(player.IsAdmin()) DontBan(); I don't see why EAC can't call up server, ask it if player in question is admin or not and then act accordingly.
[QUOTE=AshFirecrest;48476235]How hard can it be to design a game where the server says, "Yeah, we're not going to let you jump 1000 feet in the air"? I readily admit I know nothing about programming, but I've played shit tons of online games and setting something like that as an absolute impossibility seems plausible to me. While I agree that hacking will always be a thing, the point is that Rust is currently really really bad in this regard. This statement is not bitching or whining. It's just a statement. I understand Alpha. When I say "under control", I don't mean "eradicated". I mean "playable". Currently, the hacking in Rust is out of control to the point where one person can hold hostage the progression of an entire server. This is not "normal" for an online game. I have no doubt that the anti-cheat systems will eventually get to the point where hackers are few and mostly unnoticeable. In the meantime, there are gameplay changes that can be made to mitigate their effect. I'm also open to any suggestions on how to handle this situation. I've thought about letting my quarry and pump go dry for a few days in hopes that he'll take me off his list. I've also thought about baiting him with an open door and just sitting there for hours to see if I can trap him inside and get his name. Neither of these solutions are fun, but they've all I've got.[/QUOTE] Cheating is a difficult thing to tackle because of a few things: - People will find ways around it. The server needs to rely on the data sent by the player and you can't trust that it is accurate - Doing loads of checks for different things every frame for every player on a 200 slot server is going to be a hit on performance - Also having too much handled by the server introduces a lot of issues caused by lag, as well as lower performance again. - False positives. What if it's a bug, exploit or lag spike? If the system is open to false positives for these kinds of things then there is reason to doubt any ban that goes through it. And ofc doing clientside checks is a game of cat and mouse as well because whatever you do someone will just detour/bypass it. Also there's the fact that the game is still heavily in development. There's no point in them focusing too hard on cheaters until the game is actually done, admins should be better at policing servers. You need to either add an admin on Steam and message them when you think he's on the move, or sit and wait for him to appear and get his name.
The ONLY method that I've seen that works to eliminate hackers over the last 20 years is to have server admins online. Get in the habit of playing on servers with their admins present.
[QUOTE=swill78;48477822]The ONLY method that I've seen that works to eliminate hackers over the last 20 years is to have server admins online. Get in the habit of playing on servers with their admins present.[/QUOTE] It helps if admins have effective tools as well, view inventory/fps sight/statistics
Would love to involve Admins on this issue, but it's an official server. That means no oversight ever.
Unfortunately, "official" is a synonym for "crap" when it comes to Rust servers. I know this is counter-intuitive, but...avoid "official" servers.
Official = test server. It's used for testing, which also includes testing cheaters and their hacks.
Why not call it a test server then?
[QUOTE=swill78;48481181]Why not call it a test server then?[/QUOTE] Why not call it Rust:EarlyAccess then?
Sorry, you need to Log In to post a reply to this thread.