Each drop has a ClientDrop class (client-side physics and client-side visuals (meshes, effects, cash displays)) but also some server side logic ServerDrop class, and that’s exactly the issue…
With streaming enabled, when players visit other plots, they see the drop instances streamed in that never received a client-side instance, because they literally appear from nowhere from the client prospective
Current System: Server creates drops → fires replication events → client creates client instance. But when drops stream in the whole structure breaks.
Looking for feedback on this approach for handling client-server drop synchronization with Roblox streaming. Any experience with similar streaming challenges would be greatly appreciated. Particularly is there some way of knowing when an ore has streaming in/out?
Im not too sure what your main problem is, from what I can get you’re having trouble with Server telling Client to spawn a dropper but something breaks because Client doesn’t have the base loaded or something?
If that’s the case what I’d do is have each base have their own RemoteEvent that spawns in their drops and have a Script with its run context set to Client that also runs the RemoteEvent Dropper for the base. Then assuming the Base is a model, have it’s ModelStreamBehavior set to Nonatomic, this way if the Model isn’t loaded for the player, it also won’t load the RemoteEvent or ClientScript to run the base’s drops.
There are some caveats to doing this. If the player were to un-render the base while there are still drops and then come back to re-render the base, the drops are still going to be there. This can easily be fixed by just having a delete all drops run in the Client Script but just telling you so you don’t have to figure out why they still exsist.
not exactly, as i said it has to do with StreamingEnabled streaming thing in, which is not accounted for in my system and i dont know how i would implement it to react based on the instances streaming in and out
So the Server drop part gets streamed in but doesn’t have any Client Data assigned to them, thus causing stuff to break. I assumed the Client did the dropping not the Server :d.
Then I guess you could tweak my answer a little. Setting the Base’s StreamingModeBehavior to Nonatmoic will cause any Script with Runcontext set to Client to run once when the base is streamed in. Using that you can get all the dropped parts currently in the base and set their data.
Though setting their data might a little difficult. If you’re using attributes you could probably do something with the attributes but I doubt you are. I’ll likely need a bit more info on how you’re setting up the data to actually solve the problem.
Not exactly, it just isn’t used as much. You can view this like an Animation Script for a model, you wouldn’t want the Animation being controlled from an outside script, I mean you can but it just makes things whole lot more difficult then just having the Script in the Model. And Scripts with RunContext set to Client are meant to be Parented by anything, so it really isn’t bad at all.
Actually i have a framework where the animation is controlled by an outside module, and it works fine. Having scripts in models and parts , especially larger implementations is a naive approch that begginners use because it has very serious issues with scalability reliability and optimization
If you don’t want to use my solution that’s fine, though as far as I’ve looked, there isn’t really a way to detect when parts are rendered in for the player. So I guess I’m just as stumped as you are.
Actually it’s a life saver , i have 6 players per server, and each player can have a lot of minerals , a maximum of 200~, imagine 1200 parts at once… unfortunantly StreamingEnabled is a requirement.
what if you use ID’s to match the instance to the class and only do certain things if the instance exists and isn’t parented to nil? this check would only need to be done whenever the instance has to do something so it should be fine for performance, it would make it easier to make the name of the instance to the id so that you don’t have to loop every instance to find if the matching one exists
you said the client does all physics, does the server give the client data about the part and the part is made and handled on the client?
could have the server send to the clients packets of info in bulk for the respective tycoon if the player is nearby, or if content is sent to every client, if the client sees that a base isnt streamed in, to not do the physics/visuals if it is purely cosmetic
So if each drop instance is associated with some BaseDrop, could you store every BaseDrop inside of a table, when the instance is streamed in (maybe you could detect this by adding a tag to the instance), you check if there’s a BaseDrop associated with it, if not, create the BaseDrop?
If you’re creating drops from the server you don’t need replication events as anything created on the server will be instantly replicated to all clients. You may want to change your approach and exclude idea of using part physics on the server for the selling logic.
“you don’t need replication events as anything created on the server will be instantly replicated to all clients” That doesnt happen because im using StreamingEnabled
“using part physics on the server” the server doesnt calculate the physics , the owner of the plot does, the server just handles the selling logic because of exploiters
client instances are partially cosmetic partially practical but only if you are the plot’s owner if you are the drops instances are persistent anyway since you have the network ownership and you havea duty as the owner to always have your own drops loaded.
From the prospective of a client that’s not the owner on the other hand, yeah it’s purely cosmetic, so yeah i could give all the info to the client and let him create client instances and destroy them based on streaming in and out. Speaking of which i found an elegant way to detect streaming in and out using collection service’s GetInstanceAddedSignal and GetInstanceRemovedSignal, so I’m making progress and i think i got it now. Through bits and pieces from you guys i almost have a final implementation.
