Fireball

See also my post here: http://forums.bistudio.com/showpost.php?p=1657358&postcount=56 Could you verify this with sbsmac's ArmAFPSAnalyzer?

It seems to me that tree LODs (or LOD switching) had been modified. They look now much more proper and foto realistic, but FPS suffers during flight. This is also apparent in my latest Coastal Flight BM run; - blue is 70951 with exThreads=3 - yellow is 71213 with exThreads=7 - red is 71726 with exThreads=7 As you can see, latest beta hogs flight view performance pretty much. I like the view though. It would be a good compromise to switch to low LODs if FPS drops below 15, IMO.

I agree, it's been held too generic and got cluttered up. But I've made a self-running repro mission using camera scripts. So no repro steps needed there; that's why I've linked directly to my comment where the link to the attachment is visible.

http://dev-heaven.net/issues/7866#note-25 Did you try my repro already? I think there's also an issue with scoping with those trees in view. Can anybody else see it happening with my repro?

I've been trying some single player (EW campaign) with -exThreads=7 and since I had a sluggish feeling ("jumping" movement), switched back to -exThreads=3. The jittery movement didn't go away, so I terminated Skype which had blown up itself again to ~200 MBs memory usage and then it was smooth again. And as expected, switching back to -exThreads=7 it's all fine, but with my GPU I didn't expect improvements; Indeed that is the case, but it was still a recordable difference; the coastal flight FPSAnalyzer curve (% spent below fps) looks a bit flatter on the top than with -exThreads=3 (thus the high FPS shots had average more FPS again), the average FPS has improved by 1. One thing I noticed; the scripting performance went bad drastically again; after one hour of host server of a Warfare BE session, 1 "second" of the respawn timer equaled roughly 2 real life seconds again.

The problem is, if above in the poll stated "additional reasons" come to pull, you can (still) not override the "Danger Mode" (bounding overwatch) using the Aware/Safe Mode order. IMO it should be kind of "reset" with the Aware Mode order and only (permanently) overridden with "Safe Mode" though. EDIT: Another problem, which the poll does not address, is that if you're getting under fire or order "Take Cover", the whole crew starts the bounding overwatch and might be pinned with slow (bad!) tactics in the middle of a large field without any cover and you can't get them to MOVE THE HELL OUT!

Actually it's supposed to fix crashes from previous betas concerning file packing, empty LODs etc. so go and do test it as usual ;) (Keep in mind though, that Addons may deliver other bugs, which should not be connected with the core game.)

Well, for one it's sure we should check core game aspects and basic performance only without mods, but since ArmA II lives from the modding/mission making community, it's imperative that BIS does not break stuff for them. There is also the script performance cutting in - missions like Warfare BE with or without ACE2 e.g. make great use of scripting. Just because scripting performance is not optimal (specially in long missions) the solution is not telling people to play vanilla ArmA II instead.

I've made a comparison of patch 70951 (exThreads=3 vs 71141 exThreads=7) with the same settings (most settings to Normal, Shadows to Very High, PP off, AF Very High), Resolution 1680x1050. I've used the Coastal Flight FPS BM. Specially the % time spent below FPS tells the most interesting. The lower (or flatter) the cuve, the better; so the blue measurement being the exThreads=7 from 71141 shows slightly better average FPS in the lower regions but it didn't go over 40 FPS so much anymore. I guess that means with my 10% OC'ed Core i7 920 (HT off), that with my 8800 GTS 512MB, the GPU usage was already maxed pretty much.

Hello Beta community! Since here are many interested testers and many of you probably know of the issue, that some of the very elaborate leaf trees are pulling down FPS very hard: http://dev-heaven.net/issues/7866 I have three pleads to those affected: a) deliver feedback about your CPU/GPU/driver involved b) help me reproduce the issue c) vote up the bug to show some approximate numbers of affected people Thanks! Remark: I've noticed that (shift)-FLUSH resets the FPS, when the issue with the trees seems to be very strong.

