madrussian

@IceBreakr Having a absolute great time with the latest Linger. Noticed a small thing though. Ambient civs are spawning in all areas of 1.337, except for much of the new territory. (I happened upon this discovery while working on an ALICE2 mod.) Here's a quick screenshot to illustrate the current distribution of population centers. Assuming the new areas (west and southwest) should get populations too? In any event, thanks again for Linger and all your other great islands.

Laughed at loud when I read this. No worries Kremator. :) Believe me, I would love to have armed resistance women running about. That was something I think many of us took for granted back in the days of OFP. But sadly BIS decided not to include the proper weapon animations for women in ArmA2, presumably to avoid the bad press that would result from all those inevitable YouTube videos of women getting slaughtered, etc. :p From a "mission possibilities" perspective, however, yes we could really make fantastic use of armed women! I did see some mod work at some point towards this end for ArmA2. Anyone know of any success getting armed women to work? Wow, that's really quite interesting, that one island config can mess up ambient civs on another island. Makes since though, as the same can happen with jungle sounds and water color. In any event, nice detective work guys! Sounds like one way or ther other, we should probably include dead-zone data for Fallujah. If it works for some people, might as well. Speaking of dead-zone data, just finished up Linger: 35 towns * 360° / 30° * 120 seconds = 50400 seconds = 14 hours (Apparently for some islands, it goes beyond an overnight test!) Dead-zone detector revealed 219 bad buildings. That's 6.25 bad buildings per town on Linger, vs 5.7 bad buildings per town on Takistan (which was 137 bad buildings / 24 towns). Here's what Linger's dead-zone data looks like on the map: Linger Dead-Zones (217 kB) Note that many, if not all the new areas from Linger 1.337 do not spawn civilians. I hope IceBreaker eventually adds ALICE2 locations to these incredible new parts of the map! (Though I suppose we can always add them ourselves in the mean time via BIS_alice_mainscope variable "townlist".) I also noticed that the capital Maruko has far fewer bad buidlings than I would have expected. Bad building positions (Linger): Quick update on ALICE2 Release System. I've got the new tags (disarm, women-only, men-only) in place and working. Lots of code cleanup (and some optimization) still to do. Getting somewhat closer to sending you guys a beta. Again, thanks for the interest. I'm getting excited to see what you all might come up with mission-wise for these newly releasable ambient civs!

Orcinus, we are completely on the same wavelength here! This is exactly the type of thing I'm attempting to enable with this project. I wonder if the difference between those who are able to get ALICE2 working on Fallujah and those who can't is simply that some are using Wolffy's Module Improvement Project, and others aren't? Thoughts? Many thanks! Btw- There is something you and Orcinus can help me with in the short term. If you guys would like to see this release system work on more islands, perhaps you could check out vanilla ALICE2 on your favorite terrains, with debug mode on (so you can see the system's operations visually on the map). Allow yourself to teleport around using: onMapSingleClick "player setPos _pos"; You know, simply to see which terrains work and to what extent. Whichever islands/terrains we find worthwhile, we can easily extract dead-zone data for. A little help in this area would allow me to focus on getting this release system polished up, and out for you all to start using. Maybe we can team up with and/or pick Wolffy's brain at some point, if he's interested. Might save a bunch of time/energy. In any event, just thinking out load. No pressure on anyone to do anything they don't want to. :) Another couple quick things I'm adding: Tags for creating only disarmed people -and- tags for women or men only. These would be useful for example, so you can get a fifty-fifty mix of CIV women and disarmed Wolle fighting civs, for a proper mix of seemingly passive civs, before the male RES guys get released, grab guns, and start shooting up the place.

Thanks for the kind words guys! But don't thank me too much until I actually get something released. :) I definitely plan on releasing the dead-zone detection tool along with the ALICE2 release system, with pre-generated data for Takistan and Linger. I must confess however, I'm not 100% sure which islands vanilla ALICE2 even works on though. ALICE2 picks its spawn points based on memory points "AIspawnpos_#", which I think are only found in OA buildings and terrains that use these buildings (of which Linger happens to be one). I believe that's a big part of what Wolffy did with the Module Improvement Project. That is to say, making ALICE2 work with Chernarus and terrains with those buildings. The main difference I've noticed between ALICE1 and ALICE2 is that in ALICE1, civilians get moved inside and outside of solid buildings (with no interiors). While in ALICE2, all the possible buildings have interiors, so there's no need for the system to pop civilians in and out. That's my understanding, anyway. So the short answer is, I can provide dead-zone data for as many terrains as ALICE2 will work for. Btw- Thanks for being willing to run some overnight data-mining Orcinus. I may take you up on that! Yes! Actually to be specific, vanilla ALICE 2 does two things: 1. Limits it's pool of possible created units to those marked as CIVILIAN in the config. 2. Creates the ambient people on the civilian side. I modified part 1, to allow creation of units which are of any side in the config. They still get created on the civilian side (and all in one group per town), but with my release system you can easily: create any-config-side guys, and join them to any side you wish! So yes, your "off duty" idea is quite plausible, but you do need to release these men, to have them fight effectively (independent from random lengthy and quite inappropriate conversations with other AI, etc).

