Instance.new("Part")/Studio->Insert Part Inconsistencies

Feature Requests Engine Features
#1

Creating a Part via lua script creates a part that is inconsistent of that which is created by using studio’s Insert Part feature.

Untitled
Untitled894×474 14.8 KB

I believe the result of these two methods of creating parts should result in a consistent part being made.

My solution:

Modify Instance.new(“Part”) to result in a part with the same properties as Studio → Insert Part

2 Likes
#2

This isn’t possible due to backwards compatibility with old scripts that rely on parts having specific default values.

6 Likes
#3

Noted.

#4

There is also an inconsistency with creating frames in a script which have a background colour of “163, 162, 165” but in studio is “255, 255, 255”.

https://gyazo.com/9ed2b4cfb7170a37ba241fd1097f4b6d.png

#5

1 Like
#6

I generate thousands of parts using scripts, and the overhead from setting TopSurface/BottomSurface to smooth really adds up on low-end devices. I would simply not set them to smooth because SurfaceTypes aren’t visible outside of studio, but I read this post and decided that might be a bad idea:

I’d use :Clone(), but it’s generally slower unless the part has more than a few descendants.

1 Like
Changes to Part Surfaces
#7

If cloning is slower than creating a new instance and setting all the desired properties, then the right solution is to optimize cloning.

8 Likes
#8

“A frame is 3, 162, 165 due to backwards compatibility” does not seem valid at all. There is no reason Roblox would use different colours for backwards compatibility as frames have always used Color3.

In the case of part size wich has changed to a smaller minimum value there is a need for backwards compatibility.

You cannot apply the same reasoning to every instance in Roblox.

#9 
PlayerGui.ChildAdded:Connect(function(GUI)
    if GUI.Frame.Color3 == Color3.fromRGB(3, 162, 165) then
        -- New GUI cloned from server!
            manageOnClient()
    else
        -- Already managed. Client just de/re-parented
    end
end)

Roblox is a large platform, and backwards compatibility includes supporting awful coding practices. So sorry, this reason does apply to every property.

#10

It may be caused by searching for CollectionService tags

#11

CollectionService does not appear to apply to objects outside the game tree, so there should be no net effect coming from it. Even so, it was stated somewhere (an RDC talk, I think) that tags could also be faster. It’s better to optimize before breaking backwards compatibility.

1 Like
#12

I’m the one that proposed and implemented CollectionService, I don’t remember hearing about this?

I’m not really sure what you mean by “searching for” here. When you clone an instance, the list of tags on the object is copied byte for byte, which is fast.

Only upon parenting the instance to the data model does any actual work in CollectionService happen, and that work is:

  1. Call GetService(“CollectionService”) - relatively slow.
  2. Iterate through the tag list.
  3. For each tag, look up the bookkeeping data for that tag (one hash table lookup).
  4. For each tag, insert the instance into that tag’s instance list (one hash table insert).
  5. For each tag, invoke InstanceAddedSignal() - relatively slow.
2 Likes
#13

Perhaps I misremembered. There’s this question related CollectionService, but it doesn’t relate to how it is optimized:

Maybe it was something else, but I seem to remember there being some feature that “could be faster” or “more optimized”.

#14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.