RemoteEvents will automatically pass the firing client as the first argument. Knowing this, when you connect to a RemoteEvent from the server, you will already know who the player requesting to leave the queue is by Player object. Accessing their name property will give you their username.
local function serverEvent(player)
print(player.Name)
end
remoteEvent.OnServerEvent:Connect(serverEvent)
It would be a matter of using this given name, searching through your table and if they’re there, removing their name from it. If you have an array for playersInQueue, you can use table.find to see if the player name exists in the table and if it does, pass what it returns to table.remove.
Some details about why the above works: table.find finds a value in a table and if it exists, returns the position of the value in the array as a number. table.remove can only remove by position, not by value, but table.find gives you the number you need. Therefore, it’d all come down some code like:
local playersInQueue = {"foo", "bar", "qaz"}
local function serverEvent(player)
local playerName = player.Name
local queuePosition = table.find(playersInQueue, playerName)
if queuePosition then
table.remove(playersInQueue, queuePosition)
end
end
remoteEvent.OnServerEvent:Connect(serverEvent)
In my own personal experience, since the advent of CollectionService, I would always use it for systems like this. Assuming that you’re making this for one of those story games or a similar teleporter, players entering the queue would be tagged with “InQueue” or something and players wanting to leave would fire a remote that removes the tag. When it’s time to teleport, GetTagged on InQueue and pass it to a teleport method.
Only difference with the above method would be having to generate or fetch (have not tested memory addresses yet) the array every time I want queued players for anything and there’s an insignificant amount of extra memory because of serialising those tags on instances. Good stuff otherwise.