Battlefield:Bad Company 2

[brugola.x]

aggiungo altri due video a riguardo della nuova Onslaught mode

YouTube - Battlefield: Bad Company 2 Onslaught Mode Part 1

YouTube - Battlefield: Bad Company 2 Onslaught Mode Part 2

[brugola.x]

stavolta mi sà che ci siamo davvero... patch in arrivo..



giusto per essere sicuri.. qualcuno di voi può provare a vedere se il gioco gli parte? Da quello che sembra proprio adesso stanno riavviando tutto quanto ed in giornata sarà disponibile il download della tanto desiderata patch. (la cui uscita era prevista 4 mesi fà).

[brugola.x]

mamma mia che parto.. si è "rotta" mentre aggiornavano i primi server ("per fortuna")... sembra una barzelletta
il gruppo di lavoro di DICE che stà seguendo il gioco stà facendo davvero una pessima figura, infatti la patch annunciata oltre due mesi fà e ripromessa più volte, la Client R8 and Server R13 si è evoluta nella nuova Client R8 and Server R15 (annunciata oggi)
sinceramente a mè, patch o non patch mi interessa relativamente, delle skin sulle armi proprio zero, il gioco in fin dei conti non gira poi così male, mi stà sulle scatole che non si possa comunicare con il team per via di un bug che colpisce il Voip, è impossibile accoltellare uno alla schiena.. e... qualche altro piccolo difetto c'è ma ad onor del vero alla fine questo BBCF2 tanto male non è altrimenti 300 ore di gioco (+100 di beta) non le avrei fatte
se la speranza è davvero l'ultima a morire Kalms (è il responsabile DICE per progetto BBCF2) oggi ha detto che:

After a lot of trials and tribulations, all versions of the game client has now completed QA successfully.
We will do no more testing on it.

All game servers will need to be taken down for updates. The maintenance period starts on Wednesday Jun 30th at 07:00AM (GMT+2). Most of them should be back up by 11:00AM (GMT+2).

During this time window, we will also release the new game client.

Check back after 11:00AM (GMT+2), and try out the new game client!

------------------

The client patch is approximately 890MB large. The list of changes is pretty much the same as is listed here. I'm going to write a post which explains some of the background behind the delays later tonight.

fonte EA UK Client R8 and Server R15 - Release info

ragazzi... se dovete giocare fatelo finchè siete in tempo, c'è il rischio che questo giro, con una folle patch da 890MB facciano esplodere il gioco
se ho capito bene.. per ora l'Onslaught Mod è stata accantonata.. ci dovrebbe essere la soluzione di qualche bug, una mappa nuova e più che altro mi sà che rimettono mano alle varie "zone" di gioco (Asia,Europa....) staremo a vedere e più che altro.. speriamo che non facciano tanti danni..

[brugola.x]

Steam ha reso disponibile la patch..




download in corso..

Updates to Battlefield: Bad Company 2 have been released. The updates will be applied automatically when your Steam client is restarted.

All game servers will need to be taken down for updates. The maintenance period starts on Wednesday Jun 30th at 07:00AM (GMT+2). Most of them should be back up by 11:00AM (GMT+2).

Changelog Client R8 Server15:

Server - Some potential sources for lag/rubberbanding have been eliminated
Server - The old reserved slots has been replaced by a kick-on-demand system like in BF2
Server - Log file for server admins: all remote admin interface commands/events are logged
Server - Log file for server admins: major server events + all chat messages are logged
Server - Idle kick is controllable
Server - Profanity filter can be disabled
Server - Teamkill-kick system is controllable
Server - Ticket counts and bleed rate are controllable per-level
Server - Infantry only mode available per-level
Server - Initial spawn delay and respawn delay are adjustable
Server - Server description can be up to 400 characters, and use "|" for line breaks
Server - Banlist can contain up to 10.000 entries
Server - reduced latency in packet handling

Admin Interface - fixed the player.onKill spam that occasionally happened
Admin Interface - ensured that player.onJoin events always report the player name
Admin Interface - events triggered when people spawn
Admin Interface - much more info on kills
Admin Interface - detailed stats are reported at end-of-round

