madrussian

Not in my experience. Yeah, you'll need that "killed" EH on each new selectPlayered guy. Btw - If I read between the lines, what it sounds like you are trying to do is super complicated (having spent many moons on something similar myself). Have you tried simply using the game's built-in group respawn mechanics? ^ Of course, that will only work in MP (multi-player). And only works for your own group. If you want group respawn in SP (single player), check out my mission... in my signature. My Group Linked Respawn (GLR) system is pretty easy to break out and insert into your own mission. You can span group respawn across multiple friendly groups, add new units on-the-fly, give yourself limited lives that show up as little soldier icons that fade out every time you get killed, and more. Lots of options.

That sounds quite awesome! I may give this a shot, and if so might have a question or two while navigating through it. Btw - Thanks for all your hard work on these missions & scripts. You really put out some high quality stuff. 🙂 (Btw - Seems to me a simplified AI-only helicopter transport script would come in super-handy for a lot of mission creators. If anyone was so inclined.)

Just from a quick look, I think I see what the problem is. You are adding "killed" event handler to the original player unit. <- Good Then upon death, you call selectPlayer to new unit, and player is now controlling that new unit. <- Good But you never add "killed" event handler to the new unit. <- Bad So when that new player unit dies, there is no "killed" event handler (on that new unit) to take effect.

Roger all that. Sounds like to get AI-only transport working (for personal use, etc), likely all the parts are within Hermes code, I'd just need to... (re)assemble them. Plus you guys have no doubt overcome many obstacles making this all this work. I recall encountering many gotchas trying get helis transporting AIs & player in A2, so again I greatly appreciate your efforts here! OK, before I dive in and try to re-cobble Hermes to perform player-less AI-only transport... curious @Rydygier do you or anyone know of a good A3 AI-only helicopter transport script, that requires no player interaction?

Just finally checking this out. Looks awesome & like it was an absolutely huge undertaking. 🙂 I quick read through the features list & watched a couple of the intro videos. Can't quite tell though, is this well suited to transporting AI-only squads? Also if so, would assume fast-rope is optional?

