Hi, so i have a roll feature in my game and i want players to see a particle when they roll. My system is mostly complete except you can only see your own roll particle. I want every client to see it, but i want it to be client sided so the particle is smoother.
just remote event to the server all the data it needs and then replicate it to each client.
That remote event would be fired very frequently by multiple players pressing Q to roll. Would that cause performance issues?
i mean there would be less performance, but its so small that it doesn’t really matter. Plus if you want to communicate to every client, this is the only way I can think of and its really easy
Data gets sent from the server to the client every 1/60th of a second anyway. So I don’t think that would cause an issue. I would add a cooldown of 1/60 seconds for sending a remote event from the client.
You should think of limiting it to like 1/10 and lerp it to achieve smooth transition
unfortunately clients cannot directly communicate with other clients, but the client could pass the part to the server and from there the server could pass it to the rest of the clients
What you’re trying to achieve not only is a really bad way of doing it but also is almost impossible.
I also don’t understand why you would want to apply a change that small to every single client when you could just do it in the server, I can assure you having every client receive this data one by one would lag your game way way more than simply doing it on the server.
As long as you properly dispose the particles after using them everything should work just fine server-sided.
got it, I’ll just do that then
for dashing client, when you pressed the dash button, you can create dash particle on your local side for immediate response. i think you would already have a remote event that goes to server to tell it that the player dashes. in it, do a remote event to all other clients and tell them to make a dash particles on that player
sidenotes: two cents to share here. worked on a battle arena game, the one time we had to look into the particles is because of occasional lag.
We checked the stats, one particle causes gpu goes into brown zone. we lowered the number emitted and may had replaced the effect with less heavy ones.
then we see the other culprit is the slash and hit effects causing network receive goes into brown zone. especially when multiple players are fighting each others. these effects do not cause gpu to rise though.
they were server side created, so my expectation is that, each of these instance will replicate all its part, particle, cframe info etc to the clients and possibly every frame server sends their movements and property changes to all clients. that’s a lot of data, just for visual effects (that doesn’t affect game play much)
so we turned these slash and hit effects into remote events like hitEvent:FireAllClient(byPlayer, hittedPlayer, effectName). this reduced network traffic a lot. in phase two, server check the distance from the witnessing player to the hit event, and decide whether to use hitEvent:FireClient(witness, byPlayer, hittedPlayer, effectName) ; or if witness is slightly far away to notice the hit effect, we use UnreliableRemoteEvent, server will drop some of these calls if it needs more bandwidth for game play important data; or if witness is too far away, we don’t send the hit effects events and all.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.