I am trying to call a remote event from the server to the client, setting an object created in workspace as a parameter. However, since streaming enabled is on, the part that is set as the parameter does not exist on the client, even though the part is right next to the player’s character.
It is possible to do this using things such as WaitForChild, GetInstanceAddSignal, or using an ObjectValue (untested), but it seems like it should be possible to get the object directly from the parameter. (For example, instead of using workspace:WaitForChild("PartName") I would instead use the parameter that was given, for example workspace:WaitForChild(x), but this doesn’t work since WaitForChild only works with a string and the parameter is a nil value so holds no information.
The part is cloned and positioned BEFORE being parented to workspace BEFORE calling the remote, so the only reason it’s not loaded in on the client is because of Game Content Streaming is what I found from testing.
In short, is there any way to make sure the client loaded the object before calling the remote? Any way to pass on some sort of information that the client can load/identify the part with?
I had the same problem the other day. What I ended up doing was adding the parts that were referenced by scripts into ReplicatedStorage, the adding a script to clone them on the client, so they always existed locally.
I’d recommend omitting the parameter reference to the instanced object and on the listening side doing something similar to the following.
local object = workspace:WaitForChild(ObjectNameHere, 10)
Utilising the second parameter of WaitForChild() you can yield the active thread of execution for some duration of time in order to allow for the object to replicate to the client.
@BadDad2004 Sorry for the late reply- I thought putting the part I need into Replicated Storage was a good idea, but since I want the server to move the ball in the future, I don’t think that specific way would work. I did think of a solution similar to this where it was instead a remote function rather than a remote event, and then set up measures to make sure it couldn’t be exploited. This doesn’t seem like the best method for this, though, and adding extra scripts to simulate as if it is being streamed from workspace seems necessary. One method that might work is to use the remote event to tell the server if the value to the client was nil, so that the remote event would keep firing to the client until it had the object.
@Forummer I’m not sure how a time-out would help with this, there is no problem with an infinite yield for this case. The problem I had with WaitForChild was that I had no specific name or folder for the object, and it was just in the workspace. While I am rethinking about it, though, maybe just assigning the part to the player’s UserId since it is user specific would work.
Use task.wait() 0.1 - 1 before fire remote because it’s not replicated to clients yet i recommend task.wait(1) but welp task.wait(0.1) is ok too but when game lags it might delay (if you use :Clone())