Gameplay - Various minor level bugfixes
Gameplay - Helicopter handling has been tweaked
Gameplay - Weapon tweaks have been implemented based on PC public feedback
Gameplay - Tracer dart gun speed has been changed from 300 m/s to 200 m/s
Gameplay - Fixed technical hang when a crate was armed outside of the combat area
Gameplay - "Victory is near" message was shown for the wrong team on Valparaiso, this has been fixed
Gameplay - Countermeasures can be fired when driving a helicopter
Gameplay - The brightness of the pilot view in the Russian helicopter has been reduced
Gameplay - Advanced Spotting scope works better
Gameplay - Knifing people in the back works again (we backed out the change that we had done for Server R11)
Gameplay - Hit box for moving targets expands based on the speed of the targets movement
Gameplay - G36 now has crosshair when in Hardcore mode

Server Browser - Servers are sorted into 3 categories: Normal, Modified, Hardcore depending on their settings
Server Browser - Added support for retrieving update progress
Server Browser - Now refreshes information
Server Browser - Join queue system when attempting to join a full server
Server Browser - All settings are automatically saved between sessions
Server Browser - Pings are sent via an alternate mechanism, which should work for non-Administrator users as well

Client - Fixed DX9 issue, which likely caused graphics glitches and perhaps crashes
Client - Fixed some crashes
Client - Toggle/hold crouch is user controllable
Client - Toggle/hold zoom is user controllable
Client - Vsync bugfixed for DX10/DX11
Client - Rewritten how settings are written to disk; this should reduce/eliminate the spawn lag
Client - Fixed bug where a player could join a server before the stats has been downloaded causing faulty stats in "EOR- unlock progression"-screen
Client - New chat system allows chatting when dead (but not during end of round) and keeps a 100 lines log
Client - Improved Play Now functionality
Client - Removed K/D ratio and Skill Level filters in the leaderboards
Client - Any points you get while being dead will be added to your score
Client - Reduced negative mouse acceleration
Client - Increased health on the Cobra to match other vehicles
Client - More informative disconnection/kick reasons
Client - Support for Map Packs so PC gets future VIP maps at the same time as consoles

The Balance tweaks are as followed:

Slightly increased the damage of the UZI at long range.
The AKs74u now has more felt recoil when aiming.
The G3, VSS, and all SemiAutomatic rifles now settle slightly faster between shots when aiming.
The PKM, Type 88LMG, G3, An94, and 40mm shotgun have returned to their former glory.
Increased the damage of the MG3 to bring it in line with the rest of the LMGs.
Fixed a bug where the Saiga12 with slugs would do too much damage at long range.
Fixed a bug where the SVU would do too little damage at long range.
Fixed a bug where M95 rounds would not kill armored targets with headshots.





fonte SteamForum

[brugola.x]

vi voglio segnalare inoltre un interessante discussione aperta da Kalms (DICE)..

This is a story about software engineering, file formats, build processes, and packaging. All framed within the Project Management Triangle.


Developing a game is developing a software suite, and a dataset that will go along with the software. Users will use the software (= run the game executable) to manipulate the dataset (= use mouse/keyboard/joystick to control the game).

A good game requires that the capabilities of the software matches the dataset that is being created. The software is usually refined in parallel with the dataset. In order words, the game engine and the game worlds are tailored to each other, to some extent.

The programming side of making a game corresponds fairly much to developing other kinds of software. You usually use mature languages, standardized tools, and techniques which were pioneered back in the 1960s to create a set of source code, which when built creates a single game executable.

Creating the content is less straight-forward. Sometimes there are tools that do the job well (Maya, Photoshop, SoundForge, Cubase etc). For other kinds of content, there are no good tools, so the game developers develop their own.

Raw source format is not a good format for distributing a game engine to end users. One could ship the code as-is, but that would require people to have the right compilers and software SDKs available on their machines. Distributing the code in the form of a game executable is more practical.

Raw source format is not a good format for distributing the game content either. It is convenient for editing, but the game engine will usually want the content in a different format before using it. The raw source format is often bulky, and the conversion step is lengthy. Therefore, game developers usually create custom tools which "cook" the data -- convert it from source format to something that suits the game engine better.



Cooking is good, and bad.

No cooking gives you the advantage that you can change a source file, restart the game, and the effect happens immediately in the game. It is usually easy to figure out which files on-disk contribute to what in-game.

