Consider an NPC. I want server scripts to be able to specify the NPC’s displayed name. This is immediately very clumsy and there’s no clearly good way to do this.
Option 1 - Use a StringValue
I can use a StringValue to indicate the character’s name. This is problematic because client scripts may set this value and create unexpected states. Bugs appear without a clear cause and I get a text message from someone on my team asking me to cut dinner short so that I can find out which of the 92 localscripts is setting this value.
Option 2 - Make a custom network layer
I can recreate Roblox’s network layer from scratch for this NPC’s name. I can set up two BindableFunctions for getting and setting the value, a BindableEvent for when it changes, and a RemoteEvent for communicating changes to the client when the change happens. I should take care to replicate the character’s name to players as they join a game in progress without indicating in the code that the value changed. I lose parallel execution here but I can bring it back by choosing memory over execution time and creating a modulescript for each NPC instead of using bindables. At this point I need to reimplement Roblox’s signal API so that I can inform other scripts when things change. Once this is done I can use the API by requiring the module. No one else on my team can read or understand any of this code, but that’s okay because I’m spending an entire day on one property accessor so this is never shipping anyway.
Conclusion
There needs to be a step between “use a StringValue” and “reimplement the network layer”. Developers need to be able to customize instance access restrictions so that they don’t have to pick between two terrible options for every value replication their game does. Specifically,
At the “all instances of this class”, the “instance and descendants” level, the “per-instance” level, or the “per-property” level…
Restrict all access, or restrict only writes to…
“Any scripts”, “These scripts”, or “No scripts” …
on the server, or on the client, or on either
For example: “All ObjectValues under workspace.Character, restrict writing to only server scripts under ServerScriptService.CharacterManager”
And this needs to be a studio-level feature, not something that can be changed on the fly with lua.
The problem I perceive here is the lack of proper project etiquette. An object’s state should not have to be modified by so many different actors that it becomes difficult to manage. If a centralized module is used to compile all this modification, such as a wrapper of some sort, one can quickly determine what is causing the problem by using cases and retrieving the stack trace to get to the root of the problem.
The explanation of the problem was not clear, so please correct anything I missed or was wrong about.
Set the NPC’s Humanoid.DisplayName to the name you’d like to display. Alternatively, you can set the name of the NPC’s model.
Don’t blame the client scripts, blame the person writing them.
Roblox isn’t responsible for the bugs you create as a direct result of your inability to properly structure your own codebase. Throwing your fist up at the universe when events unfold in ways contrary to your expectations isn’t going to get you anywhere.
The corners you cut today will be hills you climb tomorrow.
Unless you guys aren’t the ones writing them, then just… not do that? Having client-sided code change a value sort of implies that there was an intent for them to change it in the first place, the intent of someone who wrote the code that is in your game that is breaking it.
This sounds more like a problem with your codebase though? It’s like you’re saying “Yeah, I have a tonLocalScripts that might occasionally set a value, breaking the game, but it’s the engine’s fault for letting them do that!”
It’s unreasonable to expect every programmer on your project to understand every expected access point of every API. Rather than letting them think their code works until they run into a bug, and then have them spend time tracking down the bug, and then have them spend time figuring out how to correctly access the API, wouldn’t it be much easier to immediately throw an error that tells you what you did wrong and what you should do instead?