Helmut_AUT

To clarify my issue with the "Minimum" and "Optimal Recommended" Specs: Like I said, I would expect "Optimal PC Requirements" (thanks Gutter for posting them) to allow for high quality graphics (at least medium to high settings) at average resolution (1280x1024). If using a higher resolution than average (1920x1200) in turn it should be possible to run with low details and still get very good framerate. In my case, even if I'm was using 1280x1024, I still get slowdowns under 20 FPS regularly (in an empty editor map, just with some smoke on screen) if using medium to high quality settings. That is certainly not right to call this "Optimal system specs" unless BIS thinks frames under 20 are "optimal". And an overclocked 9600GT like mine is in many Crysis Benchmarks or other modern games maybe 10, max. 15% slower than a 8800GT. That bit of performance difference doesn't explain 15 Frames a second slowdowns. As for CPU: Running the included Warfare Missions on Chenarus gives me 16 FPS constant. CPU is bottlenecking, even if I disable some AI on both sides. So with a CPU better than "Optimal PC requirements" (I have an Ahtlon 64 X2 5000+) the majority of included missions (also the freeform campaign missions) are unplayable due to CPU Bottleneck. It's not like I believed the official system specs, as a long-time gamer I learned that they are usually false, but I find it really cheap that a moderately aged dual-core CPU can't even play the included campaign since it requires too many AI handling. Basically right now I can only play small editor missions that I'm creating myself (thankfully SecOps and ACM makes this a bit more random) - and seriously, the 5000+ AMD isn't THAT old that it should be unable to run the included content.

I admit I haven't tried a lot with Mortars yet, but the MLRS is just too damn powerful. And the M119 is very precise. It would be nice to have more random center of fire, adjustable by player, AND the option to select spread and number of shots. That would enable some semi-authentic calls for fire. Combat Mission: Shock Force has a nice and simple interface that still enables a very high and realistic control over fire. Doesn't have to go quite that far in A2 (no line vs. point targets...) but some more parameters would be nice.

For me, the big thing when moving is that turning seems so... delayed. That means I'm moving my mouse across the pad left to right at a constant speed X, but in A2 the movement of the player/screen/view starts at a lower speed y, and then slowly accelerates to X. It's like the player model being stuck in glue at first until it breaks free and has normal speed. It might be an attempt to model gear load and mobility restrictions, but it means that it makes small control movements very imprecise, since we are best at controlling linear movement speeds that correspond exactly to mouse movement. And the way it's now, ot constantly feels like you are "lagging" since what your hand does is not mirrored 1:1 on the screen. In theory a good idea, but just annoying for it's lack of usability.

Oops - I didn't think there would be a difference between dedicated and hosting myself. Sorry, you might well be right. I wouldn't even have considered such potential problems since the Logics are included by BIS and you'd think they made sure to make them MP proof. Oh, and I also had "unresolvable" SecOps missions. One was to destroy the truck - I just so happened to have MRLS support - so I flattened the area and still couldn't complete it.

Ethne, if it makes you feel all superior to claim that a 9600GT can't run recent games in 1920x1200, then be my guest. End of discussion for me too since you obviously ignore your own benchmark links. Frag, I expect either the 1.02 or 1.03 patch to enable FSAA and come with at least some performance improvements. Reason being they should know by now that people REALLY want FSAA, and while they are redoing the graphics code to include this they might as well pull out a few stops. For example by adding the option to disable Motion Blur, or reduce shader demands. Most lovely would be an option to totally disable Post Processing. I still think they added this in A1 just to generate effects (Sunglare, NVG-eye adjustments) on top of an old engine that couldn't otherwise do it, while other current games use different and more efficient shading methods for light effects. That is perhaps the weirdest thing about Arma's engine at all: Most other games have some quality settings that have a massive impact on framerate. Like, 30% more frames by disabling such options. In A1 and A2, the most you get by going from super high to super low might be 15%, there is not a single option that really has a particular significant impact. Which leds me to believe it's the heavy shading that can not be turned off.

