I want to know if there exist some properties or information tied to classes, like .Locked, that could be removed when the game is compiled outside of Studio. Or, if Roblox has tried anything like this in the past.
I feel like this could improve replication performance, and I don’t know if many use .Locked on runtime outside of Studio testing
Likewise, all properties have a negligible memory footprint. In reflection they are only defined once per-class and come in two flavors
Bound: Properties which directly point to some field of data in a C++ class.
Get/Set: Properties backed by an internal getter and setter function pair.
Are some classes and members redundant/unnecessary to compile? Certainly, but when you’re covering the use cases of every game on the platform, you have to concede to some minimum baseline that covers what everyone needs. It’s not practical to continuously build and ship different builds of Roblox for different game use cases.
Locked in particular is a property that has existed for at least 17 years now, and I know for a fact that I reference it in code that runs outside of Roblox Studio. It’s not something you can just remove without breaking things.
Do you by any chance know how instances (and property changes) are replicated? If I’m understanding the task scheduler correctly…
the server goes through the replication send step, sending Instance information to clients
the client then goes through the replication receive step, waiting for the next render step
What I’m curious about is how frequent replication is. Like let’s say there’s a part that’s tweening every 1 second. Does the server only send “entire” instance data for the client to create that instance, but when it already exists, it only sends changed data (eg. whatever property is being tweened)? Are properties instantly replicated only when they change, or is there a fixed rate for the replication (is it 60Hz? 40Hz? 20Hz?).
This question is tricky because it depends on various internal factors.
Some properties are as simple as just:
They have an internal Get/Set implementation.
They raise the Changed event when calling the Set function of the value, if it is different.
As long as the property is flagged to allow replication, it will publish the change across the server->client boundary.
Bound properties are a different story. They can replicate, but usually do so through the reflection of some internal state, or an update from something else happening internally. Maybe even a custom replicator entirely. They don’t emit Changed events.
As for tweening something on the server, that will flood the network traffic with changes to the CFrame property because it’s a get/set to the underlying physics primitive’s transform, so it fires the Changed event.