bluesteel

You have to load the beta folder as a mod, otherwise it will not be used. Something like -mod=Expansion\beta;Expansion\beta\Expansion

Suma, can you quickly comment on the current state of the separation of simulation and renderer? According to the changelog the interpolation went live a few betas ago, but so far I have not noticed any of the significant framerate improvements that this seperation should bring with it.

I'm still only getting around 8-10fps in Benchmark 2, no noticable change from previous builds. Does "[82654] Optimized: Visual state interpolation fully enabled." only mean that the interpolation part is enabled, but not yet the separation of renderer and simulation? With a full separation of the simulation process I would expect significantly higher frame rates.

I have just compared screenshots taken from 82128 and the last patch (79384). There is absolutely no difference in object draw distance between these versions. Tested on Chernarus, standing on the Green Mountain tower. But if I remember correctly, there was an object draw distance increase a while back in one of the previous patches; even if I can't find any mention of that in the changelogs.

This version does not yet seem to have the simulation completely "disconnected" from the renderer, which seems to be the plan if I read Suma's blog post correctly. I still get only ~12ps in the "Benchmark 2" mission, which appears to be extremely limited by the simulation being coupled to the renderer. GPU usage is around 15% in that test. If everything goes to plan, I'd expect to see way higher framerates in that particular test. Maybe Suma can give us an overview which features are de-coupled from the renderer now and what to expect in the future. Last beta he mentioned that distant units were decoupled, I wonder how the status is in this version.

I have done a few tests with the ArmA 2 multicore support and have to come to the conclusion that there is theoretically room for improvement. My test scenario is the beginning of campaign mission "Razor Two". This is a large-scale mission, so a lot of AI-scripts should be running in the background. For the sake of testing CPU-performance, I lowered the graphics-settings and set the resolution to 800x600. That should eliminate any GPU-related bottlenecks. I am just standing at the beginning of the mission, looking straight ahead. System: Core2Quad Q6600, OC'ed to 3.4GHz 4GB DDR2 Memory GeForce GTX 260 (192 shadercores) Windows 7 x64 RC No background apps like virus scanners, firewalls,... The framerate hovers around 40fps, CPU usage never goes over 50%: Pressing Esc to pause (this should also pause the AI scripts) I get 60fps and the CPU usage changes, but still does not go over 50%: For comparison reasons, if I go to the same position in the editor (empty map), I also get the 60fps from the second example. [before someone asks, this is NOT V-sync-limited, I get 80-150fps when I look into the sky] What is interesting to note here is that even with the higher CPU load of the AI scripts in the background, the CPU usage never exceeds 50% (2 cores). What I would expect here is the CPU usage going up with increased AI activity instead of the framerate going down. In a perfect world, all the systems would run in independant threads. So there would be totally independant threads for AI, audio and so on besides the renderer. In that case the renderer could always run at full speed, while the other systems just run on the other available CPU cores. The framerate would only go down, if the other systems actually use up all of "their" CPU cores and the renderer has to sacrifice some of "his" core. I know this is simplified, but otherwise it gets too complicated to explain quickly. The Real Virtuality engine was obviously not built with multicore-support in mind, at least not when it was started 10 years ago. So I am impressed by the amount of multithreading that BI was able to squeeze in here. At the same time I am curious if there is a simple way to enable even more parallel processing; the fact that performance is capped at 50% CPU usage on a quadcore suggests that there is a small bug somewhere that is limiting the true potential.

You are missing the actual beta data folders in your mod line. It should look like this: -mod=Expansion\beta;Expansion\beta\Expansion;@CBA;@ACE;@ACEX;@ACEX_SM;@TRFW;@TRRW;@TRTV;@TRWV;@Tracers;@JayArmA2Lib;@ACRE

Who said there was no manual for ArmA 2? http://store.steampowered.com/manual/33900/ I have a similar version as PDF directly in my ArmA 2 folder. I bought the German download-version when it was first released, the manual-file came with the installation.

You can install the official 1.05 patch over the Steam version aswell, according to the download page: "This update IS compatible with ALL previous ARMA 2 versions as well as with the STEAM version. " http://www.arma2.com/support/updates/folder.html?lang=en

Thanks for the quick fix (and for the campaign itself in the first place!) One thing I noticed - the included "EW_hotfix_readme.txt" file is empty (0kB) in the archive.

Still can't confirm the water problem. I changed object and terrain detail to max, and while the water looked a bit more "wavy", the framerate was still not affected - except being generally lower because of the higher detail settings. An exact repro and system specs would be helpful to track this down...

I tried to repro this, but failed. Can you provide us with a bit more information? Where exactly (island/coordinates) did this occur? Which graphics settings do you use, do you see a difference if you change some settings around? And most importantly, what are your system specs? I think most interesting would be OS, graphics card and installed graphics drivers. Also try updating your graphics drivers, this sounds like something that could have been fixed on that front. I tested this on both Utes and Chernarus, looking at the shoreline in different places did not affect my fps in any meaningful way. I'm using Win7 x64, Nvidia GTX 260 with drivers 195.81.

