SERVER FULL
gnoarch
Join Date: 2012-08-29 Member: 156802Members, Reinforced - Gold
Join Date: 2012-08-29 Member: 156802Members, Reinforced - Gold
ARGH!
Can we PLEASE for the love of Gorge get a server que system that is able to handle multiple people waiting for a slot?!
It is a real pain in the ass to join popular servers because if you are unlucky it can happen that you have to wait literally 1 or more hrs until you finally don't get "Server full" after just another fail attempt to join.
I really cant imagine this is very hard to implement, just make a fucking waiting list with players wanting to join for each server and let them join one at a time like BF3. PLEASE!
Can we PLEASE for the love of Gorge get a server que system that is able to handle multiple people waiting for a slot?!
It is a real pain in the ass to join popular servers because if you are unlucky it can happen that you have to wait literally 1 or more hrs until you finally don't get "Server full" after just another fail attempt to join.
I really cant imagine this is very hard to implement, just make a fucking waiting list with players wanting to join for each server and let them join one at a time like BF3. PLEASE!
Comments
Why not let players add themselves to as many queues as they like? Whichever server's queue they reach the front of first is the server they'll join. On all the other queued servers, when they reach the front and the server says "hey, your turn" and the client doesn't respond within a few seconds, they'll just get dropped from the queue.
A player can still only play in one game at a time, so they're not taking up any valuable resources by being in multiple queues. So why not let them?
:-/
They should just remove that and implement it themselves since they went so far as to build the rest of the server browser themselves. The server browser is just a mess at the moment anyway.
Because it will result in problems, like you join a server from one queue and then another server becomes available so you suddenly switch to that one, and so on. They would have to resolve this by having the client inform all the servers whose queue it joined that it has joined a server already. It is of course possible to do this, but so much more effort.
It doesn't seem like it would be substantially more effort than implementing some other queueing system. When the client joins a server, stop responding to server top-of-the-queue notifications. When a server fails to get a response from a client to a top-of-the-queue notification, remove the client from the queue. Simple.
I was trying to limit traffic, but I suppose this is quite an elegant solution since it's the client who must deal with all the traffic, not the server, so it doesn't matter. There will still be the issue of having to deal with timing out - how long should the server wait? It could be decided by the server owner I suppose but could make joining quite slow. However, there still is the extra effort of displaying to the client all of the queues which he/she is in. If you don't allow joining multiple queues then the UI can stay as it is, hence the extra effort, and given the dev team's UI skills, it will require A LOT of effort to get it right.
Traffic isn't really a consideration. The overhead required for something like this is negligible - less even than loading this very page in your browser.
The timeout length doesn't matter all that much. Anywhere between a few seconds and half a minute would be fine. The longer the timeout, the longer the server sits with an empty player slot... but even at the longer end, it's not really that big of a deal to have an empty slot for a short while.
Also, the client should probably respond to the top-of-the-queue notification with "thanks but I'm already in a game". That way the server would know to drop them from the queue immediately rather than waiting for a timeout (although you still need to implement a timeout anyway to cover the case where the client has gone offline), which would let the server fill the empty slot in a matter of seconds. Again, the overhead of this kind of query-and-response is negligible for both the client and the server.
Yeh I know, I've programmed sockets before. But having multiple queues will require quite some extra thread creation code which will require handling the different connections rather than just one.
You could end up in a terrible situation where there are lots of people in front of you in the queue and there is a 30 second timeout causing a very long unnecessary wait. Indeed, this could be a solution:
But anyway, this multi-queue feature is unnecessary and quite a bit of extra work. Just the single queue functionality would be excellent and not much work on top of what we have, depending on how well encapsulated the current code is.
The main reason for the mod is to allow admins to connect and manage the servers. As an added bonus, anyone that donates receives a reserved slot.
We do NOT force anyone to buy anything. Donations are 100% voluntary and are NOT required to play the game (unless off course the server is full)
We use 100% of the donations we receive to pay for our monthly hosting fees and hardware updates (just recently we invested into a 2nd machine, 4.65GHz OCd i7 3770K, that cost us a hefty pile of cash)
Please understand that we are running a lot of high performance servers that require a lot of maintenance and attention and until a better way of checking reserved slots is implemented, we have 2 choices.
1. Add a password once it's 24/25 (25th slot is there so reserved players can join) - not a good solution due to various password related issues (we tried this before, it was a pain and we got a LOT of complaints)
2. Leave it open and autokick player 25 if non-reserved.
So until we can check reservations BEFORE players are loaded 100% in the game, this method will stay.