You can spawn parts using scripts!
Spawning a Part into via game.
Just like with strings and numbers, you can store Parts inside of a Variable
Here is how you would do that!
CoolBlock = Instance.new("Part", workspace)
So now, our Part is in a Variable called CoolBlock
As with other variables, we can print this variable and see that it is storing a part:
Now that we have a variable with a part stored in it, we can change the properties of that part. Any of the properties that you can set with Studio tools or through the Properties window can be changed with a script command. To change a property of something stored in a variable we have to provide the variable, the property we want to change, and the value we want the property changed to. In code this has to be presented in a very specific way. When accessing a property, you have to include a dot (.) between the variable and the property name. For example, to change the name of our part we can write the following:
CoolBlock.Name = "Bob"
After entering this command we can see the name of the part in the explorer changed from Part to Bob.
We can change other properties as well. For example, if we want to make a part slightly transparent, we can change the Transparency property.
myPart.Transparency = 0.5
What about parts that already exist in the game? We can change those with code too. When we need to do something to an existing part in the game, we have to specify how to get there through the Explorer. To do this, we must first understand how games in Roblox are organized.
A Roblox game is structured into what is called a tree. The very top of the tree is the game itself (referred to in code as game). Underneath the game are the standard services such as Workspace, Players, Lighting, etc. Since these are a level below game, they are considered game’s “Children”. Likewise, game is considered these services** Instance.Parent. If you go down one more level, you’ll notice that Workspace also has several Children. In an empty place, it typically has three: Terrain, Camera, and Baseplate. If you add anything else in the 3D view (like a Part, Decal, etc.), these will become children of Workspace. Looking at the Explorer is basically like looking at this tree on its side. The game is always hidden so all of it’s children appear on the first level of the Explorer. Anytime something is indented in the Explorer, it is a Child of whatever it is under. Now that we know how the game is organized, we can talk about how to access an object in the Explorer through code. When we want to get to a specific object, we have to write how to get there via the tree. For example, suppose we want to change the Transparency of the Baseplate. We know the Baseplate is a child of Workspace, which itself is a child of game. To access an object in code, we start at the highest level and then work down through the children. So, we start at game as that is the highest level in the tree.
To move to a child, we have to write dot (.) then the name of the child. In this case, we want to move to Workspace so we would write:
We can descend another level to the Baseplate by writing another dot (.) and then Baseplate:
Now that we are at the Part we are interested in, we can access the Property we are interested (with a dot, just like above), and then set it.
game.Workspace.Baseplate.Transparency = 1
The Name property of parts is critical when running code like above. To access parts like above the Name has to be spelled correctly. The Name also cannot include any spaces. If the part was named Base plate the above code would not work.
It is also important to give your parts unique names if they are in the same service or folder. If there were two parts named Baseplate and you tried to change the transparency of one using the above code, the game would pick one of the parts and there is no guarantee that it would pick the part you want. A better approach would be to name parts like Baseplate1 and Baseplate2 if you need to change them individually from code.
Med Written By 2008snate
See 2008snate's profile on Roblox