Inkompetent

Alternatively, depending on how your conversation is set up (game logics? FSM? Script?) you can either syncronize the initial waypoint (should be where you want the soldier to be during the conversation) with the game logic waypoint, or create a variable in the init.sqf, say convoDone = false; and set the condition field for the waypoints to convoDone. Then at the end of whatever conversation system you use, set convoDone = true; to let the units move.

Also, use the reveal-command. This will make sure that the AIs' knowsAbout value will be so high that they actually can pinpoint the target.

Your ace_clientside_config.hpp file

And it lags, and jerks, and is jittery, and totally unstable. Unless the vehicle is stationary or you are playing singleplayer it is practically unusable for this purpose =/

Because without quite some additions to the engine it can't be done in a *that* good way. It can be done in two ways at the moment without proper engine support, and this is by script updating the character position locked to a place i nthe vehicle, either with attachTo or something that imitates attachTo, or by premade turrets in the vehicle where proxies for the weapons need to be added, thus limiting the amount of different weapons to what the modeller can be bothered to add to the vehicle and to what mods it will require. The first way is totally multiplayer-incompatible, and the other limited in weapons choices. Might be some more way to do it, but not that I've heard of, and to my knowledge of the engine there isn't really any other ways to do it until BIS adds it, and I wouldn't think it's a minor task.

Aaaand this should go into the addon request thread ;)

Think your @desert mercenaries and blackops is the problem here. You can't have any spaces in the modline. All other spaces in your actual message is automatically added by the forum afaik.

For all CryEngine fans: I don't think there is a single person that doesn't want ArmA to get a better engine removing several of the limitations and flaws of the current one. However you have to realize that CryEngine isn't the solution. It is not designed with a game like ArmA in mind. It can't do what ArmA requires. And on top of that changing engine completely is a BIIIIIIIIIIG step for any company to take. To my knowledge there doesn't exist any engine that can do what needs to be done for ArmA, other than their own RV3 engine. Who knows? Maybe RV4 (if it comes) will be a completely new engine, scrapping some backwards compatability to allow for larger changes, but a lot in ArmA is done for a reason, even when it comes to engine-limitations. Several hundred units on-map at the same time, most or all of them AI, multiplayer for a hundred players, a huge world, a 'whole-body'-feeling, the player camera being at the soldier's eyes and letting the player see himself, like everyone else sees him (i.e. no differentiation between 1st and 2nd person view as far as models go). It puts limits on the amount of bandwidth or CPU cycles one can allow a certain thing to use, and it puts limits on how animations and stuff can work. The fact BI is working their hineys off to completely rewrite the memory management of the game engine (check beta patches) and adding proper support for multithreading says quite a lot about how serious they take the performance-issues though.

Ehh... And what is 'american voice' to you? USA is the largest immigration camp in the world with A LOT of people speaking with accent, and a lot of them making it into the armed forces ;)

Sounds really nice! I've been longing for a wound system for smaller and longer games that's not the usual revive system but a bit more demanding. ACE Wound is nice, but it usually ends up being either too much medical gear on people, or so little it is very cumbersome for few players to survive a longer time. Good initiative :)

And what makes you think this? Just because it isn't solved doesn't mean it isn't a known issue. AI is anything but easy to make you know. One *can* make super-advanced awesome AI, but then you might only be able to have 5 AI on the entire map or your CPU will self-terminate from the overload. ;)

Yep. That's a good example. It'd be like that, just the weapon would be invisible unless in use (or at least the seat occupied) and the weapon could be a whole range of weapons, instead of the static ones on that GMV. Doing it better than that won't happen for multiplayer though unless there's proper support added to the game engine.

It *can* be done in ArmA2 through mods (Generation Kill mod will make it possible for example). However it is pretty limited in what weapons you could use since the weapon itself would need to be available as proxy in the vehicle model and defined as a turret in the window-position. Due to the vast amount of weapons available in addons it is not feasible to do so, since only a handful of weapons would be possible to fire (or at least visually represented) on the vehicle

Wrong, actually. It is a Wasp class amphibious assault ship (LHC-designation, while Tarawa is LHA-designated). The length is still about 250m though, so that is still true.

The SAW isn't designed to kill (okay, all weapons are made to kill, but the reason you see one SAW per 4 soldiers in USA isn't for its killing power). It is designed to suppress. And that job it can easily do at 500m and beyond, delivering accurate bursts and having a large ammunition capacity. This of course assumes engaging targets that actually fight back properly instead of rag-tags with a lot of willpower and little skill. It allows one weapon to put down a high volume of fire for a long duration between reloads, yet being light and mobile enough for one man to carry and move around reasonably fast with. Actually I'm not sure about the expected kill/ammo ratio on the SAW, but at least in the Swedish Army a rifleman with his AK5 (a FN FNC) is expected to need 100 rounds to hit a prone target in cover at 200m shooting back at him. I don't expect the SAW to fare better. Thus you need to close on the enemy, and the only way to do that is to make sure he can't shoot at you while moving - thus the mobile suppressive weapon SAW. And as others say: You don't shoot continuous fires with machine guns. 5-10 round bursts depending on what you want to achieve, and just switching from target to target to suppress a line of enemies. For that purpose red-dot is superior to iron sights for the fast target aquisition. Although in practical terms of quick and large range-adjustments on the optics I'm actually not sure if red-dot would be prefered over irons. Yes, a .50 BMG round is superior for killing power, bullet trajectory, accuracy, cover/armour penetration, etc, etc. But who are you going to make carrying around a 58kg machine gun (gun+tripod) and its brutally heavy ammunition? War is logistics. The one with best logistics wins. It doesn't matter what weapons you have if you can't use them.

Only affects the player and the player's current vehicle if any as far as I know. Might be that it affects the player's entire squad, but I don't think so. And it's not there for any simulation of anything. Just to make the game easier. It is enabled per default in the 'easy' difficulty setting afaik, but disabled in the three other.

If you mean the difficulty setting it gives the player more resilience to damage. Not sure how much though, but it makes a definitely noticable difference.

Totally love the OP! It's so true! So many claiming they play for the realism and for it being so complex and fantastic over the 'dumb shooters' and then they can't read a briefing, sit for 15 minutes at the weapon crate masturbating over its icons, and want everything simplified and spoon-fed so that they can play it exactly like those 'dumb games' but in the ArmA2 engine. :P

A lot of triggers isn't really resource-friendly. Overuse of them tends to lag the game. However what one could do is a lot of markers (if you make a marker called "mine", then copy-paste it, your next marker will be called "mine_1", next "mine_2" etc, giving you a lot of regularily named markers. You could then use a script running in the background, either testing against a fixed range of units (if you know what units you want to make the mines dangerous for), or in a worse case for all units, or through a trigger all units within the trigger area. If going by the last example you could have a trigger covering the entire minefield of markers, running a script for all units inside of it. This code is untested, but should at least point in a working direction of action. I might have borked up the trigger, since I'm not entirely sure if the trigger will reactivate itself if another person enters the area or how it works. My code assumes that it does. Trigger: [b]Type:[/b] ANY PRESENT, Repeatable [b]Condition:[/b] this [b]On Activation:[/b] terminate mines; mines = thisList execVM "minefield.sqf"; [b]On Deactivation:[/b] terminate mines; init.sqf: minelist = []; for "_i" from 1 to [b]X[/b] do { [b]// X is the number of mine_x markers you have![/b] _mineMrk = format ["mine_%1", _i]; minelist set [count minelist, _mineMrk]; }; minefield.sqf: if (!isServer) exitWith {}; while {true} do { { _unit = _x; { _pos = markerPos _x; if (_unit distance _pos < [b]2[/b]) then { [b]// distance in meters from person to marker for detonation[/b] _boom = "someKindOfExplosive" createVehicle _pos; minelist = minelist - [_x]; } forEach minelist; } forEach _this; sleep 1; }; I'm not entirely sure how one does nested forEach-tests (and really it is not adviseable to do that at all, but if the units within the minefield won't be many at a time I guess it works), but I hope my solution works. This script will also remove a mine from the detection-system when it is detonated. Might take some fiddling for it to work right, but the overall structure should be good enough.

Just that all scripts in ArmA2 must have a script-handle. A variable that references the script, and to which return data (if there is any) will be stored. It can have practically any variable name, and it doesn't have to be unique. You can run 50 scripts with the same script handle, as long as they don't return anything (or more specifically: as long as you don't want to store the return data if any).

I use this script for taskHints: fTaskHint.sqf: #define WHITE [1,1,1,1] #define GREY [0.75,0.75,0.75,1] #define GREEN [0.6,0.8,0.4,1] #define RED [1,0.1,0,1] private["_task", "_taskDescription", "_taskStatus", "_taskParams"]; _task = _this select 0; _taskDescription = (taskDescription _task) select 1; _taskStatus = toUpper(taskState _task); _taskParams = switch (_taskStatus) do { case "CREATED": { [format["NEW TASK ASSIGNED: \n%1", _taskDescription], WHITE, "taskNew"] }; case "ASSIGNED": { [format["ASSIGNED TASK: \n%1", _taskDescription], WHITE, "taskCurrent"] }; case "SUCCEEDED": { [format["TASK ACCOMPLISHED: \n%1", _taskDescription], GREEN, "taskDone"] }; case "FAILED": { [format["TASK FAILED: \n%1", _taskDescription], RED, "taskFAILED"] }; case "CANCELED": { [format["TASK CANCELED: \n%1", _taskDescription], GREY, "taskDone"] }; }; taskHint _taskParams; Just run it with for example handle = [MAG_tskObj1] execVM "fTaskHint.sqf";

Well, as stated it'd have to be built into ArmA2, since it can't be done easily with addons. Maybe with scripts and hidden textures to swap the grading on the speed meters and modify the UI, but they are far from pretty solutions. And when it comes to actual HUD display I guess you are right about two entirely different configs. Just thought of it like it many racing and flying games/sims where one can choose the prefered measurements. Would be nice to have that in ArmA. But until it's done by BIS I'd settle with the rest of my post.

Glad to hear the pause helped! Always nice to come back with a rested mind, having had time to absorb and process and work at it in a new light. Sometimes it happens conciously, sometimes subconciously, but as long as it works!

Quality, as long as there is base quantity, which I'd say ArmA2 per default has covered. So on top of what's in basic ArmA2, gief quality! I like to go "WOW!" the first time I use an addon, but then I want to... well... it should feel so natural and well done that I don't think about it. A lack of defects, so to say. Nothing I can notice is wrong, bad, or disturbs me in any way. I don't like having a ton of addons. Sure, I download most of them, but I rarely touch them. I have a few pet addons that I keep running, then a few more just to get into servers although I wouldn't use them otherwise. Most weapon and unit addons are pointless to me. They just add a different flavour that I soon won't notice, and that doesn't actually make any difference. In the end, does it matter if I shoot CDF soldiers with this or that texture on them? Hardly so. Features and polish though! That I like. Stuff like my own addon for disposable launchers, addons for fixed ballistics, okt_noblur, WarFX, fast-roping, vehicles that actually bring new features such as the BMD-1 and BMD-2 addons, barrel fixes (shooting out of all barrels on multi-barrel weapon systems), the Chernarus electrical grid, a whole truckload of features within ACE, and a lot more in that direction. That's the shizzle! Same with CBA, really. Or more specifically Extended Eventhandlers. That is my favourite addon of all times. I still can't understand why BIS hasn't built in a similar system as default in ArmA2 considering XEH has existed since early ArmA1. It is the mother of all fantastic addons!

For the sake of simplicity I'd say KPH and metres. Even though I'd personally prefer to have the actual instruments display what they should display, and then have the UI display KPH and metres, I wonder if that is sufficient for easy, non-confusing access. Actually I'd rather see an in-game option, native to ArmA2 rather than an addon, that lets you choose if to display road speed with KPH or MPH, and air speed with KPH or KTS depending on player preference. Overall though the metric system is, as far as I know, more widely known than the imperial system, making it easier to adapt to even for countries native to the imperial system, than vice versa.