madrussian

Quick update, I'm very close. Here's a quick snapshot preview (in case I get hit by a bus in the next couple days, so these formulas don't get lost, etc): I've got the part that projects skillFinal working. Specifically: Provided with setSkill value, works great for projecting expected skillFinal (accounting for all the factors), woohoo! Still working on going backward from skillFinal to setSkill (the Holy Grail), and of course that last bit is a real pain in the behind. In the mean time if you want to take it for a spin, create folder inside mission root and name it "MRU_FinalSkillCalculator". Then place these files inside folder: In "init.sqf", prep the system (once) via: call compile preprocessFile "MRU_FinalSkillCalculator\_prepFSC.sqf"; Test via: _difficultySKILL = missionNamespace getVariable ["MRU_FSC_DifficultySKILL", -1]; _difficultyPRECISION = missionNamespace getVariable ["MRU_FSC_DifficultyPRECISION", -1]; _skill = 0.38; _subSkill = "general"; //_subSkill = "aimingAccuracy"; //_subSkill = "aimingShake"; //_subSkill = "aimingSpeed"; //_subSkill = "commanding"; //_subSkill = "courage"; //_subSkill = "endurance"; //_subSkill = "reloadSpeed"; //_subSkill = "spotDistance"; //_subSkill = "spotTime"; _projectedFinalSkill = [_skill, _subSkill] call MRU_FSC_ProjectedFinalSkill; Loon setSkill [_subSkill, _skill]; _actualFinalSkill = Loon skillFinal _subSkill; hint format ["_difficultySKILL: %1\n_difficultyPRECISION: %2\n\n_skill: %3\n_subSkill: %4\n\n_projectedFinalSkill: %5\n_actualFinalSkill: %6", _difficultySKILL, _difficultyPRECISION, _skill, _subSkill, _projectedFinalSkill, _actualFinalSkill]; If you can, please try out different _skill and _subSkill values (along with different SKILL and PRECISION slider values, along with different mods that modify CfgAISkill) and let me know how it works. [Disclaimer - Please don't expect 100% exact perfect results, as you might experience some tiny rounding errors on the order of 0.001 at most. Anything out of whack more than that, please let me know asap.] (Btw - What's the best clean, free file uploading site these days?) Alright, back into "head down" mode.

@all Great insight, tips, tricks, etc. @Grumpy Old Man Wow, interesting videos! Surprising to say the least. In my own experience, in terms of how easily enemies notice me, and how accurately they return fire, etc: I get noticeable change in-game when I adjust the SKILL and PRECISION sliders. (Note - None of this is anything I can back up with hard data like you posted Grumpy.) I notice perhaps a bigger change when simply running IFA3 (which modifies CfgAISkill values) or not. Specifically, in my dynamic mission, top player can pick player factions and enemy factions, and while playing with non-IFA3 units, I can tell absolutely whether IFA3 is loaded or not based on how the AI reacts/shoots. In any event, my testing shows that SKILL and PRECISION do indeed impact skillFinal. Here are a series of good graphs ImperialAlex posted on the AI thread that mirrors my own results: I'll be happy if I can apply skill adjustments and get a consistent desired skillFinal result. I believe this is 100% achievable, with a step-by-step approach. First, we need a way to get game's Difficulty SKILL and PRECISION settings (as it will impact skillFinal). I've not yet seen a command to get these (and if it's out there, please simplify all this by posting), so I wrote my own function (see below). My plan was to use setSkill and observe resulting finalSkill, then work backwards to get Difficulty's Skill and Precision. As CfgAiSkill will impact finalSkill, we must account for it. Here is CfgAiSkill for vanilla game: aimingAccuracy[] = {0,0,1,1}; aimingShake[] = {0,0,1,1}; aimingSpeed[] = {0,0.5,1,1}; commanding[] = {0,0,1,1}; courage[] = {0,0,1,1}; endurance[] = {0,0,1,1}; general[] = {0,0,1,1}; reloadSpeed[] = {0,0,1,1}; spotDistance[] = {0,0,1,1}; spotTime[] = {0,0,1,1}; For comparison, here is CfgAiSkill for IFA3: aimingAccuracy[] = {0,0,1,0.8}; aimingShake[] = {0,0,1,0.6}; aimingSpeed[] = {0,0,1,0.7}; commanding[] = {0,0,1,0.8}; courage[] = {0,0,1,0.7}; endurance[] = {0,0,1,0.7}; general[] = {0,0,1,0.9}; reloadSpeed[] = {0,0,1,1}; spotDistance[] = {0,0,1,0.9}; spotTime[] = {0,0,1,0.7}; To review how CfgAiSkill calculates, here's the example from the wiki: To simply things, hopefully we can make some assumptions about how mods will use CfgAiSkill. First, the original range should be 0-1 (array's first and third element). Second, the resulting range (array's second and fourth element) should go from a smaller value to larger value. (If anyone is aware of a mod that does not conform to these assumptions, please advise and I'll modify function below to account for these too.) Here's my function to determine game's difficulty SKILL and PRECISION values. Works for my purposes so far (tested with Vanilla only first, then with IFA3 loaded). Anyone mind confirming this correctly returns SKILL and PRECISION for you too? MRU_DifficultySkillAndPrecision = { private ["_difficultySettings","_general","_aimingAccuracy","_maxGeneral","_maxAimingAccuracy","_SFG_for_SS1_at_DS0", "_SFG_for_SS1_at_DS1","_SFAA_for_SS1_at_DS0","_SFAA_for_SS1_at_DS1","_group","_logic","_skillFinalG", "_skillFinalAA","_difficultySkill","_difficultyPrecision"]; _difficultySettings = []; _general = getArray (configfile >> "CfgAISkill" >> "general"); _aimingAccuracy = getArray (configfile >> "CfgAISkill" >> "aimingAccuracy"); if ( ((_general select 0) == 0) and ((_general select 2) == 1) and ((_aimingAccuracy select 0) == 0) and ((_aimingAccuracy select 2) == 1) and ((_general select 3) > (_general select 1)) and ((_aimingAccuracy select 3) > (_aimingAccuracy select 1)) ) then { _maxGeneral = _general select 3; _maxAimingAccuracy = _aimingAccuracy select 3; // skillFinal "general" for setSkill 1 at Difficulty Skill 0 _SFG_for_SS1_at_DS0 = _maxGeneral * 0.8; // skillFinal "general" for setSkill 1 at Difficulty Skill 1 _SFG_for_SS1_at_DS1 = _maxGeneral; // skillFinal "aimingAccuracy" for setSkill 1 at Difficulty Skill 0 _SFAA_for_SS1_at_DS0 = _maxAimingAccuracy * 0.8; // skillFinal "aimingAccuracy" for setSkill 1 at Difficulty Skill 1 _SFAA_for_SS1_at_DS1 = _maxAimingAccuracy; _group = createGroup sideLogic; _logic = _group createUnit ["Logic", [0,0,0], [], 0, "NONE"]; _logic setSkill 1; _skillFinalG = _logic skillFinal "general"; _skillFinalAA = _logic skillFinal "aimingAccuracy"; _difficultySkill = (_skillFinalG - _SFG_for_SS1_at_DS0) / (_SFG_for_SS1_at_DS1 - _SFG_for_SS1_at_DS0); _difficultyPrecision = (_skillFinalAA - _SFAA_for_SS1_at_DS0) / (_SFAA_for_SS1_at_DS1 - _SFAA_for_SS1_at_DS0); _difficultySettings = [_difficultySkill, _difficultyPrecision]; deleteVehicle _logic; deleteGroup _group; }; _difficultySettings }; OK, so far so good. I'll keep going and report back...

Neat command, learning something new every day around here. I think I really want to tally the kills and compare against the engine's tallying though, as I have a custom Group-Respawn style system running, and it's not 100% clear the engine is counting normal kills correctly on client machines, considering the player's are controlling different unit upon death, etc. Anyhow, my dad claims it's not counting all his kills, and now he'll have a chance to substantiate this. That looks like just the ticket! Thought more about the methods I was considering: 1. Display extra kills info on Debriefing Page 1 -> Wouldn't have worked anyhow due to that error. 2. Display extra kills info on Debriefing Page 2 (Statistics section) -> Would have negative performance impact (creating all those dummy guys in the middle of no-where just to be killed. Plus players would have to count their support kills at the end, etc. This was probably the worst option now that I think this through. 3. Display extra kills info on Debriefing Page 2 (Tasks section) -> Did some quick experiments and using tasks actually looks pretty good. Created two extra tasks (both task type "target", which looks like a bulls-eye) just prior to ending mission [one for player kills, one for support kills, each breaking down the type of vehicle kills (in my case fighting vehicles & transports), plus whether they were destroyed vs simply knocked out)]. Advantage here over "custom debriefing section" would be players can see everything all on one page (vs having to flip page to see custom kill summary). 4. Create a dialog and overlay it on top of Debriefing -> That would have been a royal pain, if it's even possible! So sounds like it's down to "custom debriefing section" vs Tasks, both which should work well. Will experiment to see which one looks better / has better feel. Thanks for the help!

I'd like to add some extra text to the Debriefing. Bit of background. When playing my dynamic co-op mission, at the end we like to count our kills on the Debriefing Statistics page and compare to each other. Often I get 30-40 kills and my dad (for instance) gets 2-3 kills. But that is showing only the units we personally killed. In my mission, a number of supports (like Mortars, Artillery, Bombers, etc) are awarded to each player and players call these in and end up killing a ton of "extra" enemies that way, which of course aren't included in the final Debriefing Statistics page. Basically I want to give players (especially my poor dad) credit for all their kills. I would like to tally and display these "Support kills", if you will. So, the tallying is trivial, but getting them to display on Debriefing page is more of a challenge. Here are the methods I can think of (so far) to accomplish this: 1. Display extra kills info on Debriefing Page 1 This should, in theory, work via setDebriefingText, but unfortunately this command is listed as broken (and quick testing appears to confirm is indeed broken) 2. Display extra kills info on Debriefing Page 2 (Statistics section) First off, this seems to be a good place for extra kill info. Could work in the following manner: Every time a player's support kills a unit (via killed EH), I can immediately create an identical unit off the middle of no-where, somehow name it appropriately to identify is as killed by a support (<- need help with this part), then create a projectile and use setShotParents to set the instigator as the player. Then send the projectile into the dummy unit to kill it, allowing the player to get credit for his support killing the unit (and then delete dummy). The part I need help with here is the "somehow name it appropriately to identify it as killed by a support". Seems that normally when player kills a unit, it is listed by it's displayName in the config. For instance if player killed a "B_Soldier_F", on Debriefing Page 2 (Statistics section) it gets displayed as "Rifleman". I need it to say something custom like "Rifleman (killed by Bombers)". Any ideas on how to correctly name/identify units (prior to killing them) in this case? 3. Display extra kills info on Debriefing Page 2 (Tasks section) Prior to ending the mission, I could always create a dummy task and add to the end of the normally displayed tasks. Task could say something like "Your supports killed 23 men and knocked out 2 vehicles." The advantage of this method is I'm confident I can pull it off. 4. Create a dialog and overlay it on top of Debriefing Talley the kills, and show it in a simple window. The big hitch here is I would need to display the dialog after the mission is technically complete. Is this even possible with mission code? Perhaps, I'd simply spawn a script in UI namespace which would persist beyond the end of mission, popping up the dialog? Anyone have any related knowledge/experience? So what do you all think? Which is the best method for displaying support kill info in the Debriefing? I welcome any and all help, even simple things I may have missed. Thanks!

I'm getting white line lately too. I haven't tried to pin it down to particular mod (or units within mod) yet. Seems like I had CBA, CUP, IFA3 and FOW running.

Sounds good! As you continue to tweak and improve external cameras, please keep us 3rd person gunners in mind. Note that under normal circumstances in ArmA3 (default vehicles included), on steep terrain, 3rd person gunner views are regularly completely blocked by the vehicle, in part because the cam is oriented to the horizon and not the vehicle. So margin for too much blockage may be slim. Again, things feel pretty good right now for those halftracks and M3s (which were the biggest offenders), but I'd hate to see them slide back into being too obstructed. Interesting. I only ever noticed this action on IFA3 halftracks and M3s. I suppose perhaps another mod was adding it, but for a very long time now I've been running IFA3 with CUP only, since RHS was blowing away config values on IFA3 turrets (as you may recall I reported accidentally as IFA3 issue and you correctly identified as RHS issue, which if I recall correctly their team subsequently fixed -> but that got me worried about other potential turret conflicts between mods). I always run CUP alongside any mods when playing because it fixes a bad animation transition error in the default game that persists to this day (stationary kneeling with rifle directly to sprint if memory serves). When trying to confirm or isolate an issue, of course I run with no mods and then with only the particular mod. In any event, seems like that "Move to Driver" action disappeared around time of your "quality of life" update. I started using setUnloadInCombat in two specific cases. First, you may recall (and to review for anyone first hearing about this): I wanted to fill out all turrets on AI-only IFA3 tanks, but ran into a bizarre issue where the extra turret gunners (those additional beyond regular gunner and commander, like the hull gunners) were errantly disembarking upon contact with the enemy. Eventually I pinned this problematic disembarking down to occurring the moment their nearby same-side units were hit, including same-side vanilla foot units. Further experiments revealed that even IFA3 extra turret gunners with disableAI "ALL", would eject in this manner! Got stumped for eons, thought of trying setUnloadInCombat on many occasions as a potential solution but quickly dismissed and never tried it (because after all entering COMBAT mode would not by itself cause extra turret gunners to disembark). Here's quick ref: vehicle setUnloadInCombat [allowCargo, allowTurrets] One day I tried _vehic setUnloadInCombat [false, false], and by God that worked, and kept those extra turret gunners in their seats! Happy to have finally solved that issue, I didn't bother to experiment further, though seems to reason allowTurrets was the key part. Second: In my dynamic mission, I have trucks (and more recently also APCs including halftracks) that bring in troops and drop them off. Vehicle crew in one group, cargo guys in another group. By design I intended for vehicle to unload cargo men exactly once, and then for the driver to drive away to extraction point and be deleted. The default game's "unload upon contact" mechanics normally works well and in fact we all rely on it. However, I was experiencing numerous related issues with the end result being that the troops would either not disembark or would disembark and then get back it, which is obviously a huge issue. Also in some case when the driver was killed enroute to dropoff location, the default game engine has someone else in the vehicle take over as driver, in this case a cargo group unit, which was also a big problem, messing up my scripts. Eventually I arrived at keeping everyone in via _vehic setUnloadInCombat [false, false], and scripting my own disembark, which works well (everyone disembarks exactly once) and had several side-benefits: Dead men are not ejected during disembark (which happens sometimes during default game disembark), skipping over dead men (vs how default game disembark gives dead men full delay), and finally intentionally faster than default game disembark (shorter cycle timer). Long story short: Seems to me that setUnloadInCombat is probably necessary to stop extra turret gunners from errantly disembarking (which otherwise would occur when nearby same-side units being hit as described above). IFA3 addons should probably apply in this manner automatically. (Perhaps you guys already added this to extra turret gunners?) Alternately, no need to automatically apply setUnloadInCombat to cargo units. (Mission creators can apply as desired, as I needed to.) AI driver getting out was related specifically to player's "Move to Driver" action (which again that action now appears to be gone). Player would use that action to bump out driver and take his place. AI driver would move to cargo. Not really sure why AI driver would then get out, but upon contact he would. Nothing to do with anything I scripted in that case. Possibly somehow related to "extra turret gunners ejecting when nearby friendly unit hit" issue. Then often he would later randomly get back in... if I recall correctly, again into driver position! Sounds awesome! May I suggest some purposed element of randomness to certain crew reactions, so things don't seem too robotic. For instance, maybe crew does not always realize how bad they are hit and that they are about to explode, so don't bail out in time (plus alternately sometimes only some crew make it out before explosion). Also, maybe when tank is immobile, most of the time they stay in, but sometimes they bail (thinking perhaps explosion was imminent, when in fact it was not). Otherwise, player will never get a chance to take over and man the busted but otherwise functional tank (with functional guns). Great questions, unsure at the moment. If/when I learn more (hopeful), will report back! If the question is whether IFA3 addon should apply this automatically, I would say no, at least for now. Leaving enableAttack at default engine value will ensure AI act in manner consistent with default game, unless it turns out those extra turret gunners are indeed having an additional impact on delay that normally arises from AIs encountering enemy. In my dynamic mission, I fill out all turret gunners on all vehicles, on all sides (player side, side allied with player side, and enemy side). On the enemy side, I want the enemy to move in and attack more methodically, and don't mind the (sometimes big) delays. On the player side, the only armed vehicles the player ever gets come via player's call for Armored support. Player orders these vehicles around via icon on the map, and it needs to be responsive, so I use enableAttack false. So I think it's a case by case basis, and thus again IFA3 addon should probably not apply enableAttack automatically. For mission creators, quick points about enableAttack: enableAttack has a HUGE impact on how fast AI will continue to move along once they contact the enemy. This applies to foot soldiers for sure and (apparently, based on my own recent discoveries which may need to be fine tuned) also to vehicles. (Disclaimer - There is a chance this only applies to vehics with extra turret gunners. Need run more experiments to know for sure.) More specifically, leaving enableAttack at default value (true) will cause AI-only foot groups to break into subgroups (which can be detected via formLeader) upon contact with the enemy. The subgroups will move out to spots chosen/ordered by the AI group leader. Upon arrival, these subgroups will stay for a random amount of time. Unless something has changed, at the upper end this can exceed six minutes. Based on my testing (long ago, again this may have changed since), it did not matter whether the AI killed all enemy nearby or not, they would still wait out the whole time. If I recall correctly, when testing this I had AUTOCOMBAT disabled on all the AI. <- Can read about these experiments here. Setting AI-only foot group to enableAttack false inhibits group leader from issuing these move out subgrouping commands. This allows your AI-only group to move along quickly and reach it's destination much faster! For some reason, with fully crewed AI-only IFA3 tanks (and perhaps all vehicles inc vanilla, unsure at this moment) setting group to enableAttack false will cause tank to keep moving to WP, where otherwise it stops along the way to fight for long periods of time, similar to how foot soldiers operate (as described above). Now how do we reconcile this, considering all AI-only tank crew are inside the tank? My guess is in case of AI tank group with enableAttack true, tank leader is ordering his driver to move out in the same manner as with AI foot soldiers. (Would be interesting to learn whether vehicle subordinates are degrouped, as occurs with foot units.) Long story short. More enableAttack discoveries to be made. In the mean time (as mission creator): If you want your AI-only groups to stop and fight along the way, leave enableAttack true (default value). If you want your AI-only groups to fight along the way but not stop (or minimally stop), set enableAttack false. If you want some combination of stopping and moving along, create a script that toggles enableAttack back and forth on a timer, and also when appropriate account for regrouping the resulting subgroups, and reversing the stops (command chosen based on whether default game is stopping them via stop, doStop, or another method)

A few quick thanks: First, thanks so much for the recent "quality of life" update, with emphasis on bringing all armored vehicles up to A3 standards. Everything runs like a dream now, and I find myself amazed every time I fire up the mod! Second, many thanks for fixing 3rd person gunner view on several vehicles. Many were so completely broken before (placed directly behind the vehicles). Now we can shoot properly while in 3rd person! (All due respect for 1st person purists, who can always simply turn off 3rd person.) Third, thanks for removing the troublesome "Move to Driver" actions on Halftracks and M3 scout cars. The problem was: With a (different grouped) AI as driver, when player took over as the driver, bumping AI driver out, and then later player moved back over to cargo spot, the AI driver would not move back into the driver seat. Instead, he'd hang out like a dummy in the back seat. This coupled with that "Vehicle crew (except driver, gunner, & commander) disembarking upon nearby friendlies hit" issue, would consistently cause my drivers to get out of halftracks and run away, often in the middle on combat! Thankfully, removing this "Move to Driver" action, plus _vehic setUnloadInCombat [false, false] keeps everyone in their proper seats. Good fix! Quick observation about tanks recently: I noticed in latest IFA3 version, AI tank crews will (in most cases) stay in their vehicles upon tank becoming immobile (as detected via canMove). This of course is in contrast to default game, where AI crews always disembark upon vehicles becoming immobile. I assume allowCrewInImmobile is being used to keep them in? If so, I'd say good call. Makes more sense that way. [Now in this moment, I'm wondering if this new "AI remain in vehic upon immobile" mechanic is IFA3 related or perhaps default game's Tanks update is causing this. Will run some tests eventually to learn more, but anyhow curious if you guys have quick answer either way?] Also noticed that every time IFA3 tank is damaged (and immobile) and explosion is imminent (which if I recall correctly is caused by critical damage to fuel system?), in this case the AI crew will always bail out. This is normal and matches default game, but when coupled with AI crew always staying in immobile tanks that are not going to imminently explode, is perhaps a bit immersion breaking? <- Because you always know whether vehicle will blow up or not based on whether AI crew bails (unlike default game where they always bail upon tank becoming immobile). Just an observation about the pros/cons of using allowCrewInImmobile. Noticed that when IFA3 tank gets one track knocked off, AI driver will keep trying to drive, which makes sense for a few seconds (as he would have to learn about his newly busted track, etc). Unfortunately, AI driver will keep trying to get the busted tank moving indefinitely, which causes the tank to spin. <- This part looks silly and is immersion breaking. Coupled with the slow WW2 turrets, this also causes tank to lose effectiveness as a fighting unit, as driver is causing gunner to not be able to line up his shots. I'm guessing this mirrors the way AI drivers operate in default game with allowCrewInImmobile true, so really just another observation about the pros/cons of using this command. (Anyhow, I can envision a quick script to detect immobile tanks and stop the AI drivers a few seconds later.) Big discovery: Have any of you experienced fully crewed AI vehicles (the kind with extra turrets like IFA3 tanks) getting stuck for long periods of time? Not sure if this one applies to IFA3 specifically or not, but hopefully this will help someone. In my dynamic mission, a long time ago I added an Armored support, which gives the player a AI-crewed halftrack or tank that they can control via an icon on the map. (Will just call them tanks here for simplicity.) Long story short, player could successfully order these tanks around, until the tank encountered enemy units. At this point tank would basically stop for an extremely lengthy period of time. It was extremely frustrating to desperately need that new Armor somewhere on the map (as my mission is survival/defense styled), and watch helplessly as tank sits there, completely stuck (even after tank killing all enemies around it), until some arbitrary super-long timeout (up to and sometimes over six minutes, if it's similar to issue I was having with infantry, detailed here). After a ton of new experiments, I learned it really wasn't COMBAT mode related, and rather something to do with tank crew detecting enemy targets. (For example, tank wouldn't get stuck simply going into COMBAT mode.) I tried everything under the sun to get them moving, and nothing worked, until this bit: _group enableAttack false ^ That was the key! They move around fluidly/perfectly now! Quickly, here's my simple cocktail for keeping AI armed vehicles that are fully crewed (inc all turrets) moving (and mounted, particularly critical with IFA3 vehicles): _group allowFleeing 0; _group enableAttack false; _vehic setUnloadInCombat [false, false]; [Note that in this case I wanted to stay away from disableAI "AUTOCOMBAT", because I detect/display when player's map-controllable groups get into combat, so the player can see on the map where the fighting is going on.] Finally great updates lately, please keep going!

