_foley

str has this neat property that it outputs a valid, compile-able code (within reason of course, in case of an object it will attempt to find a relevant variable name). When you str an array that contains strings, it's very much desired to have quotation marks around them. That way you can use it later in compile or even better in parseSimpleArray. It's also desired when you use it for debugging - being able to distinguish between 20 and "20" in a debug message/hint could be a life saver. In other words, the goal of str is to serialize an arbitrary value (including functions!) into a string that contains a SQF code. Still, I totally understand your frustration - wiki doesn't make it abundantly clear. If you're looking to convert a value into a human-readable string, you can use format. It will keep your strings as is and it will happily accept any variable type just like str. Format is less convenient to write so we often just use str when we want to convert a single value. Nothing wrong with that but it's good to understand that this is a shortcut and it may cause nightmarish bugs like the one you experienced here. @Waldemar 337 I'm curious to see what was the purpose of using str in your case.

The ability to provide distances (known as weights in standard notation) is pretty useful. Imagine that you have a short path through unfavourable terrain vs a slightly longer path but through much better terrain. If you're able to provide explicit weights between the nodes then you can make it so that vehicles would prefer a longer path on a highway instead of cutting through a dense forest. For infantry this would be reversed - they would be happy to take a longer path along a treeline as opposed to the shortest path through the open field.

Hej It looks like it's going to be a large project relatively to usual questions here but you seem to have a good idea of what you want to achieve which is a great start! This is a solid approach, perhaps you can start working towards it and let us know when you encounter specific problems. Anyway, here's a few pointers: - https://community.bistudio.com/wiki/BIS_fnc_holdActionAdd - this is how you can implement an action that takes time - https://community.bistudio.com/wiki/Category:Command_Group:_Unit_Inventory - here's a collection of commands to create, read, delete, update unit inventory - https://community.bistudio.com/wiki/setVariable - this is how you can assign a variable to a specific unit (player) - To keep track of how many points is each item worth, you need to obtain the classnames of the items (i.e. use ctrl+c in Arsenal or https://community.bistudio.com/wiki/Arma_3:_Assets for vanilla items) and then you can construct a hashmap like so: lootValues = createHashMap; lootValues set ["FirstAidKit", 3]; // set first aid kit to be worth 3 points lootValues set ["Medikit", 10]; // set medikit to be worth 10 points lootValues get "FirstAidKit"; // returns 3

Alright, I assumed you shared it for others to use in their missions. I don't mind the spoiler, I meant that you can nest code block inside a spoiler.

Hey Blackheart, here's some quality of life things you could improve 1. Use the code tag for syntax highlighting so that your script can be easily read on the forum. 2. Instead of "//Go to line 139 to edit ...", you can utilize params or #define. Params is a simple way to make your script much easier to use. It's a one-liner and it allows you to specify default values too. 3. Not sure why convoy is a global variable because it makes the script unsafe to run twice at the same time. Having two convoys active at the same time is a totally plausible use case but if it's not allowed then the script should exit early if the convoy already exists.

Replace "allUnits" with "vehicles" and it will 😉

@chow86 There's a mistake in that code, basically it will work for the first hit on a healthy unit and then, like you noticed, it will act strange, sometimes even healing the unit after a hit. I've posted a solution to your problem in the main HandleDamage topic:

Here's a way to reduce damage proportionally to what it normally should be, for example to reduce all inflicted damage by 30% Note that this is very different to returning just _damage * 0.7 which leads to undesired behaviour. What you actually want to return is the previous damage + reduced new damage. this addEventHandler [ "HandleDamage", { params ["_unit", "_selection", "_damage", "_source", "_projectile", "_hitIndex", "_instigator", "_hitPoint"]; private _previousDamage = [_unit getHit _selection, damage _unit] select (_selection isEqualTo ""); // if selection is empty then it's overall damage private _newDamage = _damage - _previousDamage; (_previousDamage + _newDamage * 0.7) } ]; Another caveat: a one shot kill often deals much more than 1.0 damage, meaning that a headshot which deals 5.0 damage is still deadly after a reduction by 30%. You can mitigate it by limiting the maximum damage that can be dealt in one hit. The example below will: reduce all damage by 30% and prevent taking more than 80% damage from a single hit. (_previousDamage + ((_newDamage * 0.7) min 0.8)) If you're using ACE, be aware that this will not work correctly on men because of the modded medical system though it'll still work fine for vehicles.

Is this what you're looking for? https://community.bistudio.com/wiki/Mission_Parameters

Doing things in editor is more visual and intuitive so it's appealing at the start and you can actually go pretty far using just editor with minimal use of .sqf files. As you noticed though, there is a point where you have to many overlapping things in the editor that's it gets overwhelming. At that point you might start moving scripts from editor into .sqf files and running them from editor using execVM. Generally, as your scenario gets more complicated, you will see more value in keeping scripts in .sqf files where you have explicit control in which order and on what machine your scripts are running. It's also much easier to reuse the same piece of code in multiple places. There are other convenient advantages like the ability to search and replace phrases or variable names across all your code base. So it's a matter of preference, do what you're most comfortable with. You seem to be keen on using editor so I would say stick to the editor but move some of the reusable/complex logic into separate script files.