Dear Ethne, your gleefully posted benchmark proves actually nothing. They are using software-based Anti-Aliasing, while newer drivers since then both brought more performance AND support for normal hardware FSAA (I'm using 2x FSAA). They are using 16x Aniso, I'm using 2x Aniso. And my 9600GT is factory overclocked to 2000Mhz memory and 700Mhz Core, not 1800 and 650. They are getting 32 avg. up to 37 for the overclocked card, I'm getting 40+ which is easily explained by the above differences in settings, drivers (174 to 185) and clock speed compared to a standard sample. So, the fact remains I can run modern games - as recent as F3 which performs even better than Stalker since Nvidia really optimized their drivers for F3 and Oblivion - at very playable framerates (always above 30) with max. details, but A2 gets framerate drops down to 15 FPS even at lowest quality settings. Don't tell me it's just the resolution, the facts clearly speak against it. A2 has no advanced graphic effects or features (compared to Stalker, F3) that would justify such a much lower framerate by themself, and even turning down the view distance to 500m has no noticeable effect. Frag, I test Arma Framerates always on empty islands in the editor, running or being driven by AI around a specific path, with some weapons firing to get smoke FX. So the CPU has zero do to in these tests. As you say, your "state of the art system" gets you 35 avg, I get 29 avg on my settings. I guess you can also get drops as low as sub-20 on your system inside forrests with smoke lingering or multiple light sources at night. Shouldn't the gap be MUCH larger if the engine was properly using it's ressources? It's turned into quite a pointless discussion here now - I actually had forgotten about this topic until someone bumped it yesterday. But if you guys insist on knowing better than I myself what my framerates are and should be in other current games, I'm here all night to prove you wrong.

I really like the addition of the Predator and Russian Drone to the inventory, together with the user friendly and easy implementation trough game logic. But, lets be honest - for what we are using it in game, the Predator is overkill. A player might realistically be commanding a platoon, at best a company in game - I doubt Officers of that rank have a real-time handle on a Predator and where it goes. Also for range and endurance, the Predator is much more than any A2 mission will likely ever need. Something that would fit in well with the more common mission type, and which is actually used by Marines (not on loan from the Air Force), would be the WASPIII Micro UAV. This thing has a 5km range and 45 minute flight time, quite adequate for most infantry assaults. If a bit more range and endurance are wanted, the RQ-11 Raven (http://en.wikipedia.org/wiki/RQ-11_Raven) or the Dragon Eye (http://en.wikipedia.org/wiki/Dragon_Eye) could be modelled. Downside to these three designs is that their primary camera is a fixed side-looking type, so instead of the movable turret now modelled on the game's Predator, you'd have a system that flys circles around a spot and keeps the camera aligned. But that's plenty for recon work, and no one says you can't still model it as "movable turret" for game purposes. Upside to them - a considerable upside - is that these are man-portable, hand-launched UAVs. Make it two pieces of large gear (one the Drone, one the control system), only one of which would fit in the "RPG/M136/Javelin Slot" so it needs two soldiers to carry, and give one of them the ability to "launch" (spawn) the UAV when needed. The soldier with the control gear (or the Unit Commander, if the Soldier is AI) can then use a menu action to connect with the UAV and get the images, no need for a dedicated UAV Terminal Object. So basically, my suggestion is: Give the user a choice not only for a theatre-level MALE UAV like the Predator which currently has to be placed by the mission designer beforehand, but also for a man-portable, "deployed during the mission" design that might even avoid the need to have it scripted into the mission - if the scripts can be packed with the "Gear", any player could select the UAVs from the Gear Selection screen before a mission. The hand-launched UAVs would be much better suited to the role I'm seeing them mainly used for in A2 - when an Infantry Squad - or Platoon - under Player Command prepares for an Assault on a village or fortified enemy position, to gain aerial overview and recon information before actually commencing the assault. The Predator doesn't really fit realistically in that role.

You guys are funny. Want me to provide FRAPS screenshots of Stalker and other games so you can compare how they look and run here, or what? I know what I'm seeing. And when I see Fallout3 (released about six months ago, so I would count that as pretty current) running at full detail 1920x1200 at full tilt, with grass, trees, fences, houses everywhere in a very large view distance, and then I turn A2 down to 500 meters VD, set all details to low and get half the framerate at best - I guess that means suddenly my 9600GT degraded in the last six months magically? I really shouldn't care what some fellow gamers on a message board tell me, but the fact is that I won't accept the argument that the 9600GT can't run modern games at high resolution. It can, and it does. However it never managed to get anywhere near the framerate out of A1 that it gets for Stalker and FO3 either, so maybe we could just agree that BIS never had the fastest graphics engine in town, especially since walking into a forrest at Chenarus can bring much newer cards to their knees. It's not hard to see why that is - they slapped a full-screen 100% everthing post processing process on the engine back in A1 to get current graphics without a total rewrite of their core engine. And post processing is costly for every game released so far. But I guess I'm just stupid for expecting a current game at low details to perform equal to a six-month old game at high details, hmm? Or maybe the guys at other software companies simple realized that shading the whole screen just to generate some effects is not the best solution. Oh, and don't take this as an Anti-BIS Rant: I love the game, just as I loved A1. But trying to put the blame on medium range hardware when other stuff runs much faster on that same hardware is just fanboism. And at the end of day, a 9600GT averages 10 to 15% less performance in benchmarks compared to THEIR recommended specs, so maybe we can also agree that the recommended specs are wishfull thinking.

Works fine in Multi, all Game Logic Modules are tested by BIS for that. The SecOps Manager is really a good way to get some randomized playtime out of a quick editor session, especially for people (like me) who's CPU coughs at the large campaign missions. What I would like as improvement is that the amount of SecOps enemies scales with your personal squad size (including subordinate squads if present in High Command). As the OP writes, 5 Russians defending a truck vs. 4 full USMC Squads is not a fair fight. SecOps will be even better once we can easily define the distance of spawned objectives (right now they are always "round the corner") and the frequency. This is in development as far as I know. BTW, if you use the Mission Creation Wizzard under "Scenarios-My Missions" there is already a template for Insertion and random SecOps missions.

Ethne, Heatseeker - do you think I'm a tech noobie or something? I run modern games with modern graphic engines like Stalker:CS, Fallout3 at 40+ FPS on everthing high detail at that resolution, with 4x FSAA. The 9600GT is an AWESOME card for the money, and absolutely capable of 1920x1200 resolutions. You can't tell me Fallout3 or Stalker with max view distance and max objects looks any worse or are more "dated" games than Arma2. Fact is that even A1 ran very much slower for most people than any other graphic-intense game, and the A2 engine has the same low performance. So much for "unrealistic expectations" or "expecting too much". Ethne, the RECOMMENDED SPECS are not the MINIMUM SPECS. Recommended is what BIS wrote on the box, a 8800GT, and RECOMMENDED should mean to be able and play the game at high details on average resolution (1280x1024) or low details at high resolution. Recommended used to be what you needed to really enjoy a game, these days Marketing seems to dictate that Recommended is what you need to barely play. I don't even want to know how A2 would play on Minimum listed. Panthe, you are right that the sluggish feel never entirely goes away, even in scenes with 40+ FPS (open field). It's like the movement is stuck at first, then accelerates to normal speed, compared to the direct, even movement speed you get in normal shooters where mouse movement and screen movement seem utterly directly related. Not so with BIS engines. If you haven't, you might want to try the 185 Drivers for the 8800GTS - they gave me 10% free performance coming from the 182. On WinXP they work very well, I heard problems for Vista Users however. Centipede, I'm on WinXP. But thanks for thinking out of the box.

Hehe, given that the MRLS in game doesn't even cover all of Chenarus, they are using "too big" stuff and cutting down on capability instead of the right sized material to begin with. My sentiments exactly, that's why I'd want a smaller UAV. Also posted for modders, but it is really something BIS might look into, especially the "packed as gear item" solution.

Carl, the process with "Check Signal" makes sense. If there are multiple controllers around, it might even offer a selection of emitters for the guy with the UAV to synch to. Only important thing is that it would also work for single player by using the ACTION menu when commanding AI.

I disagree on your last statement. I think it's ridicolous that the lying on the Box Specs now is at a point where "recommended" systems can't even play a low resolution/high detail or high resolution/low detail. I'm not saying I expect "Recommended" to run 2560x1200 all maxed out, but the game right now really needs optimization. Using Keygets noblur mod gives a few more frames, and depending on scene I can now get 30+. still slowdowns to 15 occasionally.

It generally seems to me that A2 models Body Armor much more significantly than A1 did. It takes more bullets to kill an enemy and it takes more bullets to kill my own guys (wounding happens more frequently it seems). But assuming a solid head hit, one shot will be enough.

Thanks, that sounds good. Will report back.

Hi Guys I'm trying to create a mission where the player is attacked from an endless stream of randomly spawned enemies and has to hold out until his transport arrives. I think most of us have played such missions in other games, and while not entirely realistic they are quite fun. The story setup could be that the Player's Units (I'm thinking a Platoon-Size Force with High Command enabled) has to protect the former Chenarus President and his Wife who are fleeing the country after a takeover of power by the ChDKz The action would be in a coastal town, with the player "with his back to the ocean" and waiting for transport boats. Now here's the question: To create the incoming enemy hordes I can use the Ambient Combat Module and have it spawn RU or ChDKz units in a random distance and intensity from the player. Not a problem. But when the ACM spawns units, they are in normal "patroling" mode and will move around randomly. I need the spawned units to head for the player position immediately. So I need a code or trigger implementation that picks up the units spawned by ACM (of which I know no name or ID), then deletes all their waypoints and gives them a new waypoint near the player. Could I do that with a repeat-trigger "OPFOR preset" or something? I seem to remember that a trigger has a list of units which activated it, so in theory shouldn't every spawned unit be able to be handed by that trigger? Thanks for the help.

Thanks. You enforce it to be two guys since you pack the aircraft in one container, the required "control suit" in a second container, both filling the slot reserved usually for Javelin or other AT Weapons. A single player could only carry the folded-up drone, or the control unit, but not both. This seems coherent and believable with the real size of these things. Maybe even make it so that the two guys need to be together to launch the Drone, for example by giving the launching action to the guy with the control unit, only as long as he's close enough to the guy carrying the aircraft. Arguable this doesn't require their teamwork once the thing is airborne, but for SP missions and even MP missions it means that the tactical usefulness of the small UAV comes packed with some tactical disadvantages (less carrying space on those two soldiers). IF (we don't know yet) it's possible to put these functions into actual "Gear Items", you could also place them inside a Humwee or other vehicle for easy transport. For me, it would really add to the realism to actually have a guy in my squad deploy the UAV when I want it, not requiring the mission maker to hang me one overhead all the time. The Predator is just not suited to that type of deployment - the way I understand it, they are all controlled from continental US by sat connection, directly linking their images into those command centers, from where the filtered and analysed information then gets distributed to in-theater commanders (and never as low as Platoon or Squad Leaders). Since most of A2 features the player as exactly that low rank level, he needs an UAV that is actually deployed and controlled from "in the field". It is so obvious that I really wonder why BIS chose to implement the MQ-9, I assume because of "name recognition" value more than anything else. BTW, the Russian "Pechela" is actually a bit better suited to the in-game use, but it's still a fairly large vehicle requiring a specialized launcher. Here's another interesting UAV from the category we're looking for: German Aladin http://en.wikipedia.org/wiki/Aladin_(UAV), with a range of 15km and 30-60 minutes Endurance. Which is also equipped on the FENEK Recon Vehicles as standard. I think the important part is that BIS actually put in the framework to control UAVs pretty well (although the Pred. needs a stabilized camera). They just decided on the wrong size UAV to include, and with smaller size UAVs automatically comes the idea to make them actual equipment items, not just game logic objects.

That's what I tried at the start of this thread, but the Trigger only fires once and then doesn't reset as long as OPFOR remains present. Since the trigger encircles all the area, there is always OPFOR present, and as far as I know a multiple activation trigger requires it's condition to be false before it will be able to fire again. I'd need something like a time-controlled loop, for example ever 30 seconds either the trigger needs to be reset so it can fire again - or isn't there some generic scripting call to query the engine for all units from one side currently alive? Thanks that you are still trying to sort me out, even though I prefer the boneheaded way of doing it with ACM ;)

(Originally Posted in Suggestions Forum, but maybe something for Modmakers instead of BIS: Adding a Micro UAV with the option to carry it and "deploy" it in field: I really like the addition of the Predator and Russian Drone to the inventory, together with the user friendly and easy implementation trough game logic. But, lets be honest - for what we are using it in game, the Predator is overkill. A player might realistically be commanding a platoon, at best a company in game - I doubt Officers of that rank have a real-time handle on a Predator and where it goes. Also for range and endurance, the Predator is much more than any A2 mission will likely ever need. Something that would fit in well with the more common mission type, and which is actually used by Marines (not on loan from the Air Force), would be the WASPIII Micro UAV. This thing has a 5km range and 45 minute flight time, quite adequate for most infantry assaults. If a bit more range and endurance are wanted, the RQ-11 Raven (http://en.wikipedia.org/wiki/RQ-11_Raven) or the Dragon Eye (http://en.wikipedia.org/wiki/Dragon_Eye) could be modelled. Downside to these three designs is that their primary camera is a fixed side-looking type, so instead of the movable turret now modelled on the game's Predator, you'd have a system that flys circles around a spot and keeps the camera aligned. But that's plenty for recon work, and no one says you can't still model it as "movable turret" for game purposes. Upside to them - a considerable upside - is that these are man-portable, hand-launched UAVs. Make it two pieces of large gear (one the Drone, one the control system), only one of which would fit in the "RPG/M136/Javelin Slot" so it needs two soldiers to carry, and give one of them the ability to "launch" (spawn) the UAV when needed. The soldier with the control gear (or the Unit Commander, if the Soldier is AI) can then use a menu action to connect with the UAV and get the images, no need for a dedicated UAV Terminal Object. So basically, my suggestion is: Give the user a choice not only for a theatre-level MALE UAV like the Predator which currently has to be placed by the mission designer beforehand, but also for a man-portable, "deployed during the mission" design that might even avoid the need to have it scripted into the mission - if the scripts can be packed with the "Gear", any player could select the UAVs from the Gear Selection screen before a mission. The hand-launched UAVs would be much better suited to the role I'm seeing them mainly used for in A2 - when an Infantry Squad - or Platoon - under Player Command prepares for an Assault on a village or fortified enemy position, to gain aerial overview and recon information before actually commencing the assault. The Predator doesn't really fit realistically in that role.

Which would be a pretty important feature to add. Often crouching is the better firing position.

Not quite correct - my OP was about the difference it makes in FPS what lies behind a wall, when in fact everthing behind it could be culled from rendering - or maybe not, as some people here explained for other reasons. But my test was not to show that two walls have different FPS - rather to show the engine is rendering stuff you can't see.

I really appreciate the help, but I'd feel stupid creating a mission without knowing what I do. You are right that the ACM offers far less control, but for me I kind of like that because it brings some large randomness. And all ground patrols on RU side are okay for my purpose. There must be an easy way to get all groups belonging to one side currently in the mission?

Can you guys clarify which object exactly you are placing in the editor? I'm on version 1.01 here, this drives me nuts. You are obviously NOT talking about the Radar when it's used inside a default Warfare mission, but about an editor-placed object?

I think it's a really cool feature, and seem to remember the A1 Black Hawk could not move the guns fully forward? With the Venom, it's basically the loadout of a Little Bird, with the option to have two gunners firing sideways. BTW, one thing I seriously like about the Venom: The Gunner Position for the FLIR targeting system means that there's always a pilot and copilot - no more unrealistic "Cargo gets in the front seat" situations.

Neo was so kind to send me his script, but it's quite advanced, maybe more than I can handle to adapt it. My editing knowledge is basically how to paste stuff into the init field (I did some more stuff years ago with OFP, but... way past) While I really appreciate the offer of this script solution, there must be a more simple and elegant way to make this easier with A2's ACM module? I just need a way to start every ACM-spawned unit with that DoMove command. Is there maybe a way to call a function at set time intervalls that returns a list of all OPFOR groups on the map? That would do.