I’m curious as to why you’ve decided that the hierarchical name of the instance must be passed rather than a reference to the instance itself (i.e. workspace.Baseplate instead of "workspace.Baseplate").
There are some issues with using hierarchical names to index instances in the data model:
These names are not necessarily unique; instance references are always unique. Suppose for example that there exist two instances in Workspace that are both named Baseplate: the hierarchical names of these instances will be identical. Since the same name can map to multiple instances, it’s a lot more difficult than it should be to determine which particular instance we’re actually interested in.
Hierarchical names may change; instance references may never change. Changing the properties .Parent or .Name on an instance will alter its hierarchical name. What this means practically is that the full hierarchical name has to be passed and resolved every time you want to reference an instance, which is a lot more time spent processing than is necessary.
In terms of data size, hierarchical names are big; instance references are tiny. Each additional character in a string occupies 1 byte, while an instance reference is a single 4-byte integer. This usually isn’t something to be concerned about since strings are interned, but one place where it is important is when sending them over remotes. In this case, each string will occupy 5 + string.len(str) bytes (assuming it isn’t already cached) in the next network message, while an instance reference will only require 5 bytes.
Essentially, though - I’m creating a website that provides tools for protecting the source of scripts.
I found that one of the best ways to do this is for code to never be sent to the game in the first place. Let me explain - your products code runs in a sandboxed Lua environment on one of our servers. Then, when the script needs to interact with the game, it either sends a predefined instruction or obfuscated bytecode which is then ran with an interpreter made for it.
The reason I don’t just use a reference to the instance itself is because I can’t. Code is running on our server, not the game. So when you need to get a part you have to tell the game to return data about it.
In that case, I would recommend JSON as a way to pass the hierarchy instead of the signature as a string. Both will still work though if you prefer that route. Also, you will need some way to verify if there is more than one object with the same name, or just avoid the situation entirely. That’s a pretty neat idea, to keep your code running externally, though I wonder how much latency would affect it’s usage.
What’s the point in this? Exploiters can just fetch the bytecode, as for code to run on the client, they’re always given bytecode (even if you run it with an interpreter). They can still fetch source code.
Sure this could prevent client sided place stealing as the client code will not be there but as soon as it runs in the actual game the exploiter can easily construct source code from all the ran bytecode.
I’m not sure if we’re both talking about the same thing.
My assumption is that what they meant is that the logic is being offloaded to an http server? Please correct me if I’m wrong. What it seems to me is that the intention is not to prevent client side decompiling etc, but to be able to sell scripts to developers without them being leaked. I might be confusing this with a similar thread though, since I remember another thread talking about this.
Exploiters can’t simply “fetch the bytecode”. The bytecode is heavily obfuscated so that it will only work when being ran by the interpreter.
Because of this, trying to use a decompiler to view the interpreted script will error because it’s not normal Roblox bytecode.
To accomplish this, I am buying part of the Ironbrew VM. Ironbrew is one of the best Lua obfuscators and has never been crack. It has a $420 deobfuscation bounty.
When I first started the project, the main goal was to replace closed source modules. As someone would depended on them for my income on the platform, they were really important for me. However, I have also looked into other potential usages and, yes, game security is one. This project is a website that anyone can use, so the usages will vary greatly.
As for latency, it’s only an issue when you don’t design with it in mind. For example, to remove the latency issue all together you could simply not do logic on our server and do it on the game instead. Here’s an example,
local functions = marketplace.functions()
functions.game.playerAdded(function(player)
functions.executeClientCode(player,
“print(‘Hello world!’)”
)
end)
You could put all of your client code there when they join and have it execute on Roblox normally without any latency.