Nice to see it confirmed Grumpy, thanks. Any ideas on a workaround? The closest thing I can come up with so far is teleporting the cargo guys out and back in directly after the doFollow (which indeed keeps them from disembarking) and doing all this inside a call etc, but it's really ugly as you can see the transition big time (i.e. can see the animation of them sitting back down). Hoping I can do better, as it's quite offensive looking.

Congrats and thanks on latest release! Really awesome fixes and content. Can't express enough my gratitude! Quick things I noticed so far: Some new IFA3 Russians started popping up in my dynamic mission, who are mostly silent but speaking certain phrases in English. I was curious, and opened up CfgVehicles to find a whole slew of (new?) guys: The ones that start with "LIB_SD_ALLIES_" and "LIB_SD_AXIS_". They all seem to have "LIB_NoVoice" in their "identityTypes". I looked in CfgVoices and saw "LIB_NoVoice", and in main config I see LIB_RadioProtocolNoRadio. Nice work! Wanted to let you know though that these guys are not completely silent. When you have them in your squad and order to report status via ~-5-5, they report back coordinates in default English voice. (Edit - I double-checked, and indeed this happens with only IFA3 loaded.) Anyway, are these guys simply base types? (If so, I'll simply exclude them.)

Hi all, I managed to get sideRadio command working, could use bit of help on one very important aspect. Here’s my "description.ext": class CfgRadio { sounds[] = {}; class BUB_CloseThatDoor { name = ""; sound[] = {"@A3\Dubbing_Radio_F\data\ENG\Male01ENG\RadioProtocolENG\Normal\100_Commands\closethatdoor.ogg", 0.001, 1.0 }; title = "Close that door!"; }; }; [Please note - For accessing game files with these radio commands (customRadio, globalRadio, groupRadio, sideRadio, vehicleRadio), I found the @ symbol (see above) to be absolutely critical, and as far as I can tell, it’s not listed in anywhere in the refs for any of these commands!] Here’s my call: Loon sideRadio "BUB_CloseThatDoor"; It works! That is to say: Loon says "Close that door!" aloud over the radio A sideChat message is displayed from Loon that says “Close that door!” While Loon is speaking, player hear the radio crackle (very important, so you as player can tell it’s coming over the radio) plus radio beeps. This radio “message” is queued up with all the rest of the radio messages coming in. For instance, if you run the sideRadio command in a row 10 times without delay, he will say each of his messages only after the last message is complete. In the mean time, if someone else chimes in over side channel, the new guy’s message goes into the queue too, and is spoken at the appropriate time, etc. The end result is no one talks over anyone else and all messages are spoken in turn (with none being missed). Thankfully this is exactly what I’m looking for! Here’s the problem: He says his phrase at full volume, which is very loud as compared to the regular radio traffic. This makes it impossible (or at least extremely difficult) to tell that he’s suppose to be speaking over the radio. If you really strain your ears, you can hear the radio crackle, but as mentioned it’s totally inconsistent with all the normal radio protocol being spoken, and sounds pretty much like he’s standing right besides you. Whereas in my case, he’s halfway across the map! My next thought was I simply need to reduce the volume. Makes sense, right? Well, unfortunately I can’t seem to get the volume control working, and that’s what I need help with. In the reference for “description.ext”, here's what it says about CfgRadio: Importantly, CfgRadio classes define sound (see above) as: [sound file path & filename, volume, pitch] After some quick testing, the sound file path and pitch controls work great but I can’t seem to get the volume control working at all. I'm assuming that in the example "db" is a numeric constant that must be define elsewhere. Having no idea what "db" is, I try the shotgun approach, by defining all of these test classes in CfgRadio (again, inside my "description.ext"), all in an attempt to get my Loon to speak at different volumes: Here are my test calls (referencing Test classes 1-20 above), all attempting to affect volume: sleep 1; Loon sideRadio "Test1"; sleep 0.1; Loon sideRadio "Test2"; sleep 0.1; Loon sideRadio "Test3"; sleep 0.1; Loon sideRadio "Test4"; sleep 0.1; Loon sideRadio "Test5"; sleep 0.1; Loon sideRadio "Test6"; sleep 0.1; Loon sideRadio "Test7"; sleep 0.1; Loon sideRadio "Test8"; sleep 0.1; Loon sideRadio "Test9"; sleep 0.1; Loon sideRadio "Test10"; sleep 0.1; Loon sideRadio "Test11"; sleep 0.1; Loon sideRadio "Test12"; sleep 0.1; Loon sideRadio "Test13"; sleep 0.1; Loon sideRadio "Test14"; sleep 0.1; Loon sideRadio "Test15"; sleep 0.1; Loon sideRadio "Test16"; sleep 0.1; Loon sideRadio "Test17"; sleep 0.1; Loon sideRadio "Test18"; sleep 0.1; Loon sideRadio "Test19"; sleep 0.1; Loon sideRadio "Test20"; Test Result: He says all 20 lines (great!) and he uses the radio protocol (great!), but he speaks them all at exactly the same volume (bad). So now I'm somewhat stumped, but probably I’m missing something trivial here. Anyone know how to successfully increase or decrease the volume of phrases spoken via sideRadio? Btw- I welcome any and all ideas, even simple things I may have missed. Thanks!

