You can always move the local version of the character first and wait for the server’s response afterwards, if the server character is in a different place (which is going to happen very little most of the time) then move the local character to the correct position.
That is how many games outside of Roblox do it
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Input_prediction
I have been working on large custom 2D gui pixel based games for about a year now and I all can say is that there isnt much you can do.
One of my 2D games is pretty large and consists of a single local script with 2000+ lines of code, and obviously you wouldn’t want some random exploiter to take your whole game.
Even though your games are already technically protected from being stolen and claimed as someones else, it sometimes wont be enough.
So what I would do is ensure the game cant be stolen from someone who can’t script (or is not experienced)
Some methods you can use are;
That’s what rubberbanding is. I’m fully aware that this is common practice in games where the networking is written by the developers, but Roblox is a special case because the developers generally have less experience with networking concepts and development in general, and the majority of our needs are handled by the platform. In creating a 2D engine on Roblox you will need to create your own network system, but I really don’t think it matters enough in this scenario to be the deciding factor. Client-authoritative systems are more intuitive and have their own advantages, and It wouldn’t take that much work to change it later.
Nope, not possible. However, Roblox does automatically obfuscate your code and better protects it, making it harder for exploiters to edit it.
Sorry for the late response, I was researching this topic and I think the best thing you could do is
obfuscate. It may not be the most effective if you’re trying to write code and should only be done after the fact.
I hope this helps.
Many exploits can get around the obfuscation, however, you yourself can use more secure means of obfuscation.
There are plenty of methods, there’s even a basic tutorial on how to obfuscate (Obfuscating Lua · GitHub).
Similarly to a fork bomb, using string.dump() can make your code really hard to read.
Hope this helped!
what is string.dump() and you cant change script source i think
what year do you live in
There are a few ways to prevent exploiters from reading your local scripts. Here are a few options you can try:
Here is an example of how you might use these techniques in a script.
-- Obfuscation:
local secretNumber = math.random(1, 100)
local function getSecretNumber()
return secretNumber
end
-- Encryption example:
local encryptedCode = "f89a8f9a8f9a8f9a"
local function decrypt(key)
-- Decrypt the code using the key
end
-- Access control example:
local approvedPlayers = {
["player1"] = true,
["player2"] = true,
["player3"] = true
}
local function checkIfPlayerIsApproved(player)
if approvedPlayers[player.Name] then
return true
end
return false
end
game.Players.PlayerAdded:Connect(function(player)
if checkIfPlayerIsApproved(player) then
-- Allow player to access game features
else
-- Block player from accessing game features
end
end)
Encrypting your code can help to prevent exploiters from reading it, as it makes the code unreadable without a key. However, it is important to keep in mind that encryption is not foolproof and can potentially be hacked.
Here is an example of how you might use encryption in a script:
local function decrypt(key)
-- Decrypt the code using the key
end
local function runEncryptedCode()
local decryptedCode = decrypt(encryptedCode, key)
run(decryptedCode)
end
In this example, the encryptedCode variable contains the encrypted version of your code. The decrypt function takes the encrypted code and a key as input, and returns the decrypted code. The runEncryptedCode function calls the decrypt function to get the decrypted code, and then runs it using the run function.
To use this code, you would need to provide the key that is used to decrypt the code. This key could be stored in a separate file or passed in as a command-line argument, for example.
Access controls allow you to limit who can access certain parts of your game or certain functions in your code. For example, you can set up a whitelist of approved players who are allowed to access certain features of your game.
Here is an example of how you might use access controls in a script.
local approvedPlayers = {
["player1"] = true,
["player2"] = true,
["player3"] = true
}
local function checkIfPlayerIsApproved(player)
if approvedPlayers[player.Name] then
return true
end
return false
end
game.Players.PlayerAdded:Connect(function(player)
if checkIfPlayerIsApproved(player) then
-- Allow player to access game features
else
-- Block player from accessing game features
end
end)
In this example, the approvedPlayers table contains a list of players who are approved to access certain game features. The checkIfPlayerIsApproved function takes a player as input and returns true if the player is on the approved list, and false otherwise.
The PlayerAdded event is triggered whenever a new player joins the game. The event handler function checks if the player is approved using the checkIfPlayerIsApproved function. If the player is approved, they are allowed to access certain game features. If the player is not approved, they are blocked from accessing these features.
Here let me show you an alternative. I’m used to Luajit, not Luau I apologize.
string.dump() doesn’t work because I believe it was depreciated. (Look here for more info).
You can use an alternative such as string.sub() or string.gmatch(), they work just as well.
The name of variables are not saved in compiled Luau bytecode, exploits already do not have access to variable names.
What, are you going to use loadstring() on the client too? Exploits can very easily look at the localscript’s memory for the decryption key, or just hook the decryption function to look at what data it is returning.
All of your suggestions won’t prevent a localscript from being read, unless you want to restrict features to developers or something.
⚠️ Warning ⚠️
I’m only trying to help
This code was made by AI
You are correct that the names of variables are not saved in compiled Luau bytecode, so exploiters will not be able to see the names of your variables. However, obfuscating your code by renaming your variables can still make it more difficult for exploiters to understand what your code is doing.
For example, consider the following code:
local secretNumber = math.random(1, 100)
local function getSecretNumber()
return secretNumber
end
print(getSecretNumber())
Even though the name of the secretNumber variable is not saved in the compiled bytecode, an exploiter could still figure out what the code does by reading the function names and the function bodies.
Now consider the following code:
local a = math.random(1, 100)
local function b()
return a
end
print(b())
In this version of the code, the names of the variables have been changed to single letters. This makes the code more difficult to read and understand, as it is not immediately clear what each variable represents. An exploiter would have to spend more time and effort trying to understand what the code is doing, which can make it harder for them to find vulnerabilities.
It is important to note that obfuscation is not a foolproof method for preventing exploits, as determined exploiters may still be able to reverse engineer your code. However, it can make it more difficult for them to do so and may deter some exploiters from attempting to exploit your game.
You are correct that the methods I suggested will not completely prevent a local script from being read. While obfuscation, encryption, and access controls can make it more difficult for exploiters to read and understand your code, they may not be foolproof and determined exploiters may still be able to reverse engineer your code or find ways to access it.
One option you could consider is restricting certain features to developers or trusted users. For example, you could set up a system where only developers or trusted users are allowed to access certain parts of your game or certain functions in your code. This can help to prevent exploiters from accessing these features, as they are not likely to have developer or trusted user status.
It is also a good idea to keep your code as simple and secure as possible. This can help to reduce the number of vulnerabilities in your code and make it less likely that exploiters will be able to find and exploit them. You should also stay up to date with the latest security best practices and make sure to apply them to your code.
Finally, you should also monitor your game for suspicious activity and take steps to ban or otherwise prevent exploiters from accessing your game. This can help to protect your game and your players from exploits.
Neat contradiction. What’s the point of renaming your variables to single letters (and making it harder to edit for yourself) if they aren’t even saved in the bytecode, making it completely useless to do? All the exploiter will always see is simply something like “local_1” for the variable names, a sort of “automatic” obfuscation if I may.
⚠️ Warning ⚠️
I’m only trying to help
This code was made by AI
You are correct that the names of variables are not saved in compiled bytecode, and an exploiter will not be able to see the original names of your variables. However, there are still a few reasons why you might choose to rename your variables:
Overall, while renaming your variables is not a foolproof method for preventing exploits, it can be a useful tool for making your code more difficult to understand and for improving its readability and maintainability.
I mean this in the sincerest way possible: if you use AI to try and help people, you aren’t helping them. It looks extremely bad on your part, especially in discussions like these, and putting;
Won’t make you look any better. It just makes you look ignorant because, well, the AI has written the exact same thing, and you still decided to post it here. You aren’t helping anyone, by knowingly or unknowingly spreading misinformation. Please, delete your replies.
Stop using ChatGPT, and start using your brain.
Thanks, your posts are always such a help to everyone, we all love you.Thanks, your posts are always such a help to everyone, we all love you.
Thanks, your posts are always such a help to everyone, we all love you.
There are ways to break decompilers, but honestly, I think they are all a waste of your time.
Look, decompilers arent a 1:1 recreation of your code. Anyone trying to make a game based on a decompiled localscript is going to have a very difficult time because every decompiler has errors.
SV2 gets operators confused all the time so it swaps “and” and “or” instructions. SV3 renders your code extremely unreadable to any exploiter who would want to steal your game.
You could obfuscate your code, but users can grab the instructions for the onfuscator from getgc and manually deobfuscate the entire thing.
To make it easier for yourself and to spare your sanity, trying to prevent decompilation is not going to be your thing.
It would be much easier for you to issue DMCA takedowns on any games stealing your assets, this is what BIGGames does whenever someone uploads the reverse-engineered copy of psx.
If you want to hide your scripts and make it much harder for potential exploiters, put this chunk of code on top of any localscript you want to protect.
script.Parent = nil
script = Instance.new("LocalScript")
This hides your script from saveinstance exploits, and it hides it from functions that try to bypass scripts hiding themselves in nil.
It’s not much, but it will put a layer of protection over your code if that is what you want.
Local scripts are always executed by a client, so client can read them.
It’s not a good idea to have a local script that does a lot of work. You will have problems with syncing.