This doesn’t have any inherent performance issues besides making one additional connection, which is then disconnected after yieldTime (or if player sends desired data).
Would this work with multiple players using the same remote to get their humanoidrootpsrt c frames?
Yes, because in that code I wrote you are checking for requests from specific player and if it isn’t that specific player, execution halts. You just need to verify the data player sends with typeof() and if it matches, then you are good to go!
Alright let me try it out soon
I am back home now and am able to start testing it out. I watched the video PhoenixCausesOof suggested (by Suphi) I might use his module as it seems it’s just remote functions but more secure. Could you take a look at it and see if it is viable?
I don’t have time for that, you might have to check it yourself, or just ask some of your friends.
Yeah I did looks good. Basically does what you were saying but simplifies it. Has custom yield
I don’t think using a RemoteFunction to invoke the client is the best solution in this situation. You’re basically doubling the network delay here because the server has to send a signal to the client requesting their position and then the client needs to notify the server of their position.
I’m assuming you’re trying to make a projectile system that doesn’t appear laggy? A possible solution is to have the client manage as much as possible to eliminate any network delays. The only things the server should be used for is hit detections and validations.
When a player shoots a projectile handle all the movement/effects locally and then use the server to check for hits and do any validations it needs to do. To have other players see projectiles, fire a RemoteEvent from the server to each player with the data about the projectile(start position, end position, direction) and have them create and move the projectile locally.
This thread below explains it much better than me: