Joined: Oct 02, 2011
Sun Jun 10, 2012 4:29 pm
I'm quoting this guy who has one of the USA servers running the new maps ... one of the few with players on, from what I can tell.
Anyways, DICE screwed up the queuing element for this game, and R25 is supposed to fix it. I ticketed Branzone about disabling the queuing a few days ago, because of the problem - and yah, we did get full last nite, but no TBDer coming on had any problems joining, mainly coz they joined when it wasn't full, so no complaints about a full server and not being able join. - stufz
As some may know, the GSP Multiplay did testing of the reserved slot/queue system and provided feedback to EA.
The conclusion of the test run was that it made it impossible to kick/move/kill some players from time to time, and it would lag procon out because all of the plugins start failing when data is returned corrupted/ actions aren't taken as they should be upon command by the server.
So EA had all of these test results, all the tests were called off due to these issues.
Then patch day, we had the same issues. Come to find out, they included the reserved slot/queue system that had been tested by Multiplay into the release WITHOUT FIXING THE ISSUES.
The only way to fix this BUG currently is to disable queue's completely or surrender rcon control of the server. And that is what EA has recommended until they can push out a patch to fix it. (Hold your breath)
Additionally, they didn't tell any of the GSP's about this error, Multiplay recognized the issue immediately and refused to allow queue's on their server upon release...but the rest of us had to troubleshoot the issue all night with the GSP and waste both of our evenings because EA refused to tell anyone of the issue in advance. (Server must be reset for change to take effect)
So don't be surprised if our server comes back up with no queue soon, thanks to the PREMIUM CONTENT....until EA gets around to fixing the problem....only thing is, they can't do it right now cause they are busy counting all the money they made of selling the PREMIUM CONTENT.
They have stated that they will not be fixing this issue in the next patch....but maybe in the one after that......
Yes, we have no choice but to disable queue's but that also kills servers generally...and will do damage overall the longer it lasts.
Server R24 has a bug where players who join via the join queue lack GUID. We will try to have this fixed for either R25 or R26 (depends on whether we can complete QA testing on our current internal build).
No ETA for Server R25/R26.
We've done some changes to reduce/eliminate the 'wrong slots' problem. We don't know the root cause of it yet.
Ah ! this gets better ! check this out :p
I'm pretty stunned this problem has not been fixed by DICE.
This bug has been known since we did a special R21 test with Multiplay for DICE. That was back in March....
Last week we did another VIP slots test with R24: conclusion -> Bugs still there.
I understand Battlefield Premium is a big launch for EA / DICE.
So, EA needed to roll out this update to get Premium members jump queues. But it's totally unacceptable we don't have all the GUID's and IP's of players when queues are enabled.
Multiplay has disabled the queues to eliminate these bugs (advised by DICE earlier), but appearently DICE does not like the fact more and more GSP are turning off the queue system, making the Premium Queue Jump useless.
Now it seems DICE is urging GSP's to turn this option back on.
In my option a bad decision, as the problems with this build are too big.
More info here:
More problems will arise if you use plugins which use the punkbuster player list function (pb_sv_plist) to get the players. (Procon itself also uses pb_sv_plist to get the player info IIRC?)
The players without a PB_GUID won't appear in that list, they are "ghosts".
You may check for yourself and see how many players "pb_sv_plist" outputs:
It will be the players in the server minus the players without PB_GUID's
Then next problem may occur:
Players banned by Punkbuster may be able to play on your server, because there is no PB_GUID to check against the banlists.
Another problem when queuing is enabled:
Battlelog will show incorrect server slots after a while. So this makes the Adaptive Server Size plugin useless when scaling down the slots to get more players in. The server needs to be restarted to get rid of this bug, but after several hours when server reached maximum slots capacity the bug will be there again.
So to recap this week of forward/backward, silent updates, 2 new patches and general confusion, here's the official take on it by Kalms at Battlelog - stufz
06.07.2012 01:41PM , edited 06.07.2012 01:48PM by MikaelKalms
there has been a lot of confusion around the join queue over the past week.
Let's first start with a discussion around the join queue itself. We have two old mechanisms.
The old Join Queue mechanism
This is a straight queue, with no prioritization. The first person to join the queue will be first to join the server when there is room available.
The new Join Queue mechanism
Players are divided into three groups:
1. Players on the Reserved Slots list
2. Premium players
3. Normal players
The "Reserved Slots" list is a list with player names. The list is stored locally on each server, and managed by each server administrator.
When a player attempts to enter a full server, the player will go into the queue. Later on, when a player leaves the server, one player from the queue will be let onto the server. The server will first pick a player from the Reserved Slots group; if that group is empty, one from the Premium players group; lastly, one from the Normal players group.
If there are several people in a group, the player who has been waiting the longest in a group has precedence.
In addition to this there is the "aggressive join" setting. If Aggressive Join is enabled, then if a Reserved Slots player joins the queue, a user on currently on the server will be kicked to make room for the Reserved Slots player.
The Aggressive Join setting does not apply when Premium or Normal players enter the queue.
It is common for clans and communities to use the Reserved Slots + Aggressive Join together; those who pay the monthly bills or otherwise support a server are on the list, and are guaranteed to be able to come in and play on their server. Others can play on it too if there's room.
(This is pretty much how the BF:BC2 queue worked.)
Bugs in the new Join Queue mechanism
There are two known bugs in Server R24 (which is currently running on all servers).
The first, and biggest, is that players who enter via the join queue will not get GUIDs. Also, "player.onJoin" events are not sent. This confuses some third party admin tools. PunkBuster does not always display these players in the "pb_sv_plist" output either. So-called 'ghost players' are caused by this as well.
We have identified the problem and developed a fix for this earlier this week. We expect it to go live sometime during next week. Until that time we recommend that server administrators who have problems with the new queue do not run third-party autobalancers or other similar scripts.
The second is that servers sometimes don't display the right number of max players on Battlelog. This seems to happen only to servers which run "adaptive server size" plugins. We are still investigating this. It is probably not related to the Join Queue at all, but the reports arrived at the time when we switched to the Join Queue mechanism - so, it's worth mentioning.
So which Join Queue mechanism is being used right now on the servers?
Most PC game servers, except those operated by BrainStorm Network and Multiplay, use the new mechanism. Once the GUID problem is sorted, all servers will switch to the new queueing mechanism.
I hope this answers most of your questions.
Regarding documentation around the Reserved slots, you can find the pre-release docs for Server R25 here:
(Server R25 is due for Monday-Tuesday next week. It adds support for Close Quarters maps.)