With no cooking -- or just too little cooking -- you get very long loading times. You usually get more memory fragmentation. You also lack mechanisms to validate the integrity of the data; if you want to see that it's consistent, you have to play through the full game and exercise all aspects of the game.

Cooking gives you the advantage that you can do lots of sanity checks on the data before even starting the game. You can improve loading times a lot (especially off media with slow seek times such as DVD), and you get less memory fragmentation.

You can also create extra datastructures, which improve runtime performance. (A good example of this is the BSP & PVS trees that were used in FPses back in the 90s.)

With too much cooking, you find that it is difficult to change anything when data already has been cooked. If you want to edit just one tiny little detail, you have to re-cook ALL the data. It is difficult to tell which files on-disk contribute to what in-game.


Now let us consider the Frostbite engine and where it comes from.

It was initially used to create BFBC1. This game was released only for consoles. This means that the team which developed

BC1 had to do a certain amount of cooking - mainly to avoid excessive load times and memory fragmentation. The hard memory and performance constraints of running on a console also made it more important to pre-compute some things, and to package data into suitable archives.

With this foundation, we essentially had a game engine which solved a lot of time-consuming problems for us when we began on BFBC2 PC. Loading times would be under control, it's easy to figure out which files go into which archives, and which files/archives belong to which level. These are things which are often overlooked when not using a game engine that has been used to ship games on DVD.

We also wanted a way to automatically patch the game. Making an auto-patcher that works properly under Windows XP, Vista & Win7, knows about limited users & UAC, and can handle restarting mid-way through a patch at all takes a huge amount of time.

Therefore we took the auto-patcher from BF Heroes and modified it slightly. Voila, the game could now pull down updates from the internet and apply them to its own datafiles. We were all set.

Or so we thought.



Some complex systems seem simple on the surface; it is only when you look under the hood that they turn out to be tricky.

The tools which "cook" the game's datafiles takes in a set of original files, which are roughly 80GB in size. Most of the files here are organized by function ("this is a mesh, this is a texture, this is an animation, ...") rather than location (on which level[s] it is used). The tools will process the dataset once per level, extract the subset that applies for the current level, and convert it to a format suitable for the game engine.

