I have a queue system here on the forums and I’m having an issue of having “ghost users” as I like to call them within the queue system. Essentially, I am deferring the players from connecting and upholding them in the queue system. The issue is, when I defer them, they don’t seem to trigger the playerDropped event when they stop connecting to the server? In turn, this then creates them essentially as a ghost user. Currently, I loop through all of the users in the queue every 40 or so seconds and remove the ghost users from the queue by checking if GetPlayerName(user) comes back as nil (which indicates they no longer exist).
Is there any way I can detect if a player quits connection whilst being deferred?
They do get a source, however it seems to be a temporary source number and not like an actual source number since they are “technically” not connected to the server yet. From what I’ve noticed with playerConnecting events, using GetPlayerName() will return nil within the event when the source goes nil, then this will break the connecting code and stop the event entirely… If there is a way to catch this, it’d be really helpful. I’m thinking maybe a thread being created and checking the source to make sure it’s still valid?
playerDropped is only triggered for real players, I’m not sure if cancelation/otherwise timing out even has anything exposed to monitor such state (and therefore am surprised nobody asked about it before?).
Either way, the current method of using playerConnecting might be vanishing soon and be replaced by something more reliable, structured and less broken/abusable, with probably built-in queue logic if I can get people to test such behavior… I’ve not even had a server with more than 2 players on it let alone a full server so I’d be unable to test a queue system, it might very well be that everyone is doing such loops and nobody even bothered to ask about such… would explain why existing ‘queue systems’ are all extremely unreliable and not even getting structured data right.
Yup, that’s the issue I am currently having with my queue… People can spam connect and cancel buttons to glitch themselves through the queue essentially. From what I’ve made notice of, the source variable or functions using it will return nil when called upon in the playerConnecting event. Effectively, it seems as if the playerConnecting event continues code execution even if the player cancels…
What would be really nice is a handler for if they clicked the cancel event, so this could be caught. Whilst a better connection event would be nice, I think a simple handling event for the cancelling of a connection would suffice just as well.
Thanks for a quick response bubble. I’ll keep troubleshooting to see how I can stop people from abusing it
I had asked about this back in '18 when developing a queue system and ended up going with a solution like you are describing where an endpoint check is made for players in queue and if that is null then I done the deferral on that event and let it close.
C#
if (source?.EndPoint == null)
{
deferrals.done($"{Configuration.messages["Canceled"]}");
I believe I was having problems with the same player being able to queue up again after they canceled if the original player connecting event was still in progress in the queue when they connected again.