Thanks for the reply. I understand that one ogg file will probably be louder or quieter than another. The problem is, I am trying different values for volume setting on the same ogg file, and they have no absolutely no effect on actual volume. Rather, all sounds play at full volume. Please see my 2nd "description.ext" above (which I now unspoilered, the one with 20 blue texts) and note that I'm trying all different values for volume (see blue text). Again, none of these volume changes do anything to change actual volume of the sound when played via sideRadio. Any idea what specifically is wrong in my "description.ext" that's preventing the volume from changing? Anyone have a working example of sideRadio playing the same ogg at different volumes? (Anyhow, perhaps I just found a bug. Can someone confirm?)

I tried your mission root function with mine side by side in test mission (running within non-PBO and PBO both) and apparently our methods are functionally equivalent, returning identical results. Good explanations guys, and good to know I'm not the only one having this issue. Lol, sounds like at least once you resorted to creating a fake user folder on your 2nd PC. I suppose I have an OK workaround in my mission, to simply detect whether PBO vs non-PBO running, and accordingly exclude subfactions where I have applied custom textures. In this case I only have to exclude 1 out of perhaps 30-100 subfactions depending on how many mods are loaded. I expect this probably causes big headaches for people using even a handful of custom textures. Anyhow if we are indeed stuck with this pathing issue, imo all of the affected commands (including setFlagTexture) should at least get a local version, so we may work around it properly.