Quick update on progress towards functional ALICE2 release. My automated dead-zone detection system for whole terrains is now together and working well! Town by town, it creates foot units at all available ALICE2 spawn points, orders these men to positions far away, waits a full 2 minutes, then checks to see if they are still at home (indicating a bad spawn point). Bad building combinations are tallied dynamically. System starts with a destination 1000m from town at 0° bearing, then 30°, 60° 90°, ending up at 330°. (In my testing , it is necessary to send the units off at different angles. Otherwise, you miss some bad spawn points.) A new batch of detection men is created for each bearing. For Takistan, which has 24 towns, the process took about 9 and a half hours (so yes it's really an overnight test): 24 towns * 360° / 30° * 120 seconds = 34560 seconds = 9.6 hours Got some interesting results! Takistan has 2048 ALICE2 spawn point combinations that result in unit being created inside a dead zone. This boils down to 137 bad buildings. Here is what it looks like on the map: Note that most towns have a handful of dead zones, while a few towns are perfectly clear of dead zones. Two towns in particular are teaming with them! Feruz Abad and Mulladost, with 27 and 31 respectively. Together these two towns account for 42% of all the bad buildings in Takistan! Here are all the bad building positions (Takistan): I plan on running dead-zone detection for Linger tonight, and in the mean time putting together a demo mission or two for the ALICE2 Release system. Which is of course the overall goal here, having ALICE2 create units, and being able to "release" them from the system on-the-fly (in a clean way), at which point they can be used by the mission creator for all sorts of exciting things. Also beginning to wonder how much use people will really get out of functional ALICE2 release, considering ArmA3 is right around the corner. On the other hand, I'm sure we'll have ALICE3 soon enough, so I figure best to keep going with this. :)

Again, thanks for the encouragement. Keeps me moving forward. For those awaiting a functional release of units generated by ALICE2, more good news! I figured out how to identify and avoid the "dead zones", with startling accuracy. :) Also, changed my mind a bit about not letting the system build dead-zone people. As far as using vanilla ALICE2 has always gone, these dead-zone folks never really caused any problems. They just... stayed at home, and if anything, added a bit of variety. ;) So now in my ALICE2 mod, I simply limit release to non-dead-zone units. I'll say, this modified system is really coming together! For those interested in details... The way in which I'm identifying dead-zones is by brute force. In a separate purpose-built mission (which I guess you could call a tool), I am creating a unit for each and every single spot that an ALICE2 unit can be generated. We're talking about 40-100 units at a time. I then send these newly created brave men off in mass via doMove to a location far away. After a set period of time (a minute seems to do just fine), I check the unit's distance from its individual "spawn home". If the man is stuck at home, well that's a dead-zone. This dead-zone identifying system is entirely automated, and the result is a list of dead-zone buildings which gets populated to the clipboard. My ALICE2 mod then receives this list of bad buildings. You only have to run this dead-zone detection system once per island, and after that the dead-zone data is stored permanently. Upon loading up a mission, the system will auto-load the dead-zone data, specific to the terrain. Best of all, all of this should be completely transparent to the end user. With the dead-zone issue resolved, ALICE2 unit release works like a charm! So far I've got the tool working for one town at a time, and I need to make it process the whole map in sequence, hence a sizable bit of work left to do. Good thing you guys are patient. :p I plan on including pre-generated dead-zone data for Takistan and Linger with the mod. If people want to get dead-zone data for other islands, they can simply run the tool, and paste the results directly into my ALICE2 mod. It should be a streamlined process, well documented in the readme. Please be advised though - As many of you are already aware, even vanilla ALICE2 looks for specific memory points that are only in certain objects, which are only present on certain islands. So without additional heavy modifications, my ALICE2 mod will likely only work on the same terrains that vanilla ALICE2 does. In any event, busy RL weekend/week ahead. Look for an update sometime late next week. We're going to get there!

