So knowing that, how could I detect if the clone touches something? If the cloned ball is created locally will regular scripts run in the ball? If they do could I use a remote event in the regular script to trigger a local script in SterterPlayerScripts to do actions.
use remote event one that detects the touched function and then fires it to a local script to the player that touched it therefore changing it locally.
What you proposed won’t work, as the part itself is only local and hence the server has way to know it exists.
One method you could use is have the ball be parented to a folder in workspace (carried out in the script that clones it), then use ChildAdded within the local script to detect when the ball is added to the folder
Then when you clone the part can you try and combine the .touched function with the clone? Meaning inserting the .Touched function inside the function.
local ball = "YOURBALL"
local function cloneBall()
local clonedball = ball:Clone()
clonedball.Touched:Connect(function(hit)
print("ball touched something")
if hit.Name == "pin" then
hit.Color = Color3.fromRGB(255, 255, 0)
hit.Material = Enum.Material.Neon
wait(.2)
hit.Color = Color3.fromRGB(99, 95, 98)
hit.Material = Enum.Material.Plastic
end
end)
end)
Maybe you can spawn clones without adding script inside clone
Clientside ( can be StarterGui, ReplicatedFirst or Inside player )
Method 1
workspace.ChildAdded:Connect(function(ball) -- something spawn out
if ball.Name=='ball'then -- check if called a 'ball' and make sure it was f
ball.Touched:Connect(function(hit)
print("ball touched something")
if hit.Name == "pin" then
hit.Color = Color3.fromRGB(255, 255, 0)
hit.Material = Enum.Material.Neon
wait(.2)
hit.Color = Color3.fromRGB(99, 95, 98)
hit.Material = Enum.Material.Plastic
end
end)
end)
or
Method 2
function spawn_ball()
local ball=game.ReplicatedStorage['ball']:Clone()
ball.Parent=workspace
ball.Position=Vector3.new(0,0,0) -- Spawn Position
ball.Touched:Connect(function(hit)
print("ball touched something")
if hit.Name == "pin" then
hit.Color = Color3.fromRGB(255, 255, 0)
hit.Material = Enum.Material.Neon
wait(.2)
hit.Color = Color3.fromRGB(99, 95, 98)
hit.Material = Enum.Material.Plastic
end
end)
end
spawn_ball() -- call up
Oh I see your making a bowling ball. Then .Touched won’t work I suppose using :GetTouchingParts() would work.
Edit: and maybe make a hitbox for the ball because it might not register some touched parts and use RenderStepped, Stepped, or Heartbeat
either these three
1 Like
then how come the localscript inside of my proximitypart which is a descendant of workspace is working fine?
it’s just that localscripts have a tendency to not be able to detect things in the workspace
Cause it doesnt work if the Parent is workspace for the local script.
i mean yeah, what is there to modify in the workspace locally anyway
Your logic doesnt make sense cause in that case every local script which is either inside a part or surface gui and is a technically a descendent to the workspace therefore work
try it yourself with a localscript inside of a proximitypart that is a children of a part on the workspace, you’ll see what i’m talking about.
my lookat localscript also works which is located inside a part from workspace
But the parent isn’t the workspace, under the workspace does not mean descendant in that case every script inside the workspace would not work
it’s still inside the workspace, but inside of a part or a proximitypart, or whatever. but of course it wouldn’t work if it was directly under workspace and nothing else
Yea, that’s basically what I said really.
I wanna clear something up. LocalScripts that are direct descendants of the workspace will not run. However, Scripts with the RunContext set to Client will and is subject to streaming.
arent those basically localscripts
Same environment, but the difference is where it can run. Scripts with the RunContext to Client can run mostly anywhere where LocalScripts cant (excluding things such as server containers).
This allows you to run client code in the workspace, and the main advantage to this is that you don’t necessarily need to use WaitForChild or CollectionService depending on your Model’s/game’s streaming behavior. I’m not saying this is recommended, but it is an option.
You can test out this behavior by inserting a Part, then a Script with the RunContext set to Client inside that part. Decrease your streaming radius and let it stream in and out or move the part on the server. You will see that it will essentially act like the Script is being added and removed, rerunning the code.
2 Likes
Should making showcase even much easier?
1 Like
Ha, I overthought this so much, thanks for dumbing it down for me. Video was super helpful!
1 Like
Wow ok, this is another way to accomplish my task, although the solution I marked will be easier due to amount of scripts I did not know this and will be using it in the future, thanks!