Defunkt

The fundamental flaw in your position is the assumption that the game should be developed to run maxed-out on today's hardware. This is precisely NOT what a PC-orientated studio ought to be doing, especially with the open-ended life-span that ArmA 2 will enjoy, it's called future-proofing. Having said that, with a modest view distance (2400) I do run the game with everything on Very High and on fairly modest hardware (HD4870, Athlon X2 7750), perhaps you should sort your PC out. Better yet, get a console, you clearly aren't cut-out for PC gaming if you imagine every title is going to run perfectly on the multitude of low-cost components in your average PC.

You do not need a swap file, it serves only one purpose; to serve more memory to applications. I have 4GB of RAM and no swap file and no application has ever failed to allocate the memory it needs.

Oh, right, d'uh, literally "reload", for some reason I thought you meant on mission restart or the like. I believe that (reloading) is a major part of what's being added now for the next release.

Can I ask what you mean by reload? After what?

Same information I had before, your GPU is not full utilised nor are all four cores of your CPU, I get it. All of which is consistent with the information in Suma's article, program flow and rendering are still largely dependant on a single core and the rationale for that is the principle point of the article. I also assume that the reason he's decided to post this now is because of the numerous posts like yours wondering why not everything is maxed out, it's all in the article, have another read.

As I interpret that article, if your CPU or the core that runs the primary thread (which as noted above runs rendering) is choked it will not be able to keep your GPU in work. There is therefore a direct correlation between CPU usage and GPU usage, either may have a negative influence on framerate. Without trying to say one way or the other if the article is correct or not, it is pointing out that a determination to keep all cores busy (as evidenced in your GTA IV comparison) may prove an exercise in futility because of the overhead in sharing data between threads (see the possible 20%-only note).

Lughnut, it is a very long time (10 years) since most CRT's couldn't handle 75hz. Also you should have a read of http://www.100fps.com/how_many_frames_can_humans_see.htm

No, the opposite in fact. What that article describes is that there's a limit to the usefulness of multiple cores and that, to avoid the overhead involved in passing large amounts of data to a separate rendering thread, rendering is still largely executed in the primary thread with separable routines handed out to additional cores.

Have a read of: http://www.bistudio.com/developers-blog/real-virtuality-going-multicore_en.html

I don't particularly care for the red panels, for me the aesthetic cost outweighs the functional benefit though I am sure many will think otherwise. It does provide a mid-way point between all and nothing but I still feel what's required is something more fine-grained that requires the player to evaluate and interpret more. Picking up on our discussion yesterday Mandoble, why not present the inset as suggested along with the ability to switch to the fullscreen dialog to alter parameters but base it around two primary aircraft modes: 1. Forward Looking - Being the aircraft's own targetting radar and using exactly the same LOS checks as the HUD but providing a view that indicates distance also. 2. Long-Range - Representing a general purpose all-angles radar or again, an approximation of information made available from other assets (ie. satellite, AWACS), intel which would typically be available in most sorties. You also have the ability to limit or omit this mode for 'MiG-21' tech or where such assets are deemed unavailable. This provides yet another distinction between the quality of different assets or setting specific flavour. The key here is to have this mode only consider airborne units above (say) 150m and not perform any LOS checks. As the only way to reliably remove the radar is in the mission setup and it does so for every unit a 3rd mode would be required for ground units: 3. Full LOS checks would be required but I for one would be perfectly happy for nearest 6 objects, in fact I think it would be a positive. I would also suggest ground and air modes, some units would have both (so it can be earest 6 of one or other). There might also be the option to choose (again adding more 'evaluate and interpret' to the mix) between directional (nearest 6 in an arc of X degress) and omni-directional modes.

Suggest moving to ADDONS & MODS: INCOMPLETE.

Personally I never play with or against AI, not my thing, doesn't matter how good they are, they're still dumb. But I'm not sure what you're proposing should be done, if you want 'scripted' action then you have that option, just apply your own scripts to this scenario, this will always yield a better result because it is tailored to the situation. Not saying the default behaviours cannot be improved, there is always room for improvement and there are mods that seek to do that I'm just addressing the above call for 'Scripted' AI', it's an oxymoron.