I've seen Suma's remark after I've ran all the benches and I'll thus only summarize the results: ArmAIIMark It ran on all options pretty much the same: Test1: 28-31 Test2: 34-36 (Hangar fly-by) Test3: 30-31 Test4: 42-43 Test5: 15-41 (Space capsule) So, as we can see, the differences in value are neglectable, the raw numbers are not so important here thus, except for two special mentions: Test2, the hangar fly-by stutters considerably with 1.05 and beta (noparam) but with exThreads 1 and 3 it becomes smooth. OTOH, Test5, the "space capsule drop", is the most remarkable of them: 1.05: 15 fps beta: 41 fps (no param) beta: 27 fps (exThreads=1) beta: 31 fps (exThreads=3) So interesting is that this is the only test which performs worse FPS-wise on the beta, but with exThreads=3 it feels definitely a lot smoother. ArmAIIMark values: 1.05: 3131 beta (0): 3649 beta (1): 3310 beta (3): 3456 Chernogorsk Benchmark Interesting enough I couldn't find significant differences between any version and param setting, also personally I only vaguely noticed increased stutter on raw 1.05 there. I'll do some gameplay testing, as wished, during the next few days and report back.

I got the same but I think it is not (BETA) patch related, I think it's the latest Nvidia driver(s), but I <was too lazy>|<did not want to> roll back to earlier drivers in order to confirm it, but I DID already roll back to February BETA which was performance-wise running fine (in this regard) and experienced the same issue, still. Please, other Nvidia users with this issue, tell me if you tried by rolling back BETA or drivers. EDIT: currently I'm -FLUSH'ing the VRAM all ~30 minutes in order to play

Yes, be careful with ACE2, since they need to adapt everytime a new beta patch appears, use vanilla for testing and feedback. Check back with ACE2 in a week or so, until they caught up with Beta. For me recently, the issues with the trees got worse, but I think it's driver related; see http://dev-heaven.net/issues/7866 - if you notice this issue too, please give some feedback about GPU, CPU and drivers involved. Thanks! EDIT: Well, since -FLUSH resets the FPS, it's probably not only driver related... Can you see if your issue disappears by rolling back to the february Beta patch? You probably experience the same as I do, and yes if rolling back does not help, it's the driver.

Could you two contribute evidence/computer specs etc. to my A2 CIT bug ticket http://dev-heaven.net/issues/10271 That would greatly help to pinpoint this, since I had this too, but was unable to reproduce it, after starting A2 up for a second time only in vanilla editor. Thanks!

I've got significant FPS issues when going prone, standing up, zooming in by holding RMB or scoping, while apart from aforementioned situations, FPS seems "normal". Example FPS measures vs. action: walking around normally: 25 FPS dropping to prone & standing up: stutter down to 7-10 FPS zooming in & scoping: stutter during zoom operation and FPS steady around 7 FPS I've tried to make a video but it did not record the FRAPS FPS indicator top left, for some reason. EDIT: Video on for those with the good eye mark (since FPS indicator went missing)I tried to repro it in vanilla editor mission with no luck yet. EDIT2: http://dev-heaven.net/issues/10271 EDIT3: Started some Warfare BE locally on my machine with no such issue yet, maybe a one-time issue, but maybe it will also surface much more after many player tried it for a longer while...

Actually it just takes quite some time for them to become ready again. About 5 minutes at least.

I know this has been claimed all so many times, but it never has been proved, I think. Maybe this is obvious to those who understand how AI sees, but I was asked continuously to provide a repro for that. So here we go. I'm bothered by that issue for a while already and I finally managed to do a repro mission and made a video of it even: http://dev-heaven.net/issues/show/5785 As it seems, if it's about detection, grass is considered if you're hidden in it. But if the line of sight is obstructed by grass and you're already discovered, then AI becomes clairvoyant. That produces scenes, as to where AI sees you, dives to (visual) cover into high grass and shoots you precisely, as if they saw you from there. I think that behavior is super-human (sort of cheating) and should be fixed. :protest:

Yes, the patch changelog only stated that "minimalHit" was made available, not yet integrated into the default armored vehicles. EDIT: Sorry, for stating the obvious again. But interesting find, Billy Bones.

Yes, please do not mix two (or even three) different issues. 1. what I mean is the grass layer and only that one not hindering AI view 2. what has been discussed here too, is a good AI feature (anticipation where the enemy could go) 3. what has been confused with 2. is suppression precision, which is too high; the AI just has a better idea where it lost line of sight to you, than a human normally would have

Unfortunately that's still showing up.

Yes, it's an AH-64D Longbow - you can tell by the "bowl" on top of the mainrotor, which is the Longbow RADAR, only mounted onto the AH-64D! :bounce3:

maturin, if you look at my repro mission and video you'll know it's about grass.

Localizations are due for official patch releases, not betas.

Agree, please look at: http://dev-heaven.net/issues/show/6380 Vote for it.