Ooooh, finally a town! Nice building with a hole in it! (See ~13:10... then seperately at 20:40 from the outside.) Makes me wonder how the level of building destruction will compare with OA. Then again... every other building in that video was intact. Also, whether default AI will make use of buildings... that's probably even less likely but here's hoping.

OK, my ALICE2 mod is now feature complete and essentially ready to go! You can now specify which factions ALICE2 will create and in what proportions. For example, if you want towns to populate with roughly one third ArmA2 civs, one third OA civs, and one third Wolle armed civs, you would add the following to the main logic: this setVariable ["MRU_MAL_FactionProportions",[["CIV", 0.333], ["BIS_TK_CIV", 0.333], ["Civilians", 0.333]]]; Also, unit release is now working flawlessly, with no busyness or lingering strange AI behavior. They get completely released and are free to do whatever you (the mission designer) wish of them. That's the good news. However, I am now up against a rather insidious and perplexing issue, completely separate from my project. (In other words, it's an issue within ArmA2 itself.) Allow me to explain. Most of us are probably aware of "dead zones" for AI pathfinding in various ArmA2 terrains. These are spots where the AI simply will not go. If you setPos an AI inside of a "dead zone", he can be made to move around inside the confines of the "dead zone", but he will never leave. Apparently, there are numerous dead zones throughout some of the default ArmA2 terrains (Takistan in particular). The reason that "dead zones" are a problem for my ALICE2 release mechanism, is because ALICE2 creates civilians inside buildings, some buildings of which happen to be inside dead zones. These "dead zone" civilians never leave the premises of their home building even when vanilla ALICE2 orders them across town for a stroll. They are prisoners in their virtual "dead zone" home. Believe me, it's a big problem to release ALICE2 "dead zone" civilians! Suppose you were counting on this civ you released to go do something, something very important to your mission. Opps, he's just stuck there in his dead zone, never to leave! Worse yet is doing a mass release to join a group (perhaps the player's group). Suppose the "dead zone" guy becomes #2 or #3 in your group. Everyone behind him in formation, lines up based on his position, which is always stuck in the dead zone. Suddenly, half your group is permanently stuck too! :butbut: After thinking long and hard on this complex turn of events, I've thought up a couple potential solutions. If all goes well, I'll have ALICE2 creating only prosperous civs, each able to leave his home, with no one ever confined to a "dead zone"! Then the "ALICE2 Release" will have meaning once again. Anyhow, I'm 98% sure I can manage it. Stay tuned... :)

Quick update, Happy to report that my "Release" function is working properly! Thinking about an "Insert" function as well, to insert editor placed (or otherwise created) foot units to ALICE2. That way you'll be able to release and insert at will, even the same AI man/woman if desired, all on-the-fly, which could allow for quite interesting mission possibilities. Also created a couple useful accessor functions that should come in handy. Separately, I've got the whole ALICE2 data folder (which contains all of it's internal sqfs and fsms) broken out into a subfolder within the mission folder, with those scripts accessing one another. Next up, the modifications to allow creation of resistance side units (as opposed to standard ALICE2 civ-only side units) and mix them in user specified proportions with the regular civ-side guys/gals. Good points. Looked into Module Improvement Project. Very nice! The scope of their project appears to go well beyond what I'm intending to do here. No reason for me to reinvent the wheel though. Perhaps through cooperation, we can (eventually) combine our efforts. (Please be advised, a merge would be necessary to get my new features working with what anyone else is doing. Therefore, I have clearly marked all my modifications to the ALICE2 scripts/fsms with comments.) Good news, I figured out how to do script-only version. :) Also, if you guys would like to check everything out beta-test wise before release, well... that would be awesome!

OK then, starting in. Many thanks for all the encouragement! I will do my best to provide updates periodically on progress... Stay tuned. :)

Ha! Nailed it! It was a doFSM command after all! A slight modification of an FSM loop allows the FSM script to stop, and the unit relents from his ever-so-BUSY state. Also, I've figured out most if not all of the other commands necessary to restore the released unit to fighting form. I do not foresee any additional game-breaking roadblocks to a functional ALICE2 release system here. What the finished product would look like is a mod of ALICE2 with a few additional commands/features: Allow for any side unit generation (including units from multiple sides at once). Note that vanilla ALICE2 only allows for generating Civilian side units. Release of Units from ALICE2 system. At this point you can do with them whatever you wish! (i.e. join the player, take up arms and independently go attack the enemy, get arrested and hauled off, run away from town like a madman, etc, etc) Option to redirect ALICE2 data directory to your mission folder. The idea here is to allow mission creators the capability to easily make additional modifications to ALICE2 scripts directly inside the mission folder. Absent using any of the features, I envision it working just like normal ALICE2. I'm about 98% sure I can put something together here, though it will take some time. Anyone interested in the finished product?

