there’s many methods to network a mouse click, this one makes sure it happens one time without a table reference. its code promise is that the intended user invoked or fired it every time, yes
oookayyy this is getting pretty tiring, are you even reading what I’m saying?
Why are you avoiding tables? You’re literally picking the worst possible way to do it.
Maybe I could understand the “only the intended player can fire this remote” argument, but you’re literally destroying and recreating it each time.
u know PlayerGui is the ONLY place the server and client share a local folder?
resetting your character without cleaning the folder up can cause memory leaks.
BUT it’s the most ideal place to share info server-client, because the target client is the only affected player that can see the replication
okay but why?
your character respawning script just respawns the player that fired it, why do you need to give each player their own private remote?
I rarely use RemoteFunctions and when i do, it’s to retrieve something from the client which is rare. I find RemoteEvents more easier to use when it comes to syncing server-side stuff
Ofc the times i used a RemoteFunction’s OnServerInvoke is when i needed to make the server yield but atp, why does the server need to yield? The client is the one playing the game, the server is just the authoritive side to keep things in sync and correct stuff, the client itself is the game
1 Like
external variables can modify players individually, i’m just avoiding having to check extra values from the table like you said. excluding and including players with this setup doesn’t require a table, but it will probably use one.
the main thing is cleaning up extra FireServer() and Invoke(), this ultimately ensures the code won’t iterate over the playercount, while also making it harder to exploit. It’s not about the code itself being exploitable, it’s about how spammable. (any event listener can be spammed, but not if it doesn’t exist on the server…) elaborating! im opting to reduce rejections as much as possible <---- final answer thank you GOATS! @nowodev @NPCPlayer2421 @Wunder_Wulfe
???
How on earth does playercount fit into this? I told you to track cooldowns with a table (which might not even be necessary for some use cases), not a whole physics simulation.
i really don’t know how else to tell you this, but that’s way more efficient than creating 5 billion remotes and connections!
You can also kick the player if they send too many requests!
I’ll put this another way:
Imagine you’ve finished eating a dish, do you smash the plate and buy a whole new one, or you wash and reuse it?
if there’s a RemoteEvent setup that prevents rejections, i like it more… IF… kicking a player isn’t involved. are u going to level me up??? 0~0
I’ll put this another way:
Imagine you’ve finished eating a dish, do you smash the plate and buy a whole new one, or you wash and reuse it?
You can if you really wanted to, but that’s damn inefficient and a waste of resources!
I’ll say ONE more time!
Rejections are more efficient, reliable, and maintainable than doing what you’re doing.
A function call isn’t very expensive, and even if you call it enough to maybe justify a “private” remote, why? You’re still handling each request, you’re only slightly slowing a potential exploiter down, while making a normal user’s experience worse.
the behavior has a hardcoded cooldown, i just prevent the event from spawning until ready. it’s completely stopping lag in its tracks!
…And how are you tracking that?
when it fires, it always deletes every time, promising only 1 callback (or 1 rejection) until the new remote is spawned
Well you do you I guess, you posted this in Code Reviews.
it’s completely stopping lag in its tracks!
recreating a remote (or any instance) is more expensive than just returning nil in already existing connection to already existing instance.
the behavior has a hardcoded cooldown
You literally decide how it will go depending on what logic you use for it. Your way is just a wasteful use of server resources and completely unreliable
I’m trying to make a notable commentator the Solution to this post, could you try breaking it?
everyone here is epic
The challenge:
Using both clients, try to make the server error either remoteEvents or remoteFunctions. Breaking the server loop while both Players exist is a big win
stresstestpls.rbxl (63.9 KB)
I finished making the PlayerGui setup. This one simulates menu buttons efficiently.
stresstestpls.rbxl (86.2 KB)