Well actually with this particular script they couldn’t, that would break the game.
1 Like
It actually is the problem. You aren’t supposed to handle cruical stuff such as ammo on the client, never ever at all ever. EVER.
You are supposed to store the ammo count on the server, decrement it on every shoot call, increment it on reload call, and apply sanity checks to the reload remote, such as debounce, animation time, ammo left if that’s a thing in your game.
7 Likes
It wouldn’t break the game if they just reran it, it would work just like normal, and most exploit software is advanced enough to allow this behavior anyways.
2 Likes
It’s interesting that you’re just assuming that, despite the fact you haven’t even looked at the full 7000 lines and everything the script initializes, modifies, and handles.
1 Like
To re-run this script, without dying first and manually resetting everything, would definitely break a great many things for the client.
1 Like
I’m not entirely assuming it, I know it’s possible as I know how most exploit software works due to several really amazing DevForum articles that provide tons of insight on what exploits can allow the client to do.
Here is a good article that might provide insight on what the client can do with exploit software:
6 Likes
Also most reload animations are less than 2.5 seconds. A user for tactical reasons can cancel a reload animation at anytime so they can shoot, but this won’t give them ammo.
Say for example a user is on 150 ping, which isn’t far-fetched given how roblox networking is.
User tells the server they want to reload
Server tells them it’s ok go ahead
User runs the animation, server is waiting the time of the animation
– Uh oh user canceled the animation! – quick tell the server in time
Server gives ammo anyways because by the time the cancel request comes through it’s past the original animation time.
Now maybe I can add an additional check for that too, but now either ammo count is really delayed in updating, or it’s constantly giving and taking away ammo in a noticeable fashion.
3 Likes
honestly if a remote event can be fired with input then it shouldn’t be problem to allow the player to fire it manually using code. (infact it would be easier for the player to just use the input you provided for them). If they DO exploit it somehow then the problem is your remote event debounces… you need to make sure the remote event can only be fired after an X amount of time or in special circumstances, and then some extra checks AFTER they fire it to verify. (based on position, distance, and other optional debounces)
1 Like
It is actually impossible to fix via banning certain operating systems, as the same with the browser useragent string can be spoofed, in a sense things like VirtualMachines could be spoofed to look completely different, even to the game client.
It’s mainly down to protecting all areas of your game, even ReplicatedStorage and other defaultly replicated values, to ensure that the Clientside areas that are covered by FilteringEnabled aren’t used as a guide to further advance exploits.
Again, the simple answer;
Don’t just focus on clientside security;
Implement client-server checks, and even;
Serverside only checks.
1 Like
i’d love to see you spoof it on xbox or ps4, but other then that your 100% right.
2 Likes
If you think 2 seconds delay behind the server is common on roblox then you’re mistaken.
If the animation is at like 2.4 and the edge case of them cancelling it after it has already played does happen, then simply do nothing since the ammo has been loaded in.
Most fps games on roblox use similar practices and are absolutely fine. Most importantly, they all store the ammo on the server, and apply proper checks to the reload and shoot remote.
I won’t keep on trying to change your mind about putting the ammo on the server since I’ve noticed you’re very stubborn, but in that case please don’t complain about exploiters.
4 Likes
Well, I was referring to the modularity of OS platforms like Linux, or Windows, which can run other environments inside, or be modified to report different things.
Either way, thanks for the like! 
2 Likes
so then banning PCs could technically fix the issue, but i wouldn’t recommend that as most roblox players use PC, its best to just secure everything like you said.
2 Likes
Indeed, banning PCs would harm the marketing and outreach of the game more than mobile, or console, as from what I know, PC is the only exploitable platform with regards to the client.
2 Likes
So now your average run of the mill script kiddies are running around hacking games using getsenv.
It’s only a matter of time before smarter exploiters start modifying functions that fire events and the like.
No, they aren’t. They’ve been able to do this forever.
IIRC you can put script = nil at the top of your script which seems to break getsenv on some exploits, but people can still just dig through gc and getfenv.
How are developers supposed to defend against something like this?
Don’t have insecure functions on the client? If I fire to the server 20 times to shoot someone, just have the server check if I actually have enough ammo. You can get more sophisticated and there does have to be some degree of trust with the client, but patching things like infinite ammo is easy.
5 Likes
Well the issue with roblox networking is based around the server hosting. Obviously, until your game has enough players to have servers in a vast amount of regions, there’s going to be players riding above 300 ping all the time. Any kind of integral system like ammo usage that requires verification from the server is going to suffer from delays and misfires constantly because of the natural desync. If someone in an FPS game is experiencing issues like that, they will quit, and likely never come back. Thus, game never gets popular, the issue never gets resolved.
I have plenty of security and sanity checks on the server to stop a great many things from happening, but I’m not going to sacrifice performance and precious timing (which is more important in an FPS than any other genre) just so the server can handle something like ammo, that can’t possibly work well on a game that doesn’t already have thousands of active players.
1 Like
My general take on these things is: If phantom forces can’t do it; neither can you.
4 Likes
Roblox servers aren’t this bad. That’s really my only take on that topic.
But @Meta_data and @Amiaa16 said it perfectly regarding your issues with exploiters and I don’t know what else needs to be said.
3 Likes
Well I did already patch it, alot of people in this thread are still focused on the ammo problem, but bottom line is any exploit now that would give you infinite ammo would have massive drawbacks like client errors and movement speed (ammo weight affects movement speed in my game).
The biggest issue in my opinion was the no-recoil. There is no server code possible that can force a client’s camera to move, without telling the client to do it themselves, i.e easily exploitable.
1 Like
That’s true, so that’s just something impossible to patch.
Along with other things like ESP, which don’t even use Lua at all.
It’s just something you have to live with.
1 Like