Being able to change multiple properties in Instance.new() function directly

Feature Requests Studio Features
#1

As a Roblox developer, it is currently too hard to change properties of instances without flooding the code, and it’s impossible to modify properties of newly created instance without assigning a variable to it first.

If Roblox is able to address this issue, it would improve my development experience because I and other Roblox developers would be able to create new instances with set properties in a quick and concise way without flooding the code, this would also make functions for creating new parts much cleaner and would allow for creation and modification of instances without having to assign a variable to the new instance.

Current Method:

local newPart = Instance.new("Part")
newPart.Anchored = true
newPart.Position = Vector3.one
newPart.Orientation = Vector3.new(45, 0, 0)
newPart.Transparency = 0.5
newPart.Color = Color3.fromRGB(255, 255, 255)

Requested Feature:

local newPart = Instance.new("Part", {Anchored = true, Position = Vector3.one, Orientation = Vector3.new(45, 0, 0), Transparency = 0.5, Color = Color3.fromRGB(255, 255, 255), Parent = workspace})

The properties would be assigned in order after the part is created, so it would first anchor it, then set the position, then the orientation, then the transparency, then the color and then the parent. This is much more useful than the current 2nd parameter which is only used for setting the parent.

10 Likes
#2

This would be a great addition, as someone who experiences this. This is probably one of the most annoying things to have to do. It would be so much easier to just add in a table. Of course this could be a issue on the Intellisense I believe Roblox should figure that out. Other than that great request.

1 Like
#3

this would be really helpful for instances that don’t have a lot of properties to set, i’ve had a lot of cases where i’d like to do Instance.new('BindableEvent', p).Name = 'name' but had to unroll it to assign it to a variable and slightly save on performance

1 Like
#4

As far as I know, the order of iteration over tables after the array part is not-specified, so

{Transparency = 0.5, Color = Color3.fromRGB(255, 255, 255)}

is the same as

{Color = Color3.fromRGB(255, 255, 255), Transparency = 0.5}

as far as luau is concerned. You could just say “screw ordering”, but unless you make a cop-out for the Parent property, that could have large (and easily avoidable) performance implications.

Also, …why? You have to type out a couple more letters in your autocomplete-having IDE?

Having all a part’s properties coerced onto one line is not very nice in my opinion, and it becomes more difficult to discern which properties are being set. Of course, you could write it out over several lines:

local newPart = Instance.new("Part", {
    Anchored = true, 
    Position = Vector3.one, 
    Orientation = Vector3.new(45, 0, 0), 
    Transparency = 0.5, 
    Color = Color3.fromRGB(255, 255, 255), 
    Parent = workspace})

But I feel like I’ve seen this before…

Edit: Also, we had this before, and it was not good.

2 Likes
#5

it’s funny how this gets suggested after i did it in python

CenterLineX = Instance.new("Frame", {
  "BackgroundColor3": Color3.fromRGB(0, 255, 0),
  "Size":             UDim2.new(1, 0, 0, 2),
  "Position":         UDim2.new(0, 0, 0.5, 0),
  "ZIndex":           2,
  "Parent":           Workspace
})

CenterLineY = Instance.new("Frame", {
  "BackgroundColor3": Color3.fromRGB(0, 0, 255),
  "Size":             UDim2.new(0, 2, 1, 0),
  "Position":         UDim2.new(0.5, 0, 0, 0),
  "ZIndex":           2,
  "Parent":           Workspace
})

NewFrame = Instance.new("Frame", {
  "BackgroundColor3": Color3.fromRGB(255, 0, 0),
  "AnchorPoint":      Vector2.new(0.5, 0.5),
  "Position":         UDim2.fromScale(0.5, 0.5),
  "Size":             UDim2.fromOffset(100, 100),
  "BorderSizePixel":  5,
  "BorderColor3":     Color3.fromRGB(155, 0, 0),
  "ZIndex":           1,
  "Parent":           Workspace
})

TextButton = Instance.new("TextButton", {
  "Text":                   "TextButton",
  "TextColor3":             Color3.fromRGB(255, 255, 255),
  "TextSize":               24,
  "Font":                   "Roboto",
  "TextWrapped":            True,
  "TextStrokeTransparency": 0,
  "TextStrokeThickness":    2,
  "TextScaled":             False,
  "BackgroundColor3":       Color3.fromRGB(0, 255, 255),
  "Position":               UDim2.new(0.5, 0, 0, 20),
  "AnchorPoint":            Vector2.new(0.5, 0),
  "Size":                   UDim2.new(0.5, 0, 0, 50),
  "Parent":                 Workspace
})

replacing the ‘Parent’ argument with ‘Properties’ (like Tween:Create()) would help when a lot of elements have similar properties, and would allow you to collapse the properties

local BlockProperties = {
  ["Color"] = Color3.fromRGB(255, 255, 255);
  ["Transparency"] = 0.5;
  ["Material"] = Enum.Material.Neon;
  ["Name"] = "Block";
  ["Parent"] = workspace;
}