Trying my hand at reverse engineering how setSkill impacts skillFinal, with respect to CfgAISkill and the Difficulty settings (AI Level section's "Skill" and "Precision" values). I've run a bunch of experiments and gathered the following: Mission creator calls setSkill on a unit ArmA3 engine put's the result on a curve, with the crux-point at setSkill 0.2 (linear to and from this crux-point) CfgAISkill does it's thing (applies it's multiplier) Difficulty Menu's "SKILL" and "PRECISION" does it's thing (applies it's multiplier) I'm trying to determine the order in which these things happen. Run into small hiccup: How does one get the Difficulty Menu's "SKILL" and "PRECISION" values via script? Hopefully it's a simple thing? Better yet, anyone have the actual formula or otherwise know the order in which these factors are applied? (Hoping to arrive at the exact skillFinal formula, will post it here as a reference for all.) I welcome any and all help, even simple things I may have missed. Thanks!

Hi Elgin675, just noticed your latest post. Not sure I completely follow, but please note the formulas do work both ways. Specifically: If you know your desired Final Skill value, and wish to know the setSkill value which you'll need to use (by calling setSkill) to obtain that Final Skill value, you'll want to use MRU_FSC_GetSetSkill. Conversely if you are starting with a setSkill value, and wish to know the Final Skill value which will result (by calling setSkill), you'll want to use MRU_FSC_GetFinalSkill. Hope that clarifies it? 🙂

I need to detect and stop the impact of a mortar. Create a “dud” if you will. Any ideas? Some background: I originally wrote a simple mortar script which randomly creates a bunch of explosions directly on the ground. I’m replacing that script with an improved script using real mortars that travel through the air from origin to target. I create them via createVehicle, position at the virtual artillery source via setPosASL, use kinematic equations to determine a firing solution (aka trajectory), and sent on their way via setVelocity. Finished the script and everything works great, mortars fly to exactly where I want them. Here’s where the trouble starts. The whole reason I wanted real flying mortars is for that whistle sound, so the players have some warning that a round is incoming. Fortunately, the whistle sound works great for the player whose machine created the mortar. Unfortunately, the whistle sound is entirely missing for every other player, defeating the entire point of the new script. So my idea now is to send a mortar round on every machine, hoping that all players will hear the whistle. Fortunately, this works! All players hear the whistle! Now I just need to send one real mortar round (for the player that called in the mortar), and a bunch of “duds” for the other players. I need help with the “duds”. So here’s the question: Anyone know how to stop the impact of a mortar (preferably via simple command or EH)? (P.S - I’d like to keep this clean and avoid looping scripts, but happy to hear any & all ideas.)

Playing around with assignedTarget command, using some visual indicators and rays to see what's going on under the hood. I had always assumed that assignedTarget was how to tell who a given unit is targeting (and always used it this way), but appears this is actually only partly true and the implications are perplexing. Here the setup: It's just me the player facing off against a bunch of enemy, with player damage turned off so I can observe properly (aka without getting killed). So basically I have red rays being shown from all AI units to their assignedTargets. And when they don't have an assignedTarget, their red ray disappears. All enemies are aiming/shooting at me (again I'm the only one to shoot at), but only some of the enemy (perhaps 60%) have the red rays. So perhaps 40% of enemy dudes are aiming/shooting at me without me being their assignedTargets. The question is: For these remaining 40%, how do I get their target? (Btw - One conclusion I've reached based on this test is that assignedTarget is really about the leader assigning targets. Anyhow, how on earth do we simply get the actual target?)

Thanks, I just checked and "Land_Hut01" (... to 06) use different models than our "house.p3d" hut. Which is fine, but the "house.p3d" huts in Melana Resort are special, because they offer 360 degree defense (via the windows & door on all sides). My AI system uses buildings, and every building needs a type in order to be used. And I was trying to make sure all 360 degree defense buildings can be used. I suppose I could re-write a good bit of my code so it can handle "terrain object" (aka type-less) buildings too. But probably not worth it for a silly wooden hut. On the other hand, if I start finding a whole bunch of these "terrain object" buildings then will have to rethink it. And btw - There are a ton of panelaks on Dingor, so this "terrain object building" phenomenon might be more prevalent than we might otherwise suspect. In the mean time, will do a quick query sooner or later and see if any cfgVehicles buildings use that "house.p3d" hut model (again for it's nice 360 degree defense), and if possible auto-replace like with those panelaks. Thanks for info & ideas guys!

Wow thanks, that's quite a detailed response! Looks like it will probably work. Btw- Not necessarily going for speed for this building replacement routine. It's more for the demo mission, just to get the right buildings in place (and only happening in a smaller area). But yes, definitely nice to know which is quicker. 🙂

Thanks, yes that's pretty much exactly what I'm doing for those panelaks (small, medium and large). With those, I happened to get lucky because even though panelak.p3d objs have no type name, I knew of the equivalent building(s) type to replace them with. (I was using str command instead of getModelInfo in my method though. Thanks to you guys, I know how to use getModelInfo effectively now too.) It's those wooden huts I'm having trouble with. If we assume for a moment that they have no type (which I'll confirm soon), the problem is I know of no equivalent cfgVehicles type to replace them with. (If your curious about which huts I'm talking about, they are on Dingor Island at the Melana Resort, which is along the NE corner of the big airport to the south, which itself is just east of Calamar.)

Wow, that is mighty useful indeed! (If anyone hasn't seen his video, please do click on that link.) Sounds like your tool is just the thing, to be able to tell immediately whether these huts have a type or not. Super handy advise, thanks! Ok so, if I ever want to determine via script whether a terrain obj has a type or not, sounds like I'd want to: Use getModelInfo on the terrain obj to get the model string, and then perhaps query cfgVehicles for types using that model (via some property, probably model or similar)? And if query comes up empty, that should tell me that no cfgVehicles types use that model? ^ Does this sound reasonable, or is there a simpler way to do this (again via script)?

Looking for ways to remedy bad staircases in a few particular (older) building types. Using forced movement (via _unit disableAI "PATH"; _unit disableAI "ANIM"; _unit playAction "WalkF";), and the unit sometimes passes through the stairs and ends up trapped in the area below the stairs. (Poor soul.) I have a looping floor detection remedy in place for cases in old buildings where the unit falls half-way through the floor, in which case it pop... pops him back out. The floor detection remedy runs at a low frequency, so isn't really designed to catch cases where the unit falls (or otherwise passes) completely through the floor (like with these stairs). I'd like to try to place an invisible object with a walkable surface under the stairs to see if that catches the AIs that would otherwise fall though. The questions are: Anyone know of an object type in the game, which is invisible and has a walkable surface? Anyone know way to make an (otherwise visible) object invisible but still walkable?

Back at-cha. 😉 OK, I just tried this for both selections on my VR box (with and without that setObjectMaterialGlobal from my snippet above), and unfortunately both main part & trim stayed original colors (grey and white). Good trick to know though, will try that first next time I need to hide something. Also, makes me wonder what the difference is in objs that will hide with "" vs ones that won't. Also, I agree since putting this obj under the stairs, don't necessarily need to hide it. Only, I think one end may have to come up above stairs level slightly to work... not sure on that bit yet. Will try those pallets too! That sounds intriguing, will have a look. (Happen to know the obj type?) Good idea, will try it thanks!

Quick update, I think I can use setObjectTextureGlobal to hide my object, doing something like this: _texture = "#(rgb,8,8,3)color(0,0,0,0)"; _obj setObjectTextureGlobal [0, _texture]; Only I just tried it and that texture is apparently black. Anyone know where this texture format is defined? Edit: OK I found these "procedural textures" defined here. Edit 2: So my object (for starters) is "Land_VR_Block_05_F", a giant VR block. By default it's light grey with white trim. I confirm it has two textures via getObjectTextures. Now I can turn the object completely black via: _obj setObjectMaterialGlobal [0, "\a3\data_f\default.rvmat"]; _obj setObjectMaterialGlobal [1, "\a3\data_f\default.rvmat"]; _clearTexture = "#(rgb,8,8,3)color(0,0,0,0)"; _obj setObjectTextureGlobal [0, _clearTexture]; _obj setObjectTextureGlobal [1, _clearTexture]; Of course though, I need it to be transparent! Reading up on "procedural texture", I find the (0,0,0,0) part is (Red, Green, Blue, Alpha). My Alpha is 0, so seems the object should be invisible. But unfortunately it's still visible (again completely colored black). Any ideas?

Stumped at the moment by A3 issue. This one's pretty simple to recreate and witness. Running doFollow on a group of men in a vehicle (in this case my own squad), causes all the mounted cargo guys to disembark the vehicle. [Note that the Fire From Vehicle (FFV) guys stay mounted.] I absolutely need to use doFollow as part of a Regroup script for my Group Linked Respawn system. But I can't have men errantly disembarking like this! I have tried numerous things to keep them in their seats: allowGetIn true, orderGetIn true, getting their cargo index via getCargoIndex and reassigning it back to them via assignAsCargoIndex, then directly moving them back to own seat via moveInCargo [_vehic, _cargoIdx]. I even tried disableAI "ALL" on all my mounted subordinates before calling the doFollow. But still, the cargo guys keep bailing out. Anyone else run into this? Any ideas on how use doFollow without it ejecting your (cargo) subordinates from their vehicles? I welcome any and all help, inc simple things I may have missed. Thanks!

For the record, I never really overcame this issue. Also iirc, I did try all the vehicle locking commands too (but memory's a bit fuzzy on that now, so you may want to try it). The workaround I settled on for my Regroup script was to simply never doFollow mounted cargo guys (except FFV guys)... ever! (I mentioned a workaround where I was "teleporting the cargo guys out and back in directly after the doFollow", but that looked pretty ridiculous visually plus came with other unwanted side-effects.) I like kju's idea of simplified commands to accomplish these ends... especially dissolveSubGroup(s). (Or of course a fix for doFollow.)

Thanks, that's exactly what the doc ordered. Quick summary from the report (for those interested): Looks like two others had my exact issue with getAttackTarget for AI led groups, and like it currently works correctly for player squad AI. Very nice, there is hope still. 🙂

Greetings all. I'm creating some AI scripts, which need to disable certain AI features, like the following: _group enableAttack false; _unit disableAI "AUTOCOMBAT"; _unit disableAI "COVER"; _unit allowFleeing 0; So far so good. My AI can do it's many amazing thing(s)! However later, I want users to be able to turn off my AI and completely revert the group / unit(s) back to original states. So I am storing the original states like this: _group setVariable ["MRU_DAI_RestoreEnableAttack", attackEnabled _group]; _unit setVariable ["MRU_DAI_RestoreAutocombat", _unit checkAIFeature "AUTOCOMBAT"]; _unit setVariable ["MRU_DAI_RestoreCover", _unit checkAIFeature "COVER"]; _unit setVariable ["MRU_DAI_RestoreFleeing", 0.5]; ^ The problem is, the 0.5 for allowfleeing is a total guess on my part. So the question is: Anyone know what the game's default value for fleeing actually is (set-able via allowFleeing) or how to obtain it? I've been wondering about since... oh about the days of OFP. Description for allowFleeing specifies: But not what the dang default value is! (Hmmm... If no one knows maybe a kind dev could check it out real quick and report back? Then we could update the wiki for all to know.) 😄

^ Btw - I'm not disputing any of this (and thanks for weighing in!), just letting you all know my observations. Seems there is perhaps a bit more to the underlying fleeing formula(s), considering my test results. Also, I should have mentioned I ran those tests with one single mod loaded (CBA), which made it easier to observe everything unfold.

Quick follow-up, finally checked out the getAttackTarget command (running Development Build 1.99.146550). Result is quite disappointing. In short, getAttackTarget appears to be operating like an simple alias for assignedTarget. Specifically, same test as before: ^ Only now I also added green rays from unit to their getAttackTarget (slightly offset upward from the red rays so the two rays don't overlap). In my experience, the only time I see the green rays (for getAttackTarget) is when red rays (for assignedTarget) are already showing. In this case, both red rays and green rays appear at the same time (and always to the same target). [Also, I checked my code several times to ensure red ray points to assignedTarget and green ray points to getAttackTarget.] Next, I also independently monitored these units and verified that getAttackTarget returns objNull until assignedTarget actually returns a target, and then at that moment getAttackTarget also returns that same target. Even in cases where the unit was focused and shooting on me for some time well prior to me becoming his assignedTarget. I reread the getAttackTarget command description, which says: And the example given is: In summary, (at least at present) appears getAttackTarget command does NOT work as advertised (in the example anyhow). ^ Curious if someone else can confirm what I'm seeing in-game? (Important - Perhaps the description of getAttackTarget is actually correct, and this command will indeed return the target he is engaging, but he will aim and fire at other targets along along the way during his engagement of his main target.) Meanwhile, back to the original question: How to find out via script command who a AI unit is targeting, when he is obviously aiming at (& shooting at) an enemy unit, but he has no assignedTarget? Surely there is a way? Otherwise, if everyone is simply using assignedTarget, seems to me that can't be very efficient or proper for current AI mods. We need to know who these AIs are aiming at!

OK, I did some independent investigation. Two very different tests, with somewhat different results. Goals: Test kju's hypothosis (see post immediately prior to this one) Attempt to determine the default value for allowFleeing Btw - We've managed to reverse engineer the mystical skillFinal formula, so why not this too? Test #1 - Fleeing resulting from systematic unit deletion only (This test was actually performed 2nd and yielded more specific results.) First, two input values are set: _setCourage (sets every unit's "courage" skill to this value, when nil does nothing) _setAllowFleeing (sets every unit's allowFleeing to this value, when nil does nothing) On the VR Map, automated test repeatedly does the following: 1. Creates 16 west groups, each with 10 units, equally spaced around the map in a grid pattern (4 rows of 4 groups per row), each group so far away from each other that they should have absolutely no impact on each other. (160 units are created each round.) 2. Applies the _setCourage value to every unit via: if (! (isNil "_setCourage")) then { _unit setSkill ["courage", _setCourage]; }; 3. Applies the _setAllowFleeing value to every unit via: if (! (isNil "_setAllowFleeing")) then { _unit allowFleeing _setAllowFleeing; }; 4. Once all groups are created, the groups each have 1 man deleted, then for 0.2 seconds fleeing units are counted, then 1 more man deleted, then for 0.2 seconds fleeing units are counted, and this process repeats until only 1 man per group remains. 5. The total number of fleeing units is counted and reported. (Note that upon a unit being counted as fleeing, he is flagged and not counted again.) Result is between 0-160 fleeing units. 6. All units and groups are deleted, followed by meticulous (automated) checking to ensure all the test units & groups actually got deleted. (i.e original clean state is achieved). Observations & Results: 1. When courage is set, the units' courage has no bearing on the number of units recorded fleeing. This is true when allowFleeing is also set, and also true when allowFleeing remains completely untouched. Specifically: 2. When allowFleeing is set, it has a direct impact on the test. Specifically: ^ Note that for these particular _setAllowFleeing tests, these results are consistent no matter what courage is set to. ^ Note that for _setAllowFleeing 0 through 0.4, I indicate that "0 or X" men were counted as fleeing. Turns out tweaking one small detail of this test produces one result or the other. For _setAllowFleeing 0 through 0.4, when a specific (non-leader) is selected for deletion (see step #4 above in the test steps) like last in the group's units array or first non-leader unit in the group's units array, this (apparently) always results in 0 units fleeing. However, when a random group unit is selected for deletion, this (apparently) always results in the higher number of listed units fleeing. I know, this looks (& sounds) like some straight up quantum-entanglement-double-slit-observer-quirkiness or the like. Importantly though, I assure you these results are very consistent. Also note that for _setAllowFleeing 0.5 through 1, the results (apparently) always exactly match what you see above (thus I didn't mention "or" for these). 3. Based on this test alone, we can conclude that the default value for allowFleeing is 0.6! (because running the test with allowFleeing left untouched results in exactly 80 men fleeing, and also running the test with allowFleeing 0.6 also results in exactly 80 men fleeing ... along with all of this being completely independent of "courage" skill) ... Not so fast though! We have another test. Test #2 - Fleeing resulting from Actual Battle (This test was actually performed first, and the results are unfortunately a bit muddier.) On the Stratis Map, automated test repeatedly does the following: 1. Creates 8 west groups and 8 east group (8 units per group, using "Rifle Squad" composition). So 64 vs 64 men, for a total of 128. 2. Applies the _setCourage value to every unit via: if (! (isNil "_setCourage")) then { _unit setSkill ["courage", _setCourage]; }; 3. Applies the _setAllowFleeing value to every unit via: if (! (isNil "_setAllowFleeing")) then { _unit allowFleeing _setAllowFleeing; }; 4. Gives all groups a move orders towards opposing enemy group. (Note at this point every time I increased game speed to 4x manually via the provided key.) 5. The total number of fleeing units is automatically counted. (Note that upon a unit being counted as fleeing, he is flagged and not counted again.) Result is between 0-128 fleeing units. 6. The groups are allowed to battle until 1/4 of the total number (32 men) are killed leaving 96 alive, and at this point the results are automatically recorded. (A 180 sec timeout is provided for cases in which they won't fight, which in these cases all or too many units are fleeing.) 7. All units and groups are deleted, followed by (automated) checking to ensure all the test units & groups actually got deleted. (i.e original clean state is achieved) I ran this test over 1000 times, trying to establish the correlation between courage and allowFleeing (if any) and to hone in on the elusive default allowFleeing value! Here are the inputs & results: Observations & Results: 1. Very early in these test runs, I could tell that (in actual battle) both courage and allowFleeing impact a unit's propensity to flee, and that allowFleeing has a far greater impact. 2. I made a spreadsheet with multiple tabs to establish average fleeing values at various levels. It's pretty messy, and I'll spare you the gory details (unless someone really wants to see it). Instead if you simply scroll down through the results spoiler above, you'll see me honing in towards the default allowFleeing value. 3. Early in the testing I was doing 11 battle instances per game run (checking out courage over 0-1 values in 0.1 increments while keeping allowFleeing consistent -or- conversely checking out allowFleeing over 0-1 values in 0.1 increments while keeping courage consistent). However this test is apparently somewhat imperfect, as I could tell equivalent units (assigned the same courage and allowFleeing combos) were fleeing somewhat less over a single game run instance, as the number of battles increased. Once I noticed this, I started testing 50 battles per game run with consistent courage and allowFleeing combos. You'll see this starting with test run #300. 4. Based on this (battle) test alone, (at least when courage is 0.5) the default value of allowFleeing is ~0.525! So we have competing default allowFleeing results of 0.6 and 0.525... I really wish BIS could give us an allowFleeing alternate syntax that resets unit's allowFleeing to untouched, default state. Pretty please? 😄 If anyone has any related insight or otherwise, please let's hear it. Thanks!

Good info, yes I gathered that many factors affected when units break and flee, and assumed allowFleeing value was just one of the inputs. (Probably specifically having a big impact.) If this is true, then when I set to 0.5, should be exactly the same as setting to 1. (If I understand you correctly?) In fact, in my dynamic mission, I do set allowFleeing to different values (like 0.3, 0.2, and 0.1) based on the enemy order and thought I could tell a difference. But it wasn't a scientific test or anything. Anyhow, should be fairly easy to definitively prove or disprove.

I did see getAttackTarget when looking through all the target related commands, but something I read about that specific command on different command ref made me think it was for example, when an AT unit is going after a tank, the tank would be his "attack target", but he would target other units on the way to attacking tank. If getAttackTarget really returns what I'm describing in OP (getting the simple target), then I find it bizarre that anyone/everyone has managed to get by this long (since the beginning of the series) without it! Regardless, many thanks I will check it out and report back. 🙂