troop

Manzilla; I'm using these Mods.. -mod=@FDF_Sounds;@MAPFACT;@TrueMods[only TrueView] ..and all manual Savegames are CTD. Just completely unreliable. (It may be in early stages of the mission, that 2-5 manual saves *do* work;..just after some more, the manual savegames fall apart..reason unknown) Autosaves after End Mission work ok, though. If I 'End Mission', an Autosave takes place. [autosave.ArmASave] If I immediately after this take an manual save [save.ArmASave] then this file does CTD every time. I have to delete it to be able to continue with the autosave file. Odd? You bet. The content just cannot be the same, no? Shouldn't they? - Edit: ahja;..began playing from version 0.91e and since then, MrN has changed a lot already. However, right now with 0.92b, the CTDs are still happening.

Krasny, there is your problem. You need to 'End Mission' to 'deactivate' running things. - Do not get an new mission immediately;..just do everything else *first* (Medic, [manual]Rearm) @MrN; put this in the readme? Or slight player hint ingame after 'End Mission'? Thanks.

3 German/UK/US 2 me; 1 for brother.

Bug is still present, if settings are cranked max. Try flying. This driver is definetely an huge step forward, especially for the 8800s (at least on my setup, nice performance boost) Still, V-Ram spills over very quick (~5 mins) if attempting max settings. (playing stable for hours on reduced settings) Hopefully, NVidia can fix those issues come September once and for all + fog removal as icing on the cake.

1.09 then..hopefully? Please... The fog is a *real* pain and spoils a lot.

^ And is their hit rate as bad in RL too?

I hope, the bushes will be reverted (someday) to what they were like in ArmA 1.0 No problems crawling (hiding) in bushes there. They were changed in one of the patches (1.05?) due to performance reasons. Please BIS, someday, bring them back. Or could you provide both variants to choose from? Thanks. Edit: I'd like to add..if AI soldiers are allowed to walk through each other and walls, we should be allowed to walk through bushes.

Logitech Trackman Wheel http://www.logitech.com/index.c....l=us,en

Yes, as well. 163.44 driver is quite an improvement about former ones, but the problem is still present.

1. No. Since all of the 8800 series are the exact same technique (except amount of pipelines, memsize and chipspeed) you are likely to see the same problems (be it the hardware itself or the less-than-matured drivers) with each of them. As an advice and if you got the money to spare, go for the 8800GTS/640MB; unless you plan to play below or at 1600x1200 res. with full quality settings. 2. No again. You need another 8800 of the exact same type and memory size. So either 8800GTS/320/320 8800GTS/640/640 8800GTX/768/768 Before you plan to go SLI, just do a looong and hard infosession; there are a lot of problems with SLI/games/drivers If it works, then fine. Also, this setup draws a *lot* of juice. You also may want to hold back just a little longer and see, what G92 has in store (November frame) for you. Better choice?

Ok, now please try with following settings, if you still get errors or even crashes beyond 2 hours: - Resolution: 1024x768 Range: 2500m Terrain Detail: Low Objects Detail: Normal Texture Detail: Normal Shading: High [if you get artifacts, try Normal] Postprocessing: Low Anizotroping Filtering: Very High Shadow Detail: Low Antyaliasing: Low [if it does not crash, you may try Normal] Blood Detail: High - That should do, hopefully. Granted, this is more than 2 changes of settings, but at the end of the day, you want to run stable, no?

OH yes! Aint that the truth. Always keep an eye on dust-buildup. Soo much difference to heat/stability.

MIG25_Radek, Can you please post an link to an screenshot, which shows your ingame settings? Open video options, choose 'advanced' and make an screenshot, please. This driver (97.92) is proven OK with ArmA and your GFX-card; but your settings are too high, if you get this error. You *must* lower certain ingame settings, to be able to play for *hours* continously without artifacts and/or crashing game. - BTW;..if you get this error only after *2 hours* of play, you already got *good* settings, which only require you to lower 1(2) settings a little further to play completely stable.

You are of course correct! (I will edit my posts) Just after I wrote that values, I tested maximum settings with max viewrange flying;..until crashing. ArmA usage like you've said was then close to 800MB RAM + 800 virtual memory usage. Video Memory usage 640MB (0 free) ; crash after 5 minutes. Since I never use max settings, I barely see 650MB RAM usage, thats why I wrote that in the first place. Sorry. - With correct settings, I never crash; dont need maxmem= here.

You got that one slightly wrong. Regardless, of how many RAM you've got in your PC, ArmA will only use ~500-900(?)MB *without* the maxmem= parameter set. Please read this other thread;..slighly offtopic, but MAXMEM= explained in more detail. http://www.flashpoint1985.com/cgi-bin....t=66655 During own tests (XP SP2; Vista is another story) my max stable amount was 768MB set, trying 1023MB became unstable real quick on my machine with 2GB RAM. Values working ok, seam to be[rough guidance]: 256MB (Vista) 256, 512 (Vista, XP ) 768 (XP) 1023 (XP) Try to avoid values above 1024. While for some it may work, its pointless, because ArmA never consumes that much.