local Blocks = {
  [1] = Instance.new("Part", BlockProperties);
  [2] = Instance.new("Part", BlockProperties);
  [3] = Instance.new("Part", BlockProperties);
}

... -- Versus

local Blocks = {}

for i = 1, 3 do 
  local NewBlock = Instance.New("Part")
  NewBlock.Color = Color3.fromRGB(255, 255, 255)
  NewBlock.Transparency = 0.5
  NewBlock.Material = Enum.Material.Neon
  NewBlock.Name ="Block"
  NewBlock.Parent = workspace

  Blocks[#Blocks + 1] = NewBlock
end

at the end of the day, this is just a QOL suggestion; it probably won’t be added

1 Like
#6

I don’t get how this is any better than the current method. All you’re doing is putting everything in one insanely lengthy line, which you’re going to have to space out if you want to follow proper code etiquette anyway:

-->> proposed method (single-line version)
local newPart = Instance.new("Part", {Anchored = true, Position = Vector3.one, Orientation = Vector3.new(45, 0, 0), Transparency = 0.5, Color = Color3.fromRGB(255, 255, 255), Parent = workspace})

-->> proposed method (clean version) [7 lines]
local newPart = Instance.new("Part", {
    Anchored = true,
    Position = Vector3.one,
    Orientation = Vector3.new(45, 0, 0),
    Transparency = 0.5,
    Color = Color3.fromRGB(255, 255, 255),
)}

-->> current method (clean version) [6 lines]
local newPart = Instance.new("Part")
newPart.Anchored = true
newPart.Position = Vector3.one
newPart.Orientation = Vector3.new(45, 0, 0)
newPart.Transparency = 0.5
newPart.Color = Color3.fromRGB(255, 255, 255)

Not only that, the second argument of Instance.new() is already used to specify a parent, and replacing that with a totally different datatype is quite unconventional in terms of coding standards.

4 Likes
#7

holy cow i would pay for this feature

1 Like
#8

im unsure of the performance gain over setting it directly, table construction is definitely a nice conveniece but its basically useless unless it can define a tree.

also hashtables are evil, i hope you like undefined key order.

#9

Roblox will not introduce it because such change would break many games as currently the 2nd argument is the instance’s parent (don’t use it btw, it causes performance issues!).

Also, as someone mentioned before, I don’t see it as a code readability improvement. You still list all the properties and their values, you just do it in a table that you should split into multiple lines anyway.

If you want to avoid spamming the properties, it’s a good practice to create a template part in ReplicatedStorage and then clone it when needed, minimizing the amount of properties changed via code.

#10

well i tried to explain the only two reason i think the Parent argument in Instance.new() would be replaced with Properties

  1. the table collapse
    you can’t collapse the current version

but you could with a table of properties

> local NewPart = Instance.new("Part", {
)}

and 2. and the alternative ‘property cloning’ method
it would be easier to only specify a table of properties for a lot of similar parts

local NewPart = Instance.new("Part")
NewPart.Anchored = true
NewPart.Position = Vector3.new(8, 0, 8)
NewPart.Transparency = 0.5
NewPart.Color = Color3.fromRGB(255, 255, 255)
NewPart.Parent = workspace

local NewPart2 = NewPart:Clone()
NewPart2.Parent = workspace

local NewPart3 = NewPart:Clone()
NewPart3.Parent = workspace

local Properties = {
  ["Anchored"] = true;
  ["Position"] = Vector3.new(8, 0, 8);
  ["Transparency"] = 0.5;
  ["Color"] = Color3.fromRGB(255, 255, 255);
  ["Parent"] = workspace;
}

local NewPart1 = Instance.new("Part", Properties)
local NewPart2 = Instance.new("Part", Properties)
local NewPart3 = Instance.new("Part", Properties)

this isn’t a totally useless suggestion (again i don’t think it will be added)

#11

How is it easier? If we’re going by line count (admittedly a very crude way of doing this, but it seems to be what this request is built around anyways), then both are equally easy to do.

Why would you want to collapse it? To make your code look a tiny bit shorter? And besides, if you want it that bad:

function createThing()
    local newPart = Instance.new("Part")
    newPart.Anchored = true
    --...
    return newPart
end
-- woah i can collapse it now
#12

i was saying it was easier because it’s less characters to type out; i could type out a table of properties faster than variable + property (it really depends on the person. i know some people have trouble typing brackets and quotes)

i already said this is just a qol suggestion; a very minor reason why it would be added.
not everyone cares about collapsing (for valid reasons)
but i would still rather have the table of properties over the new function

local function CreateThing()
  local NewPart = Instance.new("Part")
  NewPart.Anchored = true
  NewPart.Parent = workspace
  return NewPart
end

local Part = CreateThing()

-- this is a lot easier for Me to type out
local Part = Instance.new("Part", {
  ["Anchored"] = true;
  ["Parent"] = workspace;
})