Just spent the last hour+ running amok on the new landscapes and among the new and rebuilt towns. I am simply beyond words. :)

Yeah, I did try that. And everything else I could think of in terms of player interface issued commands. These guys are really stuck. They are the "busiest" guys I've ever seen who just manage to stand there! Well, I'm sure that would work. What I'm really after though is creating more dynamics with the ambient civs. Here's a few scenarios that are crying out for a functional release from ALICE2: The evil occupiers stroll into town, single out a few civs, arrest them, load them in a truck and haul them off to prison. The best part is the player might see all of this happen in real time. A rescue attempt is possible, and if the player succeeds the rescued civs join his group as resistance side fighters. Sure I could wait until the civs end up jailed and swap them out for fresh units, but what if they player decides to rescue them as they are being cuffed / loaded up? A collaborator is working with the enemy, and lives right here in town. An ambient civ is chosen for the role. We like for him to be an ambient civ, that way he blends right in to the population. However, he needs to be able to run away effectively. This is where functional ALICE2 release comes into play. Also, if the collaborator survives the players ambush, we can use him again as a character in a later sub-mission. Thus another reason for functional ALICE2 release... so he won't get deleted when the player leaves town. Citizens of town are kept with little or no weapons by the brutal occupiers. This town has two types of ambient units: regular civ side men and women who will never fight -and- resistance side Wolle armed civ units who have all weapons removed and setCaptive=true (this way they blend right in with regular ambient civs). If the player captures an enemy weapon truck and brings it to town, all hell breaks loose. The majority of the male population release themselves from ALICE2, move to the truck, arm up, and are ready to fight! The beauty of it is, the Wolle units went from passive townsmen who would rather hide inside, to full bore resistance fighters who (based on mission scripting), can subsequently launch an attack on a remote target (in another town perhaps), and this transformation all happened in a matter of seconds! How's that for mission dynamics! Indeed, the possibilities of a functional release from ALICE2 are limitless! But we have to get past this "BUSY" issue first. I suppose the next step is to determine exactly what's making them busy to begin with, in order to come up with a remedy. There's really not that much code inside of ALICE2. Time to start stubbing things out and see exactly what locks these guys down. Thanks for the suggestions guys. Any other brainstorms/ideas on how to un-busy these guys, please let me know. Your ideas could very well save me huge time/effort, and open up a whole new world of mission possibilities. :)

Hey thanks for the help. :) Hadn't tried setting behaviour to "CARELESS". Just tried that... No dice! I've tried doStop, doFollow, disableAI "FSM" / enableAI "FSM". Tried having the unit join another group (even on another side) first, then player group. Tried doFSM (to try and clear out any residual fsm running), tried reversing all the setVariables that ALICE2 does back to nil. These guys are persistently stuck on "BUSY". Maybe the order matters though. Should I be doing these things before the join player or after? Other ideas? Something is bound to reset these guys!