Thanks for the reply. If I simply save the mission in editor, exit back out to the main menu and host a server as you suggest (selecting my mission listed in green from the server browser), I get the same error & no flag on pole on the clients. In contrast, if inside editor (SP or MP) I select Scenario -> Export, a PBO of my mission gets created in "Arma 3\MPMissions" folder. If I then exit editor, go to MP browser, and select this PBOed version of my mission (same mission name but white text), everything works. No error, flag on the pole with correct texture for all clients. It all comes down to mission root. Here's my mission root function: BUB_MissionRoot = str missionConfigFile select [0, count str missionConfigFile - 15]; When HS is run from MP editor (which is the same as opening MP Browser and starting mission listed in green), mission root is the local directory to your mission: "C:\Users\%profile%\Documents\Arma 3\mpmissions\%mission_name.map%\" When HS is running PBO version of the mission (the one in white), mission root is: "mpmissions\__cur_mp.%map%\" So it turns out setFlagTexture works fine on HS when mission root is "mpmissions\__cur_mp.%map%" (as run from PBO). But this command blows up on the clients when mission root is "C:\Users\%profile%\Documents\Arma 3\mpmissions\%mission_name.map%\" (as run from editor) To me, the solution is not to "export to PBO every time", but rather to fix the buggy setFlagTexture command or otherwise find a real workaround. For now in my dynamic mission, I'm having to resort to detecting whether mission was run via PBO vs non-PBO, and if non-PBO then I exclude FOW's Imperial Japan as a faction selection, as I had to made custom flag texture for them (which doesn't work when run as non-PBO due to buggy setFlagTexture). Gotta love sqf in all it's glory. Anyhow, anyone know a way to set flag texture locally? That would totally do the trick.