Detonating a mine to create some smoke - now that's authentic scripting 😄 Looks like a fun project. Here's a couple of issues in the script. 1. When you run setVectorDir, it resets velocity back to [0,0,0]. Move it up one line, before the setVelocity. 2. The bullet velocity calculation is largely dominated by the velocity of the vehicle so the orientation of the cannon has very little effect. You probably want to multiply only the part representing cannon direction. 3. (vectorDir cannon) is not necessarily pointing along the actual barrel Good luck!

Looks awesome, it would be a great addition to be able to configure loot along the lines of selectRandomWeighted syntax

Run allUnits apply {typeOf _x} in debug console and the output will show up below. There you can select it with mouse and use ctrl+c

As @dreadedentity pointed out, "32% busy" is a vague metric so let's come up with some concrete criteria. If I'm understanding you correctly, you want to find out how many scheduled scripts are actively competing for that 3ms window so that you can use this information to throttle your scripts accordingly. Suppose we spawn 10 running scripts that are mostly sleeping - the metric should be low. Suppose we add 1 script running flat-out - the metric should be still fairly low because this script runs as fast as you would expect it to run on its own, it's hardly ever interrupted. Suppose we add 10 more scripts running flat-out - now we expect the metric to be high - there are many scripts competing for the 3ms window and as a result each of them is running much slower than it would on its own. I believe that's actually what your test script is probing. I doubt that we can measure this efficiently using commands available currently in the stable build so here's an alternative approach: 1. Measure performance of your scripts internally, i.e. measure run time of a loop iteration or a lengthy function. 2. Calculate "business" value based on how the measured run time that compares to the expected / acceptable run time. 3. If you measure "business" value in multiple scripts, aggregate them into one final value. 4. Ensure that your scripts adapt accordingly to the current "business" value. Hope this helps 🙂

An interesting one indeed. I have a feeling that finding a correct solution requires way more geometry than I can endure 😅 I put together something that might do the trick. It's based on this function I found: https://community.bistudio.com/wiki/BIN_fnc_distanceToAreaBorder As far as I know, this function is available only when Contact DLC is enabled in the launcher so I copy-pasted the calculation into mine. Foley_fnc_nearestArea = { params ["_pos", "_areas"]; private _distances = _areas apply { [_pos, _x] call Foley_fnc_distanceToArea }; _distances find (selectMin _distances) }; Foley_fnc_distanceToArea = { params ["_pos", "_area"]; _area params ["_center", "_a", "_b", "_angle", "_isRectangle", "_c"]; private "_centerToEdge"; // This calculation stolen from https://community.bistudio.com/wiki/BIN_fnc_distanceToAreaBorder if (_isRectangle) then { private _dir = _angle - (_center getDir _pos); _centerToEdge = abs (_a / cos (90 - _dir)) min abs (_b / cos _dir); } else { private _dir = _angle - (_center getDir _pos) + 90; _centerToEdge = vectorMagnitude [ (_a * _b) / sqrt (_b ^ 2 + _a ^ 2 * tan _dir ^ 2), (_a * _b * tan _dir) / sqrt (_b ^ 2 + _a ^ 2 * tan _dir ^ 2), 0 ]; }; (_pos distance _center) - _centerToEdge }; Here's a demo It appears to work correctly but you may notice one frame where the green area is highlighted though the blue edge is slightly closer. This edge case (pun intended 😄) happens because the algorithm finds the point on the edge that's between you and the area center but that is not necessarily the nearest point to you.

It's quite new actually, added last year.

If by name you mean the variable name specified in editor in unit's properties, then you're on the right track. Try this: if ((vehicleVarName _unit) regexMatch "badman_[0-9]+") then { // _unit is badman }; A more flexible alternative would be to use setVariable and getVariable. After spawning the unit (or in init code) you can set a property, for example: _unit setVariable ["isBadman", true]; And then you can differentiate if a given unit has this property like so: if (_unit getVariable ["isBadman", false]) then { // _unit is badman };

You wanna do "G_Balaclava_blk" isEqualTo goggles _unit

It's an open-ended question so there is no single command that will answer it. Here are a few powerful commands you can play around with: https://community.bistudio.com/wiki/selectBestPlaces https://community.bistudio.com/wiki/isFlatEmpty https://community.bistudio.com/wiki/nearRoads Keep the radius small, compare their outputs and you'll find your answer 😉

As far as I remember, when you respawn, varvar is still pointing to your first (dead) character and not your current (alive) character. If you want to target the current player character, use https://community.bistudio.com/wiki/player However if you have something more complicated in mind, i.e. you want to carry information from the dead character to the respawned one, you can use https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#MPRespawn

If this is a concern during team switch, maybe this will do the trick? addMissionEventHandler ["TeamSwitch", { params ["_previousUnit", "_newUnit"]; if (!alive leader _newUnit) then { (group _newUnit) selectLeader _newUnit; }; }];

addAction has the radius parameter, does that work?

You don't need AI for this, just use https://community.bistudio.com/wiki/setFlagTexture To detect which flag is set you can use flagTexture in trigger condition.

setFlagAnimationPhase has local effects which means you need to remoteExec this command in particular. Instead of: RangeFlag3 setFlagAnimationPhase 1.0; do this: [RangeFlag3, 1.0] remoteExec ["setFlagAnimationPhase"]; Also, consider formatting the code to make it easier on yourself. It will be much simpler to spot errors like the missing [.

Wow, what a treat. The idea of using genetic algorithms for Arma have been on my mind for quite a while so it's nice to see a framework for it. Exploring the map to find best locations sounds like a great use case. Adorable manual, btw 😀