I understand that StreamingEnabled makes it so that you don’t render stuff that is in the distance, which betters performance. But I was wandering how this will effect FireClient and FireAllClients.
If let’s say a part is very far away, and the client doesn’t render it, but we fire FireClient on a remote event and pass that specific part to the client, would the client have information on it?
An example use would be: in a very large open map, there’s a moving target (e.g a primary part of a model), and I want one player have a beacon on it. So I use FireClient to pass the primary part of the model to the client, for the client to then clone a BillboardGui on the part that was passed to the client. But on the client, this part hasn’t rendered yet because it’s very far away and therefore not streamed in.
I can’t seem to find an answer anywhere on this. Thanks in advanced.
From my understanding, parts will get destroyed once they’re out of rendering range when using streaming. In general I’ve heard it’s better to avoid using it, because you can run into lots of complications with stuff turning to nil.
If you have a reference pointer to an object that becomes nil, I would think the information about the object would still be there, although the object instance would become nil and unusable I believe.
Feel free to correct me if I’m wrong on this, I haven’t really ever used streaming
I see, so how would I go about this specific issue as noted in the example? Surely there’s a way to track a moving part that could may or may not be in the render distance.
My post is a bit all-over-the-place, but here’s what I’ve found:
So, I’m struggling a bit to set up an example where a part in memory is deinstanced in favor of new loads, but I have been able to set up a scenario in which the player does not load a part because it is too far away, and, unfortunately, sending that part to the client via a RemoteEvent results in the client receiving nil.
This is not entirely unexpected because remotes cannot send information across the client-server boundary that is not visible to both parties, although it is still a bit surprising since the part is technically visible to both parties, just not at the given moment.
While you may not be able to send a direct part reference, you may still be able to achieve the desired results. Your best bet would be to instead send position/trajectory information to the client and have the client generate its own tracker that mimics the movement of the target. You could add periodic checks to see if the target has rendered in and hide the client-side tracker while the target is currently in the cache, but then you run into issues with verifying unloading of the actual target.
If I can get my part to unload while testing, I’ll return with my findings, but all I’m managing to do is drop Studio to 0.125 FPS. I do wonder if StreamingEnabled behaves the same in Studio as it does on a live server, or what the criteria for reallocation of resources actually is.
My example case was pretty generic, I should’ve used my specific example:
The player has abilities, one of which is a super punch, in which the player leans back to charge it up and then punches. When the player does charge it up, I was planning to send the players right hand to all clients, which each client would place a dummy part on the hand to act as a glow and various sparks would be absorbed into it, all done with tweens, It would be 10x smoother on the client and would take the strain off the server since it’s not rendering the effects.
Thanks for the research! I’ll be sure to consider this.
I don’t see anything wrong with that approach based on what I found. All you would need to check is whether or not the client actually received that object reference before acting on it.
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())