Quick Question…
Could a exploiter hook a module and change settings / variables within this module?
I have seen gun-engine’s keep there gun-settings within a client accessible module script.
Things such as firerate,damage etc etc.
Could this be changed by exploiters?
Because I’m currently working on a gun-engine and want a clean method to easily be able to change or configure a gun and was thinking of loading firerate variables from a module script.
Example:
if values in objects, exploiter is able to change these values. but if local values in script like that screenshot and exploiters aren’t able to access plugins, its not able to change values. (i don’t know exploiters are able to access plugins sorry)
I was thinking of once they equip the weapon I load theses values from this module script, into the script called “Server”
located inside of the weapon (not on the server) this is how most engines load there settings. And im sure this is how stuff like inf-ammo exists before exploiters can change the values from the module-script
I am pretty sure that exploiters will eventually find their ways to change the value of the table. But will that affect your game? It depends on how you use that value though. Changes that happen in local never happens in server. However, exploiters may send a crafted table in case your function takes in a parameter as a table.
local function LoadGun(player, GunConfig)
— Load
end
In this case, without extra validation from server. If the server trusts everything inside the value sent from clients without second check it. Inf ammo could happen. That is what I think though. Maybe incorrect.
If you store it in a module, it makes their job easier as they dont need exploiter specific functions to change it. If the client relies on any of the values in the module then it will change for them.
i honestly don’t know what exactly.
but if ammo scripts are client side, maybe editable by global variables.
That is not the cause probably, that would make anyone has inf ammo though. So the problem comes directly from how you load it, not how the value is changed.
Well, I’m planning on loading raw-values I.E 0.1 for firerate into the script called “Server” notice this script is not on the server but is running from it, same with the module script.
And since the settings is what the server is going off of, and the settings can really be validated since I would need to precode all of the gun’s settings into the server-script which would void even making easily adjusted settings.
No ammo is handled on the server-script labeled “Server” and is replicated to the client using number-values.
BUT… the initial max-ammo and current ammo will be decided off of the module-script.
I.E if gun is equipped and the module script has max-ammo set to 9999 and current-ammo set to 9999 than that would be the max-ammo and current-ammo.
If it can be validated, you can kick players who may attempt in changing those configs.
Yes, it is possible for exploiters to change the settings or variables within a module script. If gun settings such as fire rate and damage are stored in a client-accessible module script, an exploiter could potentially change these values.
Here’s an example of how this could happen:
-- ModuleScript with gun settings
local GunSettings = {
FireRate = 0.5,
Damage = 10
}
return GunSettings
-- LocalScript that requires the ModuleScript
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local GunSettings = require(ReplicatedStorage:WaitForChild("GunSettings"))
-- An exploiter could change the values like this:
GunSettings.FireRate = 0.1
GunSettings.Damage = 100
To prevent this from happening, you could store these values on the server and use RemoteEvents or RemoteFunctions to communicate between the client and server.
Hard to validate once again this would require the server already knowing the weapons max-ammo…
which is the whole reason were loading it from a module script?
You can create a new Script inside ServerScriptService and put all tables as a reference. For server-side validation you can refer to this table to make sure that no changes have been made. Will that suit your game?
That’s actually really smart! I’ve never thought of that before!
Quick idea here, what if i keep a module script of gun settings, in server-storage and when the owner of the weapon equips the weapon it looks at the weapon name and try’s to find the table with that weapon name, than load from there.
I.E client can’t require a script from server-storage.
And the server-script can safely access the values
Example:
-- Server-Storage: Module
local GUN_LOADER = {
M4A1 = {
Ammo = 30,
MaxAmmo = 30,
FireRate = 0.1,
MaxFireRate = 0.2,
FireType = 1,
},
APG = {
Ammo = 6,
MaxAmmo = 6,
FireRate = 0.5,
MaxFireRate = 0.6,
FireType = 2,
},
}
return GUN_LOADER
As im typing this Jacky stole my idea…
than from “Server” inside the tool I request the table with all of its gun-settings,
Yes, that’s a good idea! Storing the gun settings in a module script within ServerStorage and accessing them from a server script is a safe way to prevent exploiters from changing the values. Since client scripts cannot access ServerStorage or require scripts from it, this method ensures that only the server has access to the gun settings.
Here’s an example of how you could implement this:
-- ServerScript
local ServerStorage = game:GetService("ServerStorage")
local GunSettings = require(ServerStorage:WaitForChild("GunSettings"))
local function onEquip(weaponName)
local weaponSettings = GunSettings[weaponName]
if weaponSettings then
-- Load weapon settings here
end
end
This way, when a player equips a weapon, the server script can look up the weapon name in the GunSettings module and load the appropriate settings.
I swear to god this man is ChatGPT…
Yep exactly haha. In the future, if you implement a customization system. You can create a new table for attachments only and let the server loop through all attachments in guns for extra stats.
Thanks Jacky,Scripted,Chess,ro1bro1x,savio for the help!
Have a good night/day.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.