(Server -> Client -> Server) Communication

Help and Feedback Scripting Support
#14

It generates a new key whenever there is a new valid request. there’s no way to reuse the old one. The only problem I think this might have is when you use it with multiple people.

oops you’re right, I’ll fix it

#15

You’re right of course, but I’ve just written it down to just give the general idea how it’d look like, I haven’t tested it.

#16

You can reuse the key because it only generates a new one when a new player joins which also brings up problems as only the recently joined player would have the right key.

#17

Of course it could be tweaked to work but a simple bool value would do for this case. You want to avoid things like this (key systems) as much as possible.

#18

what are you on about? it creates a new key whenever the function fires.

#19

The random seed isn’t in a function.

#20

the random seed is in a function, and the variable gets re-defined every time the function fires. I haven’t assigned the function.

#21

but the function isn’t tied to a PlayerAdded event so I have no idea where you got that idea from.

#22

Well it would need to be to get the plr variable thats all I am saying here.

#23

you can get that in other ways.

#24

Thanks for the help everyone. I think all responses helped me understand all possible ways, I will leave @mistrustfully’s reply as the solution as I think it works well for me.

Thanks :slightly_smiling_face:

2 Likes
#25

Alright, I still believe the key system in general is unneeded here. Do you agree?

#26

While I agree that it’s excessive in most scenarios, it’s definitely the most exploit proof. Would you rather have a keypad on your door or just a simple on off switch?

#27

Keep in mind exploiters cant modify variables on the server so they couldn’t just go to the light switch and turn it off or on. Anyway we should probably leave here as there is a solution now, I am getting carried away :laughing:

1 Like
#28

Yeah, I agree, I’ve messaged the moderators to lock the post so it doesn’t get more off track for others to see

1 Like
#29

Honestly you don’t need to worry about clients activating the interface ahead of time because the only way that would happen is if an exploiter was involved. Even then, you’re able to have the server track request ids or whatnot so that a little more work needs to go into using the raw interface, such as needing to define the type of request and the arguments. Exploiters will ignore your interface and just send things directly over though.

Separate your network flow into two parts. The server giving the client a request and the client sending data to the server. As isolated but associated systems, networking will become significantly easier for you to manage. You will know how your game works so you won’t necessarily have to worry about interfaces being activated ahead of time.

One thing - when you are looking into a system like this, do not use RemoteFunctions in such a way where you may come across the need to use OnClientInvoke. While that is the canonical way to accomplish this system and the workflow implicitly exists for you, the client can permanently hang the server by not returning a response. This can occur in many different fashions. As for an exploiter, a simple line of code:

RemoteFunction.OnClientInvoke = function() end
2 Likes
#30

Well technically you can get the break the function if the Client fails to respond within 5 seconds perhaps.

#31

What’s the point pf having a wait for that long? Wouldn’t that have major problems?

Also why is the processing input thing outside of the event? That doesn’t make very much sense.

local inputRequests = {}

RemoteEvent.OnServerEvent:Connect(function(player)
    if not inputRequests[player.Name] then
        inputRequests[player.Name] = true
        RemoteEvent:FireAllClients()
        delay(100, function() -- why not this?
            inputRequests[player.Name] = false
        end)
    end
end)
#32

You can’t. Once the server starts an invoke, the thread yields until a response is given. The only way to accomplish such a thing is to use coroutines, but now you have the risk of memory leaks. If the coroutine thread is hung, it just dies and now you have an idle thread there consuming memory. It also no longer operates synchronously so you have to create the timeout yourself and yield other code until a response can be resolved.

OnClientInvoke should never be used in production code. As great as it may be, its not stable to use because of the presence of exploiters and tampering with OnClientInvoke. BindableFunctions are still good, just stay away from RemoteFunction’s OnClientInvoke.

3 Likes
#33

The wait(100) is just an example. If OP needs it to be shorter, he can just change it.

I also mentioned that this is just to give OP an idea on how he could solve this.

I didn’t take much time or effort to make it, it was just an example.

1 Like