Well we do already have full set of unarmed animations, so that shouldn't be a problem. But yeah I now see your point on AI in particular losing weapons (and the AI routines necessary to get them back). It would indeed open up a whole can of worms. :) On the other hand if they get it right, losing weapons would add so much to the game! Anyhow, I think the ragdolling live units (from blast concussions, etc) is a good start. Hope we see that in Arma3. -------------------------------- EDIT: Some thoughts on related "live ragdolling" middleware itself. Graphics continue to progress in leaps and bounds, but not so with animations / character dynamics. Why? To the best of my reckoning, it's lack of competition in this middleware space. The folks at Natural Motion have held a virtual monopoly for what, two or three years now? How many developers do they license their real time motion generating software Euphoria to? Let's see, a whopping two, Rockstar and LucasArts. (Just looked it up, GTA4 and The Force Unleashed came out way back in 2008.) Add in their in-house product, Backbreaker. Don't they see how much money they could make by licensing their tech to more game devs? Maybe part of the deal is that Rockstar and LucasArts get exclusive rights to Euphoria, and through negotiating, NM can charge an arm and a leg? [Not sure if it's related somehow, but anyone ever wonder why Red Dead Redemption was never even released on PC?] As mentioned previously in this thread, things at Wolfire are heating up with advances in their Overgrowth tech. Will they begin licensing this amazing tech as middleware to game developers? Will this put pressure on Natural Motion to license on a (more) widespread basis? In any event, I'm really hoping these lifelike motor dynamics make it into more games in the coming months. Here's hoping the "live ragdoll" competition heats up and separately, that our beloved Arma3 is not left behind. :cool:

Very nice! As far as I can tell though, those guys are dead/dying. We really need to be able to lose weapon without dying (due to blast, weapon hit by a round, etc). I think the cost/benefit ratio of ragdolling living foot units, is immensely in favor of BI here if they put it in. The wow factor will bring in more customers, and Arma3 makes way more money! Hope we see it in game.

Does anyone recall the WW2 mod (for OFP or Arma1) with extremely good animations for pushing artillery around? (all men manning the unit heave away with legs moving for each, arti piece moved at a realistic and reasonable clip, etc) Was that Lib41-45? Has anyone seen anything similar for Iron Front? (Anyhow, not to take anything away from Invasion 1944... yes at the moment you can push some arti now but it's a static standing anim and imo not very satisfying.)

Turns out I'm already using worldToScreen to get the dot in the right place. I just need some kind of display/control callback functionality to update exactly when each new screen-frame happens (like they have with the "onDraw" for maps). Or perhaps I can use another method all-together. Bit on my revamped vehicle cam: I've been working on it a long time. Basically, 3rd person cam is tied to the vehicle, not the horizon. Much better for just flying around, etc. Because it's a custom cam, you lose the standard vehicle display (inc cursor, etc). So I'm trying to get at least the weapon cursors back. It's very tricky, b/c you have to base everything on current weapon direction, extrapolate (way) outward, then use worldToScreen to place cursor at appropriate location on the screen. Figured that 1st I would just try and get a dot to glue to an AI vehicle in game. Got that part working (again via worldToScreen), but the dot jumps around when the vehic is moving too fast or if you simply move the mouse much at all (as the dot catches up to where it's suppose to be). I really need some way to sync with each frame, as BIS appears to be doing. :)

Hi all, I'm attempting to draw a simple icon on the screen and have it follow an object around. So far I've got a colored indicator dot glued to a helicopter and it follows the helo around, which is great! But the dot kind of jumps around when the helo gets going too fast or when you move the mouse around much (though the dot always catches up to helo screen position). Long term goal here is a revamped vehicle cam, so the indicators must be spot on with no deviation to what is shown on-screen. To see what I'm after with these icons, check how the default weapon cursors, grenade throwing icons, and "group icons" behave in-game. They are 100% precise with what you see on screen at any given time. In other words, I need my custom icon(s) to be drawn once per screen-frame. Specifically, I have noticed that ctrlAddEventHandler has an event for maps called "onDraw" that fires when the map is drawn (i.e. every time the map is drawn). Tried it with maps and it works perfectly/precisely at exactly one draw per map frame! So Here's the question: Anyone know of anything similar for non-map controls? Any event or similar for non-map controls to callback to a draw function once per screen-frame? Again, I see BIS doing this (once per screen-frame) with default weapon cursors and similar icons, so there must be a way!

Alright, after a bit more digging, I now have passive dialogs up and running without mouse pointer! (Actually, passive "resources" is probably the more correct terminology.) Found out how inside ShackTac Fireteam HUD. Apparently the cutRsc command is the key. In any event, works like a charm! Thanks guys. :)

Hi all, I'm attempting to create a non-interactive dialog, simply to monitor things going on in-mission (monitor variable values, mark units in real-time 3D with floating indicator, etc). Specifically, I want the player to retain control and be able to continue moving around in-game while the dialog is up. I am familiar with how to make a basic dialog. However, I'm pulling my hair out trying to get this one aspect to work properly: Having a dialog up without the mouse pointer, so the player can retain control of his unit and continue moving around. One property is obviously important to making this happen: enableSimulation=1, which keeps the game going while the dialog is up. However... Anyone know what is needed to keep the mouse pointer from showing up in a dialog? ... in order to create non-interactive info-only dialog?

Thanks for the responses so far. :) I'm pretty sure it is indeed possible to have passive info-only dialogs, based on how hint/hintSilent illicit no mouse pointer and let you continue walking around while they are up. Will take a good look inside examples provided, and report back if/when I figure it out. However, if someone already knows how to ditch mouse pointer in dialogs (display property or otherwise), by all means let's hear it!

