Duplicate models that have functions in StarterGUI?

Thanks, to clarify this in simple words: All you need to do is put the original model in ReplicatedStorage then Clone it into camera? I understand this completely except for the cloning into camera bit. What does that do?

1 Like

It makes, since you clone it in a client’s camera, that one can see it, while others don’t. Collisions apply, etc.

You can access the camera like this:

local camera = game.Workspace.CurrentCamera

The camera is an object that resides in Workspace, but only on the client. That is, each client has a camera object that is only located on their computer, in their version of Workspace. Therefore, any child of it will also become located only on their computer. You can use this concept for anything, including client-specific lighting effects.

No, I want others to see the model. But I want duplicates of the model that wouldn’t all be changed by one script but changed individually.

What you can do in that case is, save the model in ServerStorage, and then clone it when a player connects. You clone it with a name like nanitook’s ColorModel.
Obviously, you have to program everything, so that each script refers to the model of the player who is running it.

You can clone a ServerStorage model like this:

local model = game.ServerStorage.Model:Clone()
model.Parent = game.Workspace

There’s a couple of different ways you can do that, but the most efficient one that you’re looking for is to generate a new model for each player. It’s nearly the same concept as cloning and putting it into the camera, just a little different. The basic idea is this:

  • Store the original model in ReplicatedStorage
  • When a player joins, in a server-side script, clone a new model from ReplicatedStorage and place it in the Workspace
  • Use the name of the player in the name of the cloned model, so that the client script you’re working on right now can easily identify which one it’s working on

Is there any way to keep the models in workspace, as an individual without going through a mass Variable Change run. (If the model in unclaimed then they would see it unclaimed)

If you have a limited number of players (let’s say 8 or so), you could create 8 different models and assign each one to a client as they join, but in my opinion, that’s probably more work than it’s worth.

I think it can be. Since you could clone it from the workspace and rename it. Although this is not entirely recommended. You should also change the variables, because although you clone it from the workspace to the workspace, to refer to two different models, two variables are needed.

I plan to have about 80-85 players per server. But with 30-40 model copies.

Trust me, on that scale you’re going to be far better off taking a procedural approach.

1 Like

I agree completely. It’s not the best way to do it, but if you want to do it like that…
On that scale (80-85 players) it is less than recommended what you want to do.

In the simplest way to put it, it is the same result as renaming every variable name and replacing scripts. But in a more convenient way if this helps to clear things up?

Yeah overall you’re getting the same result (everybody gets a model to recolor), but you don’t have to have 80 different variables for each model. Such a case would be quite unmanageable.

1 Like

So overall Post 33 would work?

function modifyParts(partsToModify, newColor)
    for i, v in pairs(partsToModify:GetDescendants()) do
        if v:IsA("BasePart") then
            v.Color = newColor
        end
    end
end

button3.MouseButton1Down:Connect(function()
    modifyParts(primaryParts, Color3.fromRGB(table.unpack(selectedColour.Text:split(", "))))
end)

button.MouseButton1Down:Connect(function()
    modifyParts(secondaryParts, Color3.fromRGB(table.unpack(selectedColour.Text:split(", "))))
end)


button2.MouseButton1Down:Connect(function()
	local lost = workspace:WaitForChild("lost")
    local text = lost.SurfaceGui.TextLabel
	
	text.TextColor3 = Color3.fromRGB(table.unpack(selectedColour.Text:split(", ")))
end)
1 Like

Yes, it will work as long as ‘primaryParts’ and ‘secondaryParts’ are both properly defined for the player in question.

1 Like

What do you declare by that? (Sorry for this going long I am new to GUI scripting)

Not a problem. I just mean to make sure that ‘primaryParts’ and ‘secondaryParts’ refer to the correct model for each player. For example:

local localPlayer = game.Players.LocalPlayer
local primaryParts = workspace:findFirstChild(localPlayer.Name.."_primaryParts")
local secondaryParts = workspace:findFirstChild(localPlayer.Name.."_secondaryParts")

Assuming that you make two folders called “PLAYERNAMEHERE_primaryParts” and “PLAYERNAMEHERE_secondaryParts” for each player that joins the game.

Ok I seem to get this, every time they join, and “buy the booth”(bit off-topic so I didn’t mention this much) their name would be on the folder making that model theirs, but I also plan for when they leave the game for it to reset.

Exactly. And when they leave you’d have a section of code similar to this:

function playerRemoving(player)
    workspace:findFirstChild(player.Name.."_primaryParts"):Destroy()
    workspace:findFirstChild(player.Name.."_secondaryParts"):Destroy()
end
1 Like