This is related to my previous post ‘Effective Carry System’. I tried one of the suggestions, it being using Remote Functions. It ended up skipping over some of my code thus returning a nil value. Is there a way to make the function wait for a GUI button to be pressed before returning a value?
Here’s some example code:
-- CLICKED Player recieves a sit request
request.OnClientInvoke = function(hasRequested, playerRequesting)
button.Activated:Connect(function()
return true
end)
-- returns nil bc skips over event above ^
end
request.OnClientInvoke = function(hasRequested, playerRequesting)
button.Activated:Wait()
-- code
end
That should work just fine, but lets talk about the implementation for a second. Generally server isn’t advised to invoke the client and this is exactly why. Forget that you are waiting for a button being pressed while using a RF (which is best done thru RE btw) but suppose the client left the game without pressing the button, then what would happen? Well, the server would be kept yielding forever. Not quite what you want, is it? So my advice, don’t invoke the client at all, just use REs; anything that ca be done thru RFs can be done thru REs.
Ah, I didn’t think of that. The thing is I’m sending a RF from the first client (player who requests to carry someone else) to the server which then sends the RF to the second client (the player being requested). The second client’s response is returned to the server. The first client is waiting for a response from the server.
Originally I was using a bunch of RE. Using RF, I thought it’d be more efficient. Do you suggest I switch back to RE’s?
Player A wants to carry Player B and fires RequestCarry to server with Player B as the param (instance form cuz it has less overhead). The server sets RequestMap[Player B] = Player A and the server then fires RequestCarry to Player B who fires AcceptCarry to the server, who then checks if Player B is in the RequestMap by RequestMap[Player B] and if there is then do your welding stuff.
Also if you are using a UI for showing the request, you can skip the whole rerouting by just setting the gui in the player gui of Player B from the server itself.
Player A wants to carry Player B and fires RequestCarry to server with Player B as the param
The server sets RequestMap[Player B] = Player A and sets the gui inside the player gui of Player B to be visible.
If Player B accepts the gui, he/she fires AcceptCarry to the server who then checks if Player B is in the RequestMap by RequestMap[Player B] and if there is then do the welding stuff.
And th reason we use it is to track which player has requested to carry which player. For ease of access, the index will be the Player who is requested to be carried i.e the player who got the request (Player B) and the corresponding value is the Player who offered to carry (Player A). It is done so that when Player B fires the AcceptCarry RE, we can directly check if anyone had requested to carry the said player, by indexing the RequestMap with the default arg of RE (player who fired the remote).
AcceptCarry.OnServerEvent:Connect(function(playerToBeCarried) --// playerToBeCarried will be the player who accepted the request
local playerWhoOfferedToCarry = RequestMap[playerToBeCarried]
if not playerWhoOfferedToCarry then --// no one had offered to carry said player, which means that an exploiter is firing the remote or if you have a timeout system, the request timeout had exceeded
return
end
end)
