Directly Linked Properties, an idea that could save us a lot of time!

(DLP) Directly Linked Properties

Hello, fellow Robloxians! I’ve been thinking about an idea for a while now, I call it Directly Linked Properties.

What’s a DLP?

A DLP is/would be a property that is linked to another property of the same type, for example, TextLabelA.Text is linked with TextLabelB.Text, Any change to TextLabelA.Text would replicate to TextLabelB.Text and vice versa.

Why do we need this…?

A: It would be way easier to make cool text effects like this one, without having to make a script to change the text of both.
B: Lets say you have a message on a wall that is cloned in different places, instead of having to do…

for i,v in pairs(workspace.Messages:GetChildren()) do
   v.Label.Text = "Server Message!"  

You could just DLP all of the messages and change one in the script and have it apply to all of them!
C: Lets say you’ve created a intermission system, you have a value in workspace called “Shout”, let’s say you initialize it like this…

   script.Parent.Label.Text = workspace.Shout.Value

Instead of doing that, you could just set DLP to the label.Text inside StarterGui and when its cloned to PlayerGui, it maintains its DLP


  1. You cant link a number and a string, it can only be bool to bool, string to string, number to number, etc.
  2. It might be a pain to DLP multiple objects

Here is an idea of what I think it should look like:
When you select a linkable property, a link icon will pop up, once you click it, it’ll have the same effect as when you edit the parent property of an object or select an attachment for a rope constraint.

Bugs we may run into

  1. When an instance using a DLP is removed, It might go crazy so make sure to add an auto disconnect for that.

Multi-Mode: Uses a mesh type topology, any change to any object in the DLP group will apply changes to them all
Single-Mode: A one-way connection, if A is changed, B will change, but not vice versa


A concept similar to Zindexing or collisionId. Apon clicking the Link button, a drop-down menu will show up with an option to create a new group, or add the current object to an existing one.


Lua Implimentation
:LinkProperty(Property, GroupId)

I’ll be updating this thread often.


This very quickly becomes harder than simply hooking up to a changed event.

Example: I want a money indicator. "DLP"s would now need to have prefix settings to display “$1000” instead of just “1000” in my textlabel.Text. What if I wanted text afterwards? It would only work for the simplest of use cases at which point you might as well write the code since it’s ~3 lines?

I’m just not seeing the problem that this solves. It seems like a separate system to the Lua scripting language which I don’t like the idea of.


Huh? Not really? How is an API for properties to clone to each other suggesting a new scripting language?

1 Like

Misread the first line. Will correct my post!

1 Like

There’s got to be some way to do it. Considering that you can do script.Parent.Label.Text = "Hello" using that same idea you should be able to mass apply it in the way that I’m suggesting.

But why? It seems like you want to mess with dropdown menus instead of writing code, when the code is easier.

Also, changing syntax

whatevervalue.Value = anothervalue.Value

to link them would be a change of existing behavior and would also make no sense when you’re trying to access a property.

I see your point and I do agree that it’s not the cleanest method and needs quite a bit of polishing. The main idea behind this is just to make making 2 things have the same value more user-friendly to people who don’t know how to code properly or are just trying to quickly put something together without the hassle of going in and connecting it with code.

Most of the stuff I posted is directed towards a more advanced and complex idea. All I really want is to be able to link 2 things really quick and be all set. It just feels like I’m wasting a bunch of space in my neat and clean script, it just bugs me because adding a connect for something so small makes it feel so dirty.

1 Like

Are there other use cases apart from UI where this is useful? I think the actual use case you have here might be that you can’t manipulate text in the way you want without using multiple text labels.

1 Like

This can’t really happen, and I think the majority are missing a very important point: security.

Something about letting the engine handle properties for you just sounds very sticky and dangerous. How would you handle say, if someone were to link workspace.BoolValue.Value to ServerScriptService.LoadStringEnabled? Or to workspace.FilteringEnabled? Maybe to a RobloxLocked object?
You’d likely need to just start checking from which threads the changes are coming from and if they’re possible, and if they’re not, what error will you throw? There’s no script to blame, and if it won’t throw and the changes go through, what will this do to the current script sandbox in place?

You could easily write an easy-to-use API for this, though?

I was bored:

Test / showoff code
local DLP = require(script.Parent)

-- Single-mode

local con
local A ="StringValue") A.Name = "A"
local B ="StringValue") A.Name = "B"

A.Value = "Test 1"
con = DLP:LinkValue(A,B) -- or DLP:Link("Value",A,B)
print(B.Value) --> Test 1

A.Value = "Test 2"
print(B.Value) --> Test 2

con() -- disconnect
A.Value = "Should still be Test 2"
print(B.Value) --> Test 2

con = DLP:Link("Name",A,B,string.upper) -- or DLP:LinkName(A,...)
A.Name = "Am I shouting?"
print(B) --> AM I SHOUTING?


-- Multi-mode

local C ="IntValue")
local D ="IntValue")
local E ="IntValue")

con = DLP:GroupValue({C,D,E},function(v) return v + 1 end)
C.Value = 1
print(C.Value,D.Value,E.Value) --> 1, 2, 2
E.Value = 5
print(C.Value,D.Value,E.Value) --> 6, 6, 5

con = DLP:GroupValue({C,D,E},function(v) return v/2 end,true)
E.Value = 8
print(C.Value,D.Value,E.Value) --> 4, 4, 4
DLP Documentation
	prop: The property to link (e.g. "Text")
	from: The object to listen to
	to: The object that'll listen
	func: [OPTIONAL] Value transformer
		Arguments when called: newValue,prop,from,to
		(e.g. function(val) return val * 5 end)
		What it returns will what will be written to 'to'
	Alias for DLP:Link("PROPERTY",from,to,func)
	prop: The property to link (e.g. "Text")
	objects: Table (array) with the objects to group
	func: [OPTIONAL] Value transformer
		Arguments when called: newValue,prop,from
			Notice: There's no 'to' argument as in DLP:Link()
				This function only gets called once for all objects
		(e.g. function(val) return val * 5 end)
		What it returns will what will be written to 'to'
	editSelf: [OPTIONAL] Value transformer should affect the invoker
		e.g. function(val) return -val end
			Objects A,B,C and we set A's property to -5
			With editSelf true: A=-5,B=5,C=5
			With editSelf false: A=5,B=5,C=5
	Alias for DLP:Group("PROPERTY",objects,func,editSelf)


EDIT: Added multi-mode (Group) and some fancy shenanigans


This and the ability to lock properties from being changed aswell. Eg you could lock the Y axis on a parts position to prevent it from moving up/down

Constraints or body-mover objects are better solutions for something like that. They are also more versatile than just locking a part onto a plane.

1 Like

Are they though? For that to work you’d have to create a new BodyPosition instance then we all that up where locking the property is just 1 click. The same goes for rotation.

There aren’t too many use cases but it’s just a feature that’s be nice to have. Both Blender and Unity have it so why not Roblox?

Yes, the best practice for manipulating physics of parts (locking them to 2 axes is manipulation of physics) is through those objects. I think having a component listed in explorer under the object is way more intuitive than “locking” properties in the property window.

Yeah, it might be nice to have for a couple specific cases, but typically you have to argue why a feature would be a good addition, not that “it wouldn’t hurt to have it”. A good way to think about this is that you weigh the reasons pro/contra a feature request in terms of points, and you have to start out with -100 points instead of 0 points, and work your way back up to 0 by providing all the use cases you can. We don’t want to suggest features that just introduce clutter/bloat into the API, especially if there is another method already in place that is much more intuitive to use (with only maybe a grain more effort to do so).

1 Like

Starting with security, by default some values are locked by ROBLOX, like
you cant change FE to false in the command line, I see no reason why this
would allow you to edit locked values.

Just because there is no script to blame doesn’t mean it cant throw an
error, it’s like trying to set an object’s parent to itself in studio
manually by dragging it into itself, throws an error but not from a script.

The error would likely look something like this…

Unable to apply value to Workspace.part.label.text

If its multi-mode it’d throw an error and skip it.

1 Like

That’s Studio, which can make a popup, and identifying errors is a must when there’s something that needs fixing.

Moreover, you can’t just assume that you won’t be able to do these different context things. I assume this data will need to embed with the place file somewhere in the XML if you want it to work by clicking some buttons in Studio, so it’d be just as easy to edit the XML to get this result, effectively bypassing the filter in place for it.

If this is the case, wouldn’t that the same with everything then? If I wanted to forcibly allow myself change the parent of workspace to ServerScriptService then I’d just have to go into the XML file and enable it.

See? doesn’t make much sense, I doubt that studio would have that little security where you could change a filter by adjusting an XML file.

Also, I think along with the pop-up, it outputs a small one-line message. I could be wrong though.
It cant be that hard to add a failsafe to an idea like this one. if they made error outputs like this, I’m sure they could do the same with this idea no problem

In that image there is no script to blame for their failure, its just an error.

You could also do this to create effects with bricks like this one…

You could even add a rotation effect too.

Those “errors” are different; they’re assets that failed to load or couldn’t. If I started to change BoolValue.Value a bunch of times a second and my output started flooding with errors that weren’t stopping the script creating them I’d be pretty annoyed too.

And you got the XML idea completely wrong; yes, changing workspace.Parent or w/e through XML is a thing, but it’s nothing compared to changing actual properties of RobloxLocked objects and have it show ingame.

This doesn’t seem like a secure idea because of the fact it’d affect runtime itself, as opposed to something static which couldn’t mess with gameplay.

I certainly don’t want something like this toggled mid-game.