Is setting part properties through a script more efficient than through the “Properties” tab

[FlammableSnowman]

Script:

game.Workspace.Part.Transparency = 0.5
game.Workspace.Part.Reflectance = 0.5
script.Parent.Rotation = Vector3.new(0, 0, 0)

(a lot of other properties along those lines)

Would it be worth creating a script to adjust these simple properties, or is it more efficient to just adjust them through the “Properties” tab. Please explain the advantage of both, and which you would prefer.

[Halalaluyafail3 (FindFirstChild)]

I don’t see why adding a script to change the properties would be more efficient. It would simply create unnecessary scripts, using excess memory.

If you’re talking about changing properites in the command bar, I would assume changing the properties in command bar would be more efficient but would take more time and you wouldn’t be able to undo the change with ctrl z.

Changing every property in a big script becomes a huge issue as if you want to edit one part you have to find where its properties are edited and then click play every time you want to see a change.

If you’re also creating the instances in the script then you can’t guarantee that those instances will exist when other scripts run so you will end up using a lot of WaitForChild()s when you don’t need to.

[colbert2677 (Dreamseeker)]

No. One is done precompile time and one is done at run time. Don’t see what your use case is for creating a script to set properties where you don’t need to, that’s pointless. Just set properties in Studio and continue on with your game?

Editing properties with code is only really necessary if functionality in your game needs to change properties for any specific reason (e.g. tweening).

[anthlons (tatemcraefan45)]

If you are building to build, do not use a script as its useless. Lets say you want to create a script to make an object that isnt in the game, then it would be logical to set properties in a script.

[FlammableSnowman]

Why would it be more efficient through the Command Bar?

[colbert2677 (Dreamseeker)]

The performance difference is negligible. The command bar spawns a thread when code is executed, if I remember correctly. Either way, all operations done in Studio are precompile so it doesn’t quite matter what you use.

I only really use the command bar if I need to access items in chunks, test code or I need a script to do something I can’t with the properties tab (like trying camera angles for menu screens). In every other case, I use the properties window.

[Xeptix (Xep)]

No.
But, the following should not be done:

local Part = Instance.new("Part")
Part.Position = x
Part.Size = y
Part.Parent = workspace

due to inefficient C-side calculations that occur when properties like Size, Position, and CFrame are set before the part was parented. @TheGamer101 explained it in the past. [im wrong ):]

[FlammableSnowman]

Other users are against creating a script. Can you please describe your reasoning for preferring a script, or link TheGamer101’s procedure?

[TheGamer101]

This is not correct. I think the post you are thinking about is this post which has a good explanation of the optimal order to set properties in a script.

PSA: Don't use Instance.new() with parent argument

I’ve discovered a pretty bad performance issue in one of top games that has to do with Instance.new and wanted to write about this, since this is not obvious unless you know the system inside out. Tthere are several ways to create a ROBLOX object in Lua: local obj = Instance.new(‘type’); fill obj fields local obj = Instance.new(‘type’, parent); fill obj fields local obj = util.Create(‘type’, { field1 = value1, … }) If you care at all about performance, please only use the first option - I wi…

The key is that you want to set the Parent property last always, adding a new Instance to the DataModel before it is fully initialized causes the game engine to do extra unnecessary work.

[Sentross]

The most simple way to put it:

• If you are using the properties for anything that have to do with builds just use the properties.
• Use the properties even when scripting to set up initial properties
• If you need to change any property during run time, then change it in code. You don’t have to change properties in code unless you need dynamic change.

[Xeptix (Xep)]

I had it the other way around. Thanks for the clarification, sorry

[FlammableSnowman]

You and multiple others prefer to use the “Properties” tab for specifically building, is there any reason for this? Why not use the “Properties” tab when scripting (if that’s what you’re saying)?

[Sentross]

I did not say to only use it for building, my second reason states:

• Use the properties even when scripting to set up initial properties

The only reason scripts have the feature to change properties is because often programmers need to change the properties throughout the run time of the game or dynamically.

For example: If you made and coded a sword that is silver but turns red when the player you are attacking about to die, you would use coding to dynamically change the sword blade colors to red. But there is no reason why you can’t change the blade color to silver via properties initially or pre-runtime.

Edit: Also the reason no one uses scripting for properties during building is because its useless. You do not need a script, you can change it on the spot.

[FlammableSnowman]

Thank you for the help @Halalaluyafail3 @colbert2677 @TheGamer101 @SentroRetorak! For any other advice please message me.

I have bookmarked all the posts in this topic that are useful, contributive, and admirable.

Have a wonderful day, and thank you!