@NoRailGunner Thanks for trying this out. Interesting we got different results. I'm off to run some variations on this test and report back shortly! Hopefully we can pin down the discrepancy here. EDIT: OK, it took a large number of attempts, but I finally got the BMP3 to consistently fire at different targets simultaneously. Some observations (same basic test, BMP3 facing its main turret backward, only this time with a large # of invulnerable west men in back, me the player on foot and invulnerable in front): Most of the time, when the main gun was engaged with the large group of infantry behind, the front hull gunners ignored me as I ran around the front of the BMP3. I'm thinking this could probably use some tweaking. When the west AI were closer (though still only within firing arc of main gun, not front gunners), it was seemingly impossible to get the BMP3 hull gunners to shoot at me while the main gun was engaged with the west footmen, without the main gun switching to me at exactly the moment the hull gunners opened fire. Again, not ideal, but not necessarily broken either. Most of the time in this case, I could run around in front of the BMP3 unmolested, without being targeted at all. I guess the BMP3 hull gunners were distracted? Perhaps this can be considered realistic. However, I probably got the BMP3 to split fire between front/back in only about 2 of 40 tries (when the west men in the rear were close). When the west AI were further away, finally I could get the BMP3 to split fire between front and back more consistently. The interesting thing here was, while the main gun was engaged with the rear forces, only the right hull gunner would ever fire at me... never the left. When the main gun would join and start shooting at me too, only then would the left hull gun join in. Hmmmm... Anyhow, that was repeatable. To summarize, after extensive observation I stand corrected about my claim that vehicles with multiple turrets never fire on more than one target at a time. But I have found at least one clear case (see initial post in this thread), where the AI is failing consistently at making any use of its additional turrets. A more important item I'd like to focus on is assignedTarget: As it stands (again please correct if I'm wrong), there is no way to get the current target of a turret gunner. I hereby advocate for assignedTarget to be expanded to turret gunners (in ArmA3, if not hopefully yet in ArmA2). :)

I've been doing dispersion work recently (preliminary testing, etc), and was shocked to discover that currently in ArmA2, AI crewed vehicles with multiple turrets only target one individual enemy at any given time. Even when the turrets are facing opposite directions! One would be inclined to believe that each turret could and would follow a separate target. After all, isn't the point of turrets to shoot at different things at the same time? :) I have high hopes for ArmA3, and the issue currently may not be obvious in regular ArmA2 gameplay, but can be proven beyond any doubt with a simple test in the editor (1.60 and previous versions): 1. Create an AI crewed BMP3. (I chose a BMP3 because it has one main 360º turret, plus two forward-facing hull gunners that have limited field-of-fire). 2. Have the BMP3 watch something like an empty car directly behind it (so that the main gun is facing backward), via doWatch. 3. Create two west men, and make them both impervious to fire via "this allowDamage false" 4. Have the men walk out from behind buildings, first one behind the BMP3, then the other man in front on the BMP3. 5. Carefully watch what happens. The BMP3 will fire begin firing on its first target, the man behind it, with the main turret, as expected. Here's the problem: The man in front is a legitimate target and the BMP3 has two hull gunners capable of opening fire on this second man. However, they do not open fire. Instead, the two hull gunners will wait indefinitely... until the moment this legitimate target in front is actually "targeted" (which you can monitor via assignedTarget). Unfortunately, currently in ArmA2 it's one target per vehicle at any given time (regardless of multiple turrets). IMO, it should be one target per turret at any given time. Can you imagine a B-17 bomber, bristling with MGs, that can only target one enemy fighter at a time?!? :eek: Incidentally, assignedTarget operates on a vehicle (i,e, tested and for vehicles, it only works for vehicle itself or the commander, not the turret gunners), where as IMO it should operate on individual turret gunners. Anyhow, hope this gets sorted by ArmA3, hopefully yet in ArmA2. [Finally, I figure this deserves its own thread as it's quite fundamental to the game engine... let's see if mods agree. Thanks!] EDIT While the above case of vehicle AI-only crew not making effective use of its multiple turrets (i.e. not shooting someone right in front of them with hull gunners just because the main gun is engaged) is indeed repeatable, further testing has revealed that multi-turreted AI vehicles are indeed firing at multiple simultaneous targets, at least in many cases. :)

You would think so. However, based on my testing... seems not! :)