Well then that requires 'tank' to have its threat rating elevated, but you can't solve it with an always run 'script' as suggested above.

Actually things have turned out not too badly at all with a sudden influx of DR/MW2 refugees trying ArmA just as it's really coming into its own and these improvements will feed the upcoming stand-alone expansion. I've certainly enjoyed having it to use and develop missions for in the meantime and I doubt that many of the issues now resolved or being worked on would have been so far along if this period had been restricted to a small test group.

It might appear random at times but I don't believe there is any coin-tossing in the present decision making. What you describe (if (nearest.enemies[x] == T90) run;) is going to yield more negative side effects than the situation it solves. What if the soldier in questtion has a Javelin, or the soldier standing next to him, or a friendly gunship is operating in the area above him or he is backed-up by a whole platoon of Abrams. And so it goes, you cannot solve something so complex with such simplistic rules. To act independently the AI have to weigh up many factors or their behaviour will prove 10x as odd and inflexible as it does now or you will end up with something so computationally heavy you can only afford a handful in operation at once.

You are confused, 'scripts' as used in this context detail predefined behaviours based on narrow and predictable events. Code (it may be in script form) that allows an entity to determine for itself what it should do in any given setting and respond to any event represents 'AI'. You're asking for the latter and calling it the former.

Mando Missile would be my solution of choice to the TAB-Boom issue.

Not sure what you mean, the radar (being the panel at the top that shows you enemy locations) is not essential for targeting.

You can place ShowHUD=0; in description.ext and the entire HUD (except for the compass in vehicles) is gone. The main problem this presents is knowing which weapon you have selected but it would be easy to script a nice discrete replacement and a key-driven function to query the ammo in your clip/webbing. I briefly considered doing this in my P-v-P mission(s) but decided that the radar as-is is a better approximation of the sensory equipment available than no radar at all. A radar replacement could be coded but would involve more time than I have.

Your map tools rather got my attention and I recalled that you were working on this. Can I ask, is this project script-based (as Jones' initial release was) rather than add-on based? The former offers big advantages to those of us running public servers as it can be included in the mission and used by anyone who joins without mods.

I would suggest that, whizzy as it is, the ability to share map drawings isn't actually all that desirable in a simulation, it's not like every platoon has a fax machine. I feel there is more immersion to be had from the requirement for clear and precise verbal communication.

I haven't arrived at this need myself yet but will eventually, I was hoping something like you've described would be possible, good to hear that it is.

Modders and mission makers will always reach limits, it is the nature of the beast, you cannot contemplate a 3D world with zero parameters, it is a fantasy. Maybe you could tell me which game you are comparing ArmA to? I'll say again, it is (by a country mile) the least limited I know of without considering what might be possible with a full SDK under the terms of a commercial license which is (obviously) not relevant here.

ArmA would have to be the least limited engine known to me and if you think BIS are lazy I suggest taking a look at ; you could not possibly have seen it and still hold this opinion.---------- Post added at 07:40 AM ---------- Previous post was at 06:48 AM ---------- Delivering an x64 binary is as easy as setting a compiler switch but the only meaningful enhancement is an increased address space. How does one improve game performance with more memory? By caching data and I cannot think of a more easily separated function than file/resource caching so how on Earth would throwing out the current rendering engine make that happen quicker? Suggest you read Suma's blog entry on the opportunities and pitfalls inherent with multiple CPU's, I am certain he knows far more about it than you or I. Given all this game manages on top of cutting-edge visuals I consider performance to be quite exceptional and I am especially grateful that they have pushed today's hardware and ensured the game (this one especially) enjoys a decent longevity, it's what PC titles (those that are left) should be doing. If you ask me it's the assumptions of the "OMGZORS nOt all me 733t corez is crankin'" set that need rewriting.

I'm sorry but this 'start over' idea is plain nonsense, I doubt anybody with actual development experience would promote it. Evolution rather than revolution will get the product further, faster.