This allows the tools to do some per-level precomputations easily; for instance, since all the pixel/vertex shader combinations that will be used throughout the entire level is known, the tools pre-generate all these combinations and store them in a "shader database". (BF2142 generated & compiled the shader combinations during first load - that's one reason why first launch of a level was very slow there.)

After this is done for all levels, there are a bunch of archives for each level. This is ideal for quick loading times and no memory fragmentation, but it wastes diskspace unnecessarily. The result is probably about 15GB in size.

In order to make a better tradeoff between diskspace and load times, an extra processing step has been added; all the level-archives are compared, and any datafiles which appear inside many of these level-archives are moved to a level-common archive. So when loading a level, everything inside the level's own archives and the level-common archive has to be processed. This reduced the total data size down to about 6GB.

This technique allowed BFBC2 to fit on a DVD, both for the console and the PC versions. It is not perfect by any stretch, but dealing with these large amounts of data is time consuming, and therefore you don't try every idea under the sun - rather, try what seems most likely to work first, and then keep on until the end result is good enough.



So this is all awesome when shipping the game. Where do the problems begin?

When you begin creating patches.

First off, it turns out that the tools that "cook" the data don't produce binary-identical data all the time. The result after cooking is always functionally identical, but the bit-content may differ slightly. Items in unordered lists change order, uninitialized fields contain random data, that sort of stuff.

Why didn't this get caught sooner? Because you only notice problems of this kind when re-cooking the same data several times, from scratch. And re-cooking all BC2 data takes over 48 hours for a high-end computer. And locating & correcting all places where cooking isn't deterministic down to the bit level would take a lot of time (both calendar time and effective development time). Perhaps that time is better spent elsewhere?

So. If different "cooking" runs produce slightly different results, it is suddenly difficult to look at version A and version B of the data and answer the question, "what are the differences between these two datasets?". It's easy when looking at the source data, but when looking at the cooked data there are a lot of changes which have no effect on the final game experience.

There are about 40.000 source files, and this results in well over 100.000 cooked files. Going through those by hand is not an option. Writing a perfect filter, which knows which differences are benign and which are for real, will take as much time and effort as making the cooking 100% deterministic. Neither that is an option.

So you make a filter which does something in between; be smart, create rules for the file types you know about, and when in doubt - assume that the change is for real. Err on the side of caution.


Then you realize that those shader databases were never designed to be extendable. What happens when a new object is added to a level in a patch? Its mesh & textures are included, no sweat, but what about the shader combinations? How does one create add something to the shader database, when the shader database is an opaque binary block whose entire contents may change when just one object is added to the level?
(One shader database is about 5MB. There are three shader databases per level - one each for DX9, DX10 and DX11.)


And finally, the patch system itself. Yes, it can replace portions of files on-disk. But due to its heritage (from BF Heroes), it is not able to open BFBC2's archive files and apply differences to individual files within the archives.
The only straightforward way is to make all patched-in content arrive in archives on the side of the original archives.



Given the above scenario, we end up with the situation that we have today.

Each patch gets larger than the previous, because the game drifts ever further away from what was shipped on the DVD. Changes that require shader database updates make the patch balloon in size. And we have to be careful and clever when selecting which file types to include and which to ignore when creating the patch.

And that's where we finally ran into real problems. It was too difficult for one person to identify which changes were required and which were not, and how to update the patch generation process to accommodate the latest set of changes. Most of the delay of Client R8 was because there are very few people at DICE who have the in-depth knowledge of the far-spanning corners of the game engine *and* the cooking tools *and* the patch generation process, to work out what is going wrong, why, and how to fix it.

The new content did work a long while ago - but the patch was back then approximately 7GB large. The patch had to get down to less than 1GB, or else some customers in Australia and South Africa would not be able to download it due to bandwith caps.

[As an aside - how about distributing the patch as an installer, for those who prefer that option? We would love to do so, but creating an installer that does anything out of the absolutely most ordinary installer-y requires ridiculous amounts of development time.]


I think that we have a proper Client R8 patch ready for release, but the approach we have been using thus far has been taken as far as it can go. (A bit too far, considering the delays.) We want to continue supporting the game, but if we want to change anything else than the game executable itself, we will need to spend time on figuring out how to do so with a less error-prone patch generation procedure ... and preferably without generating as large patches.

This stuff keeps me awake at night. What are your demons made of?

link alla discussione originale su EA Forum UK


il gioco ora risulta essere aggionato alla v.553292

[brugola.x]

976,3MB di patch ed a mè è filato tutto lisco, dopo 1 oretta di game posso dire con tranquillità che il gioco a mè gira bene, e grazie alla patch ora posso anche accoltellare la gente alla schiena


..

[brugola.x]

se già non lo conoscete vi vorrei segnalare un utilissimo configuratore per bbcf2, è appena uscita una nuova versione per aggiornarlo alla patch ed ora funziona in modo impeccabile





si tratta di un configuratore "ufficiale", questo post proviene infatti dal forum ufficiale EA UK, problemi di hack o ban neanche a parlarne, è proprio un altra cosa.







=EM= Clan Certified BC2 configurator -v1.12b

Hello everyone. VERSION 1.12b IS RELEASED

Version 1.12 is a big step forward. It supports the latest client update (patch). But more importantly, the program now works for XP users! The reason behind the crash is insane: AN ICON (image) that should be shown in the upper left corner of the window caused the crash! Win7 and Vista can resize them but for XP it was too large so it crashed on launch!

My initial goal was to build a tool that would integrate all of the settings that are available in the .ini files in one, user friendly program.

There are quite a few options not available via the ingame configuration and I've made all of them (including the available ones) configurable, with tool tips that will explain in detail what each setting means.

If you screw something up, don't worry, load defaults, or UNDO the changes you made until that moment.

The main reason I created this was PRACTICE and FUN. I am still a beginner in programming so I had learnt quite a few things while making this program.

There were a few bumps on the road and a few bugs but, toghether with my clan, I've managed to overcome them. So all I can say in the end is: configure your game the way you want it and then enjoy it to the fullest.

Sure, there are other utilities with a similar function roaming around, but I wanted to make the most integrated one, with most options and with a clear yet user friendly interface.

Development of this tool took 2 weeks + a week of beta testing and fixing a few bugs.

Version 1.1 is up, download it from the link below!



MAIN FEATURES of the program:
-Disable "negative" acceleration and configure the sensativity values individually for on foot/vehicle/stationary/helicopter
-Presets for configuring the sensitivity settings with ease
-Restore last "backup" allows you to restore and load previously backed up settings in one click
-FOV configuration AUTOMATICALLY calculates the HORIZONTAL FOV for you
-Tweak those hidden settings (Bloom, Speaker size, directx mode, Graphics in detail)
-Lists with all available resolutions that your PC can display with the ability to set a custom resolution (with refresh rates)
-Voice Over language options have an information line that tells you EXACTLY how your enemies/squadmates will sound
-Sound settings have preset values that you can select by choosing the type of your CPU
-When you save your configuration you have an option to create a backup - you won't loose your settings by messing around
-Most of the commands have tooltips on mouse over that explain their function in detail
-The software automatically detects your BC2 configuration folder and your game folder so you don't have to configure anything and can launch it from anywhere
-Auto scales the application window in order to fit all of the controls on resolutions equal or below 1024x768

Usage tips:
HINT 1: Mouseover on the TITLE of any command to get a tooltip that shows you in detail what each command does.
HINT 2: To use the negative acceleration tweak click on the YES button, set your desired sensitivity settings and click the SAVE button (it will save all of your settings, including the tweak)
HINT 3: To restore the old mouse sensitivity and acceleration settings click on the NO button in the "Input" tab and again click the SAVE button OR use the RESTORE LAST BACKUP command.

Screenshots (v1.1 final):




DIRECT DOWNLOAD LINK AND HOMEPAGE (NOT YET UPDATED TO 1.12!): =EM= CONFIGURATOR HOME

MIRROR 1 DOWNLOAD LINK: MEGAUPLOAD - The leading online storage and file delivery service

MIRROR 2 DOWNLOAD LINK: EM BC2 Configurator 1.12b by psycho063.rar

Software Requirements:
.Net Framework 3.5 (If you have windows 7 you allready have it):
Download details: .NET Framework 3.5

Updated DirectX:
Download details: DirectX End-User Runtime


Instalation:
1. If you have windows XP or don't have .net Framework 3.5 download and update it from the above mentioned link
1a. XP users also need NET FRAMEWORK 2.0
2. Unpack the Bad Company 2 Configurator.exe anywhere and run it.
3. If you get a directx error, copy the .dll file to the location where you copied the .exe OR download the directx update (link above)

Finally, for the more paranoid users, virustotal report: Virustotal. MD5: 997b0db3f1d70a97296a431becaa9b7b

ENJOY and post comments/suggestions

fonte EA forum UK

si ringrazia psycho063 ed il Clan =EM= per aver condiviso il configuratore

[brugola.x]

è disponibile da oggi il Map pack 3

Laguna Alta, Squadrush - (code name "mp_003sr")
Nelson Bay, Squad Deathmatch - (code name "mp_008sdm")

gira che ti rigira alla fine sono sempre le stresse riciclate

[brugola.x]

Dopo il rilascio di ieri del VIP Map Pack3 per PC, è in arrivo il 4...
Per le varie consolle il nuovo Pack 4 è uscito proprio oggi.. noi per il PC tanto per cambiare aspetteremo qualche giorno in più

VIP Map Pack 4

port valdez CQ

atacama desert RUSH

Nelson Bay CQ (not sure about that)

video YouTube - Battlefield: Bad Company 2 - VIP Map Pack 4


FONTE : zh1nt0 su EA blog


PS da quanto di intravede nel video, ci sarà la possibilità di utilizzare qualche mezzo in più che prima era "riservato" alla modalità single player.. (parlo della jeep che si utilizza nella missione della nave nel deserto)

[brugola.x]

VIP Map pack 3

Laguna Alta, Squadrush - (code name "mp_003sr")
Nelson Bay, Squad Deathmatch - (code name "mp_008sdm")

VIP Map Pack 4

port valdez CQ

atacama desert RUSH

Nelson Bay CQ (not sure about that)

perchè mai ci avranno fatto aspettare così tanto per rilasciarle?




come si può vedere quì sopra (la lista di sinistra), le mappe annunciate di recente (sia SP che MP) sono presenti nella cartella d'installazione del gioco sin dal giorno del rilascio... potevano anche rilasciarle prima...