The original GeForce 7900GS is clocked at 450/1320 - The Galaxy GeForce 7900GS is already *heavily* factory overclocked at 550/1500 You know, what you have to do now, dont you? While you're at it, update your driver to 97.92 Problem solved?

properties of ArmA shortcut; like this: Target ..YourPathTo..\ArmA\arma.exe -nosplash -maxmem=512

Hello, You mixed something up a little bit (yeah, confusing parameters, I know) The /BURNMEMORY switch is an Operating System (XP, Vista) parameter, which 'prevents' the OS from allocating more memory. Say, you've got 4GB and set /BURNMEMORY 2GB, only 2GB will/can be adressed by the OS. (This is useful for getting software RAM-drives to work, for example) --- The MAXMEM= parameter is an ArmA specific one. Without this parameter(default), ArmA will make use of ~500-900(?)MB RAM If your ArmA runs (crashfree! ) with the default setting (no MAXMEM parameter) leave it at that. - There are situations however, where you need to tell ArmA to only use an *reduced* amount of RAM, to help stop it crashing. Especially with the OS Vista, you *may* need to limit the RAM ArmA is requesting; starting with amounts of MAXMEM=256MB up to MAXMEM=1023MB - So, lets recap: In general, the more RAM to *Vista*, the better! (no /BURNMEMORY switch at OS startup) Also, if you can run ArmA with its default settings and no crashing, leave it at that as well (no MAXMEM= parameter set) - But;..since you are running ArmA on Vista(unsupported), chances are high you *must* set the MAXMEM= parameter to get it to run (fairly) stable at all. The situation might change later, that remains to be seen. (Better GFX drivers; maybe someday official Vista support)

Well, I'm in..of course. http://img523.imageshack.us/img523....MG]

I do also have the Asus EN8800GTS/640MB and except the fog issue, no problems whatsoever (WinXP 32bit/ 160.03 driver) - Please do note, that the original fan duty cycle for the 8800s straight from factory might be too low, causing overheating issues. And as we know, ArmA is heavy on everything. I have had to force mine via Rivatuner to run at 100% while playing games. I only can highly recommend to change the fan duty cycle (from ~60% [?] in 3D mode) to 100% and go back down to 50% in 2D. Instructions on how to do so on this link: http://home.comcast.net/%7Eboog....ide.htm Again; no issues. Enjoy!

Should be around christmas timeframe. Exception might be, if ATI isnt able to surpass 8800 Ultra with next offering. We'll see. Next couple drivers by Nvidia should be interesting as well, as they are promising to fix some major bugs wrt. hefty slowdowns and more in other games. Hardware is fine;..but the drivers (sigh)

Fine tip! I did not suspect this to work with ArmA as well, because it never used that much main memory. (And I dont get BSODs with ArmA unmodified on WinXP 32bit) Another workaround to the list.. --- The same fix also works for Supreme Commander while playing big maps + many AI. Also, this works with Windows XP 32Bit version. --- Here is the original thread and some additional ones (3GB enabler > including editbin.exe) http://forums.gaspowered.com/viewtopic.php?t=2382 http://forums.gaspowered.com/viewtopic.php?t=267 additional sources: http://forums.nvidia.com/index.p....y225600 http://files.filefront.com/3GB_enabler2zip/;6791818;/fileinfo.html This also may work with other heavy on main memory games. Part of my boot.ini: /fastdetect /NoExecute=AllwaysOff /3GB /Userva=2900 /usepmtimer /PAE --- --- Btw;..keep and store your original ArmA.exe (like already told) for future patches! Once patched, reapply (if nesesarry still) the fix.

Which Joystick do you have? (model, pic? ) Is it USB? If so, try to use another port. Does it have separate trim controls? Maybe one is fully moved out instead of center.

Well some 'news' about the issue. In fact, meanwhile many other games face heavy slowdowns (particulary with the 8800GTS/320MB but depending on maxed settings, other 8800s with more memory are affected as well, as we know) I think, the problem with the slowdowns in other games are related to the ArmA behaviour of crashing instead. While now we've got some workarounds like changed ArmA main program, lowered settings, maxmem parameter and finally VRAM flush, it seem Nvidia finally admits to some fault in their drivers, which affects not only ArmA but other games regardless of other hardware/software setup present. Good news is, they announce some driver fix still in July;..lets see how this turns out. - http://www.techreport.com/onearticle.x/12877 - http://www.beyond3d.com/content/news/349 Me? I think, once again Arma just pointed out underlying issues way ahead of time..

Does your Desktop resolution match the ingame resolution? (ArmA claims foreground of screen) Maybe the gfx driver is unable to make the switch correct and therefore gets stuck on shutdown. Another thing to try is to temp remove your LAN cable (or disable wireless) before you shutdown ArmA.