Lots of useful info in here! Turns out I've got a similar query / conundrum: I would like a unit to say something from the Radio Protocol, in this case "Cannot execute, adjust coordinates.", and do so over the radio (again without usage of "description.ext" if possible). The Config entry looks like this: Tried this with playSound3D, and it works! Like so: playsound3d [ "A3\Dubbing_Radio_F\data\ENG\Male01ENG\RadioProtocolENG\Normal\100_Commands\CannotExecuteAdjustCoordinates.ogg", Loon]; He says this aloud in-game (no-lip syncing, fine in this case), which is great. But what I really need is how to make him say this over the radio. Anyone ideas?

Hey thanks for the help here. Managed to get my mortar/artillery system working great! Every client gets the dynamic whistle sound of real flying rounds! I ended up going with dummy rounds for each client (aka "whistlers"), and used per-frame handler to delete them prior to impact (as Grumpy Old Man suggested, thanks for the idea). Also added in a object/terrain intersection check, based on meters-per-frame velocity (just for the projectiles under 50m): Performance remains great as far as I can tell, and so far in many playthroughs no client's fake whistlers make impact, meaning it's working! I do wish mortar/artillery rounds would simply make the whistle sound for all clients out of the box. Or at least I wish we had a way to simply create duds via a quick script command, and not have to go through all these hoops. Oh well, maybe with upcoming Enfusion engine... @mrcurry Very nice! I ended up using playSound3D for the firing sound at the source, as well. Interestingly, when I went in to locate the sounds from the game files, I was surprised to see they each have multiple parts based on distance (for close, medium, far, etc). Learned that if you play them in isolation, they all sound a bit funny. Only when you play them all simultaneously together (with some tweaks for distance per sound), do you get the appropriate firing "sound". (I suppose it's that way for all weapons.) [Also, edited one of my earlier posts for clarification. See those edits in blue.]

The round I'm sending is "Sh_82mm_AMOS" (vanilla game mortar). Here's "soundFly" and falling bomb sound configs with default game loaded: configfile >> "CfgAmmo" >> "Sh_82mm_AMOS" >> soundFly[] = {"",0.0316228,4}; soundFakeFall[] = {"soundFakeFall0",0.25,"soundFakeFall1",0.25,"soundFakeFall2",0.25,"soundFakeFall3",0.25}; soundFakeFall0[] = {"a3\Sounds_F\weapons\falling_bomb\fall_01",3.16228,1,1000}; soundFakeFall1[] = {"a3\Sounds_F\weapons\falling_bomb\fall_02",3.16228,1,1000}; soundFakeFall2[] = {"a3\Sounds_F\weapons\falling_bomb\fall_03",3.16228,1,1000}; soundFakeFall3[] = {"a3\Sounds_F\weapons\falling_bomb\fall_04",3.16228,1,1000}; Here's "soundFly" with CUP loaded (falling bomb sound entries are the same): configfile >> "CfgAmmo" >> "Sh_82mm_AMOS" >> soundFly[] = {"CUP\Weapons\CUP_Weapons_Ammunition\data\sound\shorter.wss",2,1,500}; (Most of my experimentation was run with CUP loaded.) I did listen to the the four falling bomb sounds (soundFakeFall) individually in test mission using playSound3D, and they do sound pretty good. The game engine though, changes the pitch of some of these sounds (or is it changing pitch of soundFly sound?) as projectile travels (Doppler Effect I presume) which is awesome, and I think I have no hope of duplicating that dynamic change of pitch. Thus I was simply hoping to create "dud" rounds that sound perfect because they are, of course, the real thing. @.kju Any idea how soundFly fits in and what it means to have an empty string for soundFly?

Great ideas! I'm off to run some quick experiments, and will report back. In the mean time, a couple of my (previous) observations regarding your current suggestions: Both of you mentioned deleting these mortar shells... Are you guys able to successfully delete them? Using deleteVehicle for me has no effect on them, and they still make impact. As an alternative to deletion, I end up having to teleport them somewhere far far away. <- EDIT: Correction, deleteVehicle does delete this type of projectile if they are local. Apparently, I was trying to delete them non-locally. (The deleteVehicle command is suppose to be "Argument Global, Effect Global", but at least in the case of these mortar projectiles, calling deleteVehicle on a non-local projectile seems to have no effect.) I looked into playSound3D previously, and quickly realized I'd have a number of issues. First off (according to KK's comment on the ref), the sound will not move along with the shell as it travels. Secondly, seems like the engine's whistle sound changes pitch as it moves, and I don't see any way to dynamically change pitch over the course of the played sound with playSound3D. (You can set the pitch of the played sound once but that's it.) Third, as it is a global command, seems the new sound will clash with the engine created whistle for that one player (who's machine ran the createVehicle)? Curious mrcurry, if you experienced any of those? Also a handful of tidbits for anyone interested (from my experiments so far): When an actual vehicle fires a shell and you grab the projectile via addEventHandler "Fired", that projectile is accessible to that machine. But if you try to broadcast it to another machine (via remoteExec), the projectile is not accessible on that new machine. In contrast, when you use createVehicle to create the projectile shell and broadcast it to another machine (again via remoteExec), it's accessible on both machines. <- EDIT: In this case "accessible" on the non-local machine is pretty limited. You pretty much just have a reference to the non-local projectile, and few commands will do any real operation on it. (For instance, I could not delete them, etc.) createVehicle and createVehicleLocal both seem to do the exact same thing when creating shell ammo types as found in CfgAmmo. Either way, the object created is definitely present and accounted for on all machines (owned by the machine that created to it). <- EDIT: By "present and accounted for", I mean to say that the impact (at least) has a global effect! Using allowDamage false and hideObject true on projectile shells seems to do nothing to stop the impact. Attaching the "dud" shell to a carrier object (like a "Land_Wrench_F") via attachTo (then sending the carrier obj along the same trajectory) will keep it from exploding, but it totally mucks up the engine's whistle sound (removes the desired whistle and leaves the unpleasant metallic part, also messes up the pitch, etc), which again defeats the point.

Anyone notice IFA3 tanks have many turrets, but only the 3 standard AI crew by default (driver, gunner, commander), leaving all the extra turrets empty? Ever wonder why those extra turret gunners are missing? Ever tried filling those extra turrets with AI turret gunners, only to dismay when the extra AI turret gunners seemingly randomly disembark once the fighting starts? If so you’re not alone, and thankfully it turns out there is an easy solution to your multi-turreted troubles. First, some background. This "IFA3 extra turret gunners disembarking" problem has long vexed me, and I tried seemingly everything (all manner of script commands, including disabling "AUTOCOMBAT") to keep those extra turret gunners in their seats, and nothing worked. Eventually, I pinned the problem down to same-side units (even foot soldiers) near the vehicle being hit. Same-side guy gets shot (not necessarily killed), and immediately the vehicle’s extra turret gunners disembark. Perhaps most amazingly, this even happens when all the extra turret gunner’s AI components are disabled! Here’s the original test: Fast forward to present, today I figured out how to keep IFA3 extra turret gunners in their seats, simply and cleanly: _vehic setUnloadInCombat [false, false]; Of course that really threw me for a loop, having utterly dismissed setUnloadInCombat more than once (thinking "naw that can't possibly work, as I've tried disabling "AUTOCOMBAT" many times and know 100% that has no effect", etc). So I don't see how or why it works, but thankfully it does (and I'm not one to look a gift horse in the mouth). So load up those extra tank turrets boys, setUnloadInCombat false works perfectly! @.kju Can you use setUnloadInCombat to overcome all the issues you guys were having with the extra turrets? If so, can we eventually get fully crewed tanks in the editor? Either way, thanks again!

I tried this mortar load action again and it works now. If it got fixed, thanks! Quick observations: The 1-round mortar mags are configured for player to be able to pick them up and load them, but the 8-round mags are not. Similarly, the mortar vehicles are scripted for player to be able to load 1-round mortar mags, but not 8-round mortar mags. Specifically: With 1-round mortar magazines, player can see these in inventory of a crate, pick them up, see the picked up mags in his personal inventory, go to the mortar vehicle, load the mortars, and in this case indeed everything seems to be working as intended. However, with 8-round mortar magazines, when player opens a crate with these inside, a config error pops up saying in essence no picture, and player can see these 8-round mortar mags but indeed they have no picture and also the count is missing from inventory display (though I checked and the correct count of these mags is present in crate). Player can pick them up (and again picture/count doesn't show in personal inventory), go to mortar vehicle, and try and load these 8-round mags, via “Prep 60mm HE rounds” and "Load", but it doesn't work. Anyway probably all this is intentional, as "8-round" mortar mags probably don't exist in real life (or at least not in WW2), and if they did foot soldiers probably couldn't carry them. (Finally, wrote a "Load all Mortars" action script to overcome this 1-round vs 8-round discrepancy in my scenarios.)

OK, I figured it out. There is a further multiplier, "artilleryCharge", which is based on the weapon's mode. configfile >> "CfgWeapons" >> "mortar_82mm" >> "Single1" >> "artilleryCharge" = 0.35 configfile >> "CfgWeapons" >> "mortar_82mm" >> "Single2" >> "artilleryCharge" = 0.7 configfile >> "CfgWeapons" >> "mortar_82mm" >> "Single3" >> "artilleryCharge" = 1 So, here's a breakdown of this weapon's modes / expected initial velocities: Single1: 200mps * 0.35 = 70mps Single2: 200mps * 0.7 = 140mps Single3: 200mps * 1 = 200mps Good, it all makes sense now! Hmmm... Hope that helped someone.

From my perspective, two simple and well-defined issues account for easily 90% of the problem. The worst offender right now is vehicles given a WP directly behind pretty much always get stuck. That one should be easy to fix, and would have an enormous impact. Fix that and the convoy thing and you'll have a lot of happy customers.

Such an awesome map! Great for CTIs too. I love how (pretty much everywhere I checked) you left space along the roads and even the paths so the AI can get around freely. My dynamic mission won't work on Tanoa because the vehicles get stuck everywhere, but it sure works great on Pulau! Considering you're still adding clutter/etc, please keep those roads/paths clears for our humble vehicle-bound AIs. Also, it seems to me by and large (based on initial Pulau version and in stark contrast to Tanoa), the central island is very AI accessible (very few dead spots where AI footmen can't get), and the smaller islands to the sides is where you went wild with imagination and terrain height experimentation (very likely) at the expense of the AI getting around on those smaller islands. This is the perfect approach, as CTIs will simply exclude the small islands and restrict AI to the main island. I hope you can continue to make/keep the main island AI friendly by making sure AI foot soldiers can get everywhere (and again for AI vehics keeping those roads/paths clear). EDIT: Wow, there are now two main islands! New island is roughly same size as the original. Time to go exploring!

I’m happy BIS introduced the ability to disable AI component “AUTOCOMBAT” a while back (via disableAI command). It’s quite useful in getting the AI moving and avoiding getting bogged down in COMBAT, but apparently only in very specific circumstances for AI-only groups. Like getting the AI to run somewhere fast (as in flee) and while not stopping to shoot back at any enemies. Old Painless has an excellent formula for exactly this case that he detailed over on the Dev Branch AI thread. It really works great in my tests! My dream is a little different, but seems like it should be doable: You know how as a player (leading our AI group), we can move around and our AI will keep up formation and shoot at the enemy, scooting along and shooting as they go? That is, until they sense a certain level of danger and all go into COMBAT? Even before we had ability to disable “AUTOCOMBAT”, this has always been possible for player-led groups. For lack of better terminology, I’ll call it AWARE scooting with shooting. Seems like this same thing ought to be possible with an AI as group leader (especially now that we can disable “AUTOCOMBAT”). Here’s what happens when I try it. First, I disable “AUTOCOMBAT”, like this: { _x disableAI “AUTOCOMBAT”; } foreach (units _group); Good to go so far, give that AI-only group a WP and they happily move toward it. When they discover an enemy, they (sometimes some, sometimes all) stop, turn and fire, as expected. And here’s where the trouble starts. When the enemy is neutralized (or teleported away), the stopped AI don’t start moving again. Often, they don’t start moving again ever. It doesn’t matter what code I run on them to try and get them moving again. I tried all this: { _x doWatch objNull; _x forceSpeed -1; _x stop false; _x disableAI "TARGET"; _x disableAI "AUTOTARGET"; _x disableAI "COVER"; _x disableAI "SUPPRESSION"; _x enableAttack false; _x doFollow (leader _group); } foreach (units _group); (in various combinations / orders) They start moving again for a moment and then stop again. (which makes me think maybe the AI group leader is ordering them to stop again repeatedly). I tried disabling various AI components of all subordinates before they ever find an enemy to begin with. I tried disabling various components of specifically the group leader’s AI, including “ALL”. I tried using a game logic as the leader of the group. [I did notice that the stuck guys do "Return to Formation", if the group leader comes close to them at some point in the future. (Obviously, this isn't a practical solution though for real-world missions.)] Eventually, I used marks to track the expectedDestination (composed of [position, planningMode, forceReplan]) on each of the units, and noticed that all the units (including the stuck guys) are where their expectedDestination wants them to be at (which makes me think maybe the group leader is ordering them to those locations). I also noticed the stuck guys are in their own formation, distinct from the moving guys formation (even though they are all in the same group). [I’m using an automatic marker system to view and track all this.] I experimented with using FSMs to modify their expectedDestination, and those stuck AIs stayed stuck. For the life of me though, I can’t get those stuck guys moving again! The one thing that works is to disable their native FSMs via: _x disableAI “FSM”; But then they only move, and don’t turn or stop to shoot at enemy. (Which turns out to be similar to Old-Painless’s cocktail from the AI dev thread mentioned above, useful but not what we’re looking for here.) I don’t want to write a full-blown FSM to do targeting, cover, etc (although it would really just be targeting and moving, as cover seems to apply only to Combat mode). I want to piggy-back off the native solider combat and formation FSMs, and let those do the stopping / shooting, but unfortunately those FSMs don’t seem to account for an AI-only group with “AUTOCOMBAT” disabled. Steps To Repeat: Create an AI-only group in the editor Disable “AUTOCOMBAT” on all units in the group (via disableAI) Give group a waypoint semi-far away Give group a temporary threat, ideally small threat that AI-only group will shoot at but which won’t shoot back (I was using myself as the different-side player with allowDamage false, teleporting in, getting them shooting at me, then teleporting out). Fire up mission. Observe, AI-only group moving towards WP normally Have AI-only group run into temp threat, observe AI-only group stop and shoot at enemy. Observe AI-only group remains in AWARE mode and does not enter COMBAT mode, as expected. Have threat be eliminated (or disappear or get teleported away, etc). Observe stuck AI-only group units (whoever stopped to fire when threat was present) Experiment with dozens or even hundreds of commands (in various combinations) to try and get stuck AI to “Return to Formation” and resume movement quickly This type of Ai-only Aware-only scoot-and-shoot would allow AI to cover ground more quickly (much like the player can) and would be awesome for all sorts of missions! I feel like we were let down a bit, regarding the (implied) promise of disabling “AUTOCOMBAT”, as it doesn’t seem to work out-of-the-box with AI-only groups. (Best outcome - I'm not sure whether this is really a bug per say, but maybe BIS can provide a quick fix?) I know it’s a long shot, but has anyone got anything like this Ai-only Aware-only scoot-and-shoot working? Any ideas? (P.S. I’d be very happy for now with a way to simply get the stuck guys to “Return to Formation”. Thanks!)

[Anyone who may have read me saying the stopping problem had come back, please strike that, reverse it. Apparently I had forgot the enableAttack false part (in my test), which of course is the key.] Everything in-game is working as advertised (apparently since 1.68). This is all it takes to get your AI-led AI-only group moving in proper scoot-and-shoot fashion: { _x disableAI "AUTOCOMBAT"; _x enableAttack false; } foreach (units _group); By default enableAttack for groups is true, which causes the AI group leader (upon contact with enemy) to order his men to move out in subgroups. Once these subgroups get where they are going, they wait for a (often very) long time before they abandon their subgroup and follow the group leader again. This can give the impression that they are perhaps permanently stuck, given that you'd disabled AUTOCOMBAT on all members in your AI-only group, with the intent to have them move quickly. You can monitor subgroups via formLeader on each of the group's units. So when you use enableAttack true, upon contact there will be multiple subgroups. When you use enableAttack false, there will only ever be one subgroup.

@.kju I'm glad you did! So I just doubled-checked by rerunning my original test (see above). Quick history for anyone catching up: EDIT: Yesterday, I errantly posted that this stopping problem was back. Please see my next post for updated/correct information. Your mileage may vary, but I know I personally wouldn't have any chance making sense of most AI related matters (especially issues like this one) without a good map-based unit/group monitoring system, that importantly draws all it's icons on the main map (for ease of use). I developed such a system for general purpose, which I codename Marker Command. In addition to monitoring all units/groups, you can select any group on the map (again, the main map) and add/remove/move/delete their WPs. Then you can enable/disable group visibility & control individually per group. And you can display groups as group icons or as unit icons with lines connected to leader (like in the editor), individually per group. This system is central to my dynamic mission and close to release-worthy, but lol not quite there yet. You may use it if you like (just send me a quick PM). Anyhow, I'm sure someone has something similar and quite possibly better already released. If I understand what you're asking... Let's see, for the most part I keep AI grouped. If I'm going to try sending them into buildings, I definitely put each guy in his own group. In my dynamic mission, I keep each vehicle's crew in separate groups, so they have a chance of getting where they are going, given Abysmal state of AI-driving since 2016 change. Also, when I want the AI guys in my own group to get somewhere fast, I give them move orders individually. I hope some of that made sense / maybe helped.