Server R20 is due on Thu Mar 29th

As you probably have seen elsewhere, there will be a client update on Thursday March 29th, 09:00 UTC.

This update will be accompanied by a new game server.

At the aforementioned time, Battlelog will go down for a while. The RSP companies will begin updating servers at that point; you can expect it to take some hours before they have updated all servers.

Non-updated servers will not be visible in Battlelog after the downtime.


Most of the changes in the game server are balancing and modifications done to support game client changes. The set of changes reported here is fairly up-to-date: http://blogs.battlefield.com/2012/03/game-update-will-drop-on-the-27th-of-march-for-playstation-3-xbox-360-and-pc-will-come-soon/ [blogs.battlefield.com]

However, we have done some additional changes to the PC game server operation since that list was compiled. Here is the completed section:

Fixes - PC Server operation
- Having the same map occur multiple times in the maplist now works properly
- If adding a new map to the servers maplist after a clear and then running "mapList.runNextRound" the server will ignore any remaining rounds on the map that it still run since before the clear and move to the new first map in the list. The server will now have reset the current rounds per map and run the map in the list for the number of rounds stated when adding the map.
- Maplist can contain up to 1000 entries now
- mapList.list will return at most 100 entries. To get the entire list, perform mapList.list repeatedly with increasing offsets (like banList.list)
- The locked-in-place warm-up has been replaced by a warm-up where players can move around, shoot, and take objectives; scoring is disabled during warm-up
- The Conquest Assault layouts on Back to Karkand maps have had the gamemode names changed to reflect that Conquest Assault is a gamemode in its own right
- vars.serverDescription is documented (it shows a string on a server’s detail page on Battlelog)
- vars.roundLockdownCountdown can be used to control the pre-round timer


The renamed Conquest Assault modes will cause initial confusion. The 3rd party admin tools don't know about this change yet, and existing Maplist.txt configurations contain the old names, so this is something that server administrators need to be wary of. It is a one-time change though, and it's worth it in the long run.

The latest server docs are available here: http://static.cdn.ea.com/dice/u/f/bfbc2/tmp/BF3_PC_Server_R20_926998_Docs_ServerAdministrator_v2.zip [static.cdn.ea.com]

We were initially intending to release on all platforms at the same time. The QA process & stabilization phase took different amounts of time on the different platforms - so we decided to do the next best thing: to release on each platform as it got properly finished.

RandyZie said:

MikaelKalms said:
We were initially intending to release on all platforms at the same time. The QA process & stabilization phase took different amounts of time on the different platforms - so we decided to do the next best thing: to release on each platform as it got properly finished.

But honestly this patch should have been broken up into 3 sections, each released as they were finished. It's so easy to patch on PC, why not take advantage of it?

We generally track the code and content where the actual "dev work" is done in a single repository. This way, changes that are done to one platform will also apply to other platforms as well by default.
The main reason why we do this is because we want most changes to apply to all platforms - and it saves development time.
If we would have had three repositories, each platform could have been done totally independently of each other, but there would be much less synergy effects between platforms. Our overall velocity (progress per month) would be lower, and the work that we have accomplished during the 5 months since launch would have taken 6-7 months instead.

So what we do instead is to work in a shared repository when work is going quickly. Then, at some point during the stabilization phase, we split into one repository per platform (because fixing a problem that occurs only on one platform can destabilize another platform through obscure knock-on effects). Stabilization took longer than expected for two platforms, thus release on those got delayed.


Another way to look at this is: there is a fixed number of people available to work on all platforms combined, and we work this way because it is the most efficient way we know of working (if you measure our progress over multiple releases).