Actually, if you add both these lines, there is no need to set the file to read-only: postFX=3; HDRPrecision=32;

Vista got its bad reputation for two things, bad driver support when it was released and some pretty ugly bugs/performance problems in the release version. Vista SP1 performs much better, and while you're at it, install SP2 directly aswell. Nowadays Vista is much better than it's reputation, but that only works if you also update it to the latest version. The unpatched release-version is still as bad as they all say ;) If you don't get SP2 offered over Windows Update, try going here.

I think the average user expects this choice to be remembered by the game, since this is how most other games work. If I set a game to windowed and click save/apply, I usually expect it to stay windowed until I change the setting again, no matter if I restart the game or not.

The 8 gigs are what's causing this if I remember correctly, try adding "-winxp" to your commandline/shortcut. If you rightclick your ArmA 2-shortcut, make sure it looks like this: "[...]\ArmA 2\arma2.exe" -winxp The [...] is a placeholder for the relative path on your system. Important is that the "-winxp" exists outside the quotation marks.

The new settings for max_frames_ahead control how many frames the CPU can prepare while the GPU is still busy with the current frame. Typical values are between 0 and 10, anything higher is not practical. Let me explain: Think of this value as the amount of frames your GPU - and the picture you see on the screen - is late with processing. While you see frame #10, your CPU is already preparing frame #20 to be rendered. Since your mouse inputs are tied to the CPU, this means that when you finally see frame #20, your mouse input will be what you did 10 frames ago. If you set the value to 1000 and your framerate is 30fps, then you enable your CPU to hypothetically prepare so many frames ahead, that the picture on your screen is over 30 seconds old. That equals a mouse lag of half a minute. That is why values over 10 are not practical, as they would induce a lag of a third of a second (333ms) at 30fps already. Most likely other factors limit this anyway, I doubt the system can build up a buffer of 1000 pre-computed frames that wait to be sent to the graphics card. Personally I can sense the difference between values of 1 and 3 already, with 3 introducing slight but noticable mouse lag. This is using the option in the NVIDIA control panel, but I assume the ingame controls will behave similarly. Most likely the game can not even override the value you have set in your ATI or NVIDIA control panel, so values larger than what you have set up there should will not have any effect. Only lower values should be able to do any difference.

I found the problematic tree. I get around 30fps in that area, but when I am close enough that the tree fills my view completely, it drops down to 20fps. I think you are right, Ohara, I found a almost linear resolution dependancy. 50% 3D resolution gave me 45fps while looking at the tree, and 200% resolution gave me something around 13fps, starting from 20fps at my normal resolution (1680x1050). I believe the only fix is to replace that particular tree model with a less detailed one, one with less overlapping layers.

Well, we had the exact same situation with ArmA 1. The German version was released early, was released by the same publisher as ArmA 2 and was locked into German language in the beginning. But after a while one of the official patches opened up the language options, and we could choose the language in the options menu. So I believe it is valid to ask BIS for a solution, since they provided one for ArmA 1 as well.

Overclocking from 3.0GHz to 3.2GHz increases your CPU speed by 6.7%. If your CPU is your performance bottleneck and not your graphics card, you will gain 6.7% fps. So if you have 30fps right now, you would get 32fps after the overclock. If you had 60fps, you would get 64fps. But keep in mind that this only applies if your graphics card is not slowing you down already, in that case increasing CPU speed will not have much effect at all.

Or, in other words, the server should only accept connections when the player limit has not been reached yet, and refuse connections once it has been reached.

Have you updated ArmA 2 manually, or did you get the update over Steam? It says in big red letters on the patch download page not to use the standalone patch with the Steam version...

What benefit would you have if BI picked one of the beta-builds and labeled it "official beta"? What do you expect of an "official beta"? It would obviously not be more stable than the other beta builds; "beta" means that the code is not fully tested and potentially unstable. After all, the whole point is to test for bugs and get community feedback on any changes before releasing the next official patch version (1.04). Releasing an "official beta" would not help developement either, since it would split the testers into two camps, one that uses the "official beta" and one that uses the newest build. Since testing is only useful if done on the newest build, this would benefit noone in the end.

I haven't tested it yet, but this also depends if there is a global value involved or if this is something inside the addon-file that contains the C-130. The beta patches contain almost no addon-files, so any change they make to the models and attached variables will not show in the beta patches that we receive right now. But that does not necessarily have to mean that they did not fix it internally. EDIT: Ok, I just tested it. I didn't test it in the release version, but it seems I don't have to. If you mean that it is nearly impossible to turn the C-130 at all while on the runway, then yes, that is still there in the current beta (59025). But as I said above, it might involve a change to the corresponding addon-file, and those are not present in the beta patches.

Just tested shooting MGs, no problem there anymore. Then I placed two MG squads (BLUFOR/OPFOR) at a distance from each other and gave them orders to "DESTROY" each other. I was listening from a couple hundred meters away. I saw tracers and muzzleflashes flying around, but I did not hear nearly as many shots as there should have been. But maybe I was a bit too far away, could barely see the other guys with bare eyes. EDIT: Tested with 59025.