I think this would be better to be called “Copy Properties.”
I support either way.
I think this would be better to be called “Copy Properties.”
I support either way.
I’ll adjust that in the post! Thank you.
This would be extremely useful. I would even say the ability to copy similar properties from different types of objects would be neat as well.
Please include use cases. You have described what you want to do, but not why. Why are you copying lighting settings between places so often? Why do you want to copy properties instead of duplicating the object when possible?
Here’s my use cases:
Making UI. To make everything look and feel right, I constantly have to adjust any items to look like the others. This gets old really fast, especially when I have to insert a new element and tediously change each property of it to match the others.
Copying lighting. I like to take screenshots for my games in separate places and need the lighting to match up. Especially with FIB, it’s very annoying having to copy each lighting setting manually back and forth.
Building. I was making a map the other day with tons of windows that were all specific colors, materials, and transparencies. Whenever I could not just copy/paste and needed to make a new part, I had to manually set all of its properties. Gets old very fast.
Is there any reason you cannot use the tags feature and a specialized plugin or the command bar for the first and second? I know that’s slightly more work but it seems easy enough to me. Easier than Roblox adding this anyways.
Never touched the tags feature. I don’t see how it would help me.
Using the command bar is wayyyy more painful than manually copying/pasting in this case. So much typing and no formatting…shutters.
Even if I use a plugin, I’d still have to manually set each property and every time Roblox adds one I’d have to update the plugin
The tags feature is really useful because you can just tag an Instance and then grab all of them at a later date using the CollectionService. You could have it copy the properties of a selected object to all of the other objects that shared the same tag.
Or you could even just use currently selected instances and copy to them. Would be up to you.
And as for manually updating the properties… You could use an API dump json from online (I recommend this one that Clonetrooper maintains on github) to manually generate a list of properties for every class. It would be relatively quick and painless.
Tags are non-optimal for copying appearance because it can’t be previewed in Edit mode (it is only set in-game at runtime).
Tags can do that? If so then this feature request would be almost redundant.
That being said, you can grab those properties, but I don’t know how you’d be able to index them.
EDIT: Nvm tags are dead to me if they only work while the game is running
I did not know that! Darn!
For the sake of answering your question though @Intended_Pun, you can index Instances like any other Lua data type. So game[“Name”] is the same as game.Name.
You could probably still use Selection for this what with PluginActions being a thing but Tags not behaving like that puts a damper on my idea. That sucks.
@Intended_Pun @Dekkonot Tags work in edit mode but they won’t automatically update the appearance of the object. You have to run a script to iterate through all of the tagged objects and update their appearance manually. Unless you’re running a plugin that looks for that tag and modifies the part (not scalable to generic use), there’s no way to run a script to do this in Edit mode.
Ah. Yes that’s the assumption I was operating under. My thought wasn’t that they would do it automatically, just that it would be an easy way to ‘tag’ everything that needed to have the same set of properties. Upon further reflection this is a bad idea, or course, but such is the way of it.
Regardless I can see a use for this feature because even though it’s doable using Selection and/or tags, it’s not going to be efficient and it would be easier to have it built-in. All three of Intended_Pun’s use cases are valid to me and I would probably use this for basically that were it added.
The proposed feature is self explanatory and there are endless uses. To answer your question though, if I want to apply a material, color or any appearance change to other items in the game I’d rather copy it once instead of changing those attributes several times separately. I already duplicate items in foresight but when they need to be changed, this feature will help with that. The lighting example was just what sparked this idea.
Yes, I could make 99 baseplates and manually copy over the configurations of another game onto these 99 baseplates, so that I have 100 files with the exact same content. Endless uses for the feature perhaps, but most are not particularly worth implementing the feature for. This is why you write down the significant ones that you actually need solved.
Always be specific, no exceptions. Don’t assume something is self-explanatory: more often than not it isn’t, or there may be a better feature they could implement to solve your use cases, but they don’t know unless you write about them (rather than the specific solution that may be a worse way to solve your use cases).
I would personally have many uses for this.
When working with UI, there are a lot of UI instances that share common properties such as background / border color and transparency. I often want to carry these common properties between different instance types so my UI is visually consistent.
In some cases, copy and pasting instances with the properties I want either isn’t easy, or just doesn’t work:
Being able to copy and paste properties between instances would significantly improve my workflow in these situations.
When starting up a new place, I sometimes want to carry Lighting settings over from another place. In fact, I have a small library of rbxl files with nothing but Lighting settings on an empty baseplate simply so I can quickly add attractive lighting settings I’ve already designed to a new project.
To do this, since I cannot copy the Lighting service between places, I need to manually fill in each property of Lighting by hand while looking between two different Studio windows, which is very tedious.
In some rare occasions while debugging my games I need to move subsystems out into isolated baseplates. My code often depends on specific service settings, and since I cannot copy and paste most services, I need to carefully set properties on Workspace, Chat, SoundService, ServerScriptService, Players, etc, so my code runs the same way it does in the actual place. It would be much faster if I could copy the properties of key services instead of carefully inspecting each service and mirroring properties.
Alright well the only uses I could think of are for building because that’s all I do in Studio. However, I’m sure there are more seeing that this post is getting some attention. The primary use of this feature is to save on building time. No need to get upset, Thomas.
I often find myself manually typing over settings when making UI, support.
I myself would still find this feature useful in studio for every aspect listed in replies. We’ve gotten a lot of great updates but things such as this should be looked at as a possibility.
Definitely something that would be useful for me for many of the reasons Pezsmistic mentioned above, as well as the case for lighting in the original post.
If you’re an artist and find yourself wanting to transfer a bunch of properties from one part to another i.e. making a new mesh to preserve it’s size after changing the MeshId of a new mesh, this plugin is useful in the meantime for that case: