Harzach

And it's great for writing totally natural-sounding responses to forum posts! Cool!

And unfortunate that there are those with such a narrow view of what Arma is and can be.

Give it a second waypoint, type "CYCLE." It will return to its start position then move to the SAD waypoint, ad infinitum. Speaking of which, setWaypointLoiterRadius is only relevant to the "LOITER" waypoint type, which is itself only relevant to aircraft.

Yes. If you aren't interested, don't buy it.

I'm picking up two invisible characters in the last line of your code. Impossible for me to say if they are being created when I copy, or if they are in your code already. These characters seem to pop up most when I copy/paste from the Biki - which makes a lot of code found on the forums suspect. Always check via a code block here, or in your editor. In a forum code block, they appear as red dots. In Notepad++, check View > Show Symbol > Show Non-Printing Characters.

ACE doing ACE things, probably.

Check your syntax: https://community.bistudio.com/wiki/doArtilleryFire Also, try in vanilla (unmodded) Arma first.

Best I can figure at the moment is all mags in inventory, plus any loaded mags in unequipped weapons - NOT including any weapons you may have in your backpack/vest/uniform. That might take some other voodoo. private _rounds = 0; magazinesAmmoFull player select { (_x #3 == -1 || (_x #2 == true && _x #4 != currentMuzzle player)) } apply { _rounds = _rounds + _x #1 }; hintSilent str _rounds; So if you have your primary equipped, this will skip that mag, but will include the mags in your handgun and secondary.

Do you mean the map icons? These can be found in ui_f_data.pbo > Map > Vehicle Icons.

Those commands return an array that holds only a string. The info you want is embedded in that string, and can be tricky to extract. Example from the wiki: [ "6.5mm 30Rnd STANAG Mag(30/30)[id/cr:1/0](3x)" ] An easier route might be magazinesAmmoFull, which returns a multidimensional array of all magazines, including some very useful parameters. If we filter the array for unloaded magazines only, we skip counting loaded mags and other mag types like throwables. Then we just grab the ammo count parameter and add it to the pool. private _rounds = 0; magazinesAmmoFull player select { (_x #3 == -1) } apply { _rounds = _rounds + _x #1 }; hint str _rounds; Keep in mind that this results in a single number that includes all varieties of bullets.

Maybe you could get the current distance to the laserTarget then add a few meters. private _target = laserTarget gunner <vehicleName>; private _dist = gunner _tank distance _target; private _overShoot = _dist + 5;

I was playing around with this some more this morning and it seems that my "fix" isn't a fix at all. With getPos there are cases where the search aborts itself, just as with getPosATL. I think getPosATL was probably the best option, with your scenario creating an edge case where it fails. We can hope that Larrow will be able to take a look at this and maybe implement a solution.

OK, I managed to set up my test mission such that I was seeing your issue (using the default searchLoot.) I changed line 16 in fn_initSearch.sqf: _searchPos = getPosATL _player; //change to _searchPos = getPos _player; and everything worked as expected. I'm staying with this because you shouldn't have to employ workarounds that compromise your intent. getPos uses PositionAGLS, so if your waves are high enough, it may throw things off a bit. Though this may only require increasing LARs_searchRadius in LARs_lootSettings.sqf by however high the waves are.

I'm not bragging, friend. I'm telling you that Personally, I would take a clean version of the searchLoot system and build a simple test mission to troubleshoot. Or share a version of your mission with the default searchLoot system so others can giver you a fresh perspective.

I placed a few different rocks of different sizes under the pier with no issue.

I just did.

You are recreating the same marker. Why? You can just change the existing one. That's what commands like setMarkerColor are for. _trigArray = [ [5782.864,10333.795], [12895.979,7353.194], [5517.676,9951.941], [1809.986,11952.15], [3051.818,11187.059], [9556.457,13465.348], [13416.808,12078.425], [8621.35,10250.979], [11852.628,2528.827], [11295.57,5227.608], [5482.726,4058.376], [7383.236,8253.998], [7910.444,7686.77] ]; _randomLA = selectRandom _trigArray; _mrk = createMarker ["marker1", _randomLA]; "marker1" setMarkerShape "ELLIPSE"; "marker1" setMarkerColor "ColorRed"; "marker1" setMarkerSize [500, 500]; "marker1" setMarkerBrush "SOLID"; _trg = createTrigger ["EmptyDetector", _randomLA]; _trg setTriggerArea [500, 500, 0, false]; _trg setTriggerActivation ["ANYPLAYER", "PRESENT", true]; _trg setTriggerStatements [ "this", " 'marker1' setMarkerColor 'ColorBlack' ", "" ];

I downloaded @Larrow's SearchLoot mission. In the editor, I placed a wooden pier in the middle of the sea, with the typical "pile of garbage bags" object sitting on it. Everything worked fine. There might be something else in your mission causing your issue.

Yeah, it looks like most modules are synced only at mission init, so you can't sync new objects during mission runtime. The "dummy' method is probably the way to go.

https://community.bistudio.com/wiki/synchronizeObjectsAdd Admittedly, this description is not completely clear - "unit" in this case refers to the thing you are synchronizing to, "objects" refers to an array of objects to be synchronized to that thing. richtaskdest synchronizeObjectsAdd [trgtfshmn1];

Ah, cool. Check the links in my sig - you'll get an overview of the differences, as well as basic-to-comprehensive descriptions/examples of every command/function/etc. Have fun!

The "Keys" item is in fact NOT an item, but a magazine. The command items returns everything but magazines, while the uniform/vest/backpackItems commands do return magazines, which is why your second attempt worked. Easier is to just use itemsWithMagazines, which returns everything.

Check your syntax, you have some weird things going on: _trg setTriggerStatements ["this", execVM "Marker1.sqf'", "'"]; Elements in an array are separated by commas. I find that arrays are easier to see when they are expanded vertically: _trg setTriggerStatements [ "this", // correct execVM "Marker1.sqf'", // nope! "'" // nope! ]; The parameters of setTriggerStatements (exclusive of the leading handle) are an array of strings. So, in this case, each element should be a complete string. And since the .sqf name in an execVM is also a string, it will be a string within a string, for which we use single quotes: _trg setTriggerStatements [ "this", // correct "execVM 'Marker1.sqf'", // correct "" // correct ]; ALSO While it's not incorrect, you are mixing use of the createMarker handle with the marker name in your "Marker1.sqf." The handle returns the marker name, so it works normally, but it's inconsistent and maybe "non-aesthetic." bob = createMarker ["marker1", [5782.864,10333.795]]; "marker1" setMarkerShape "ELLIPSE"; "marker1" setMarkerColor "Colorblack"; "marker1" setMarkerSize [500, 500]; "marker1" setMarkerBrush "SOLID"; // same as bob = createMarker ["marker1", [5782.864,10333.795]]; bob setMarkerShape "ELLIPSE"; bob setMarkerColor "Colorblack"; bob setMarkerSize [500, 500]; bob setMarkerBrush "SOLID"; Though there is no real reason to use a global, since the marker name itself is global: private _bob = createMarker ["marker1", [5782.864,10333.795]]; "marker1" setMarkerShape "ELLIPSE"; "marker1" setMarkerColor "Colorblack"; "marker1" setMarkerSize [500, 500]; "marker1" setMarkerBrush "SOLID"; // same as _bob = createMarker ["marker1", [5782.864,10333.795]]; _bob setMarkerShape "ELLIPSE"; _bob setMarkerColor "Colorblack"; _bob setMarkerSize [500, 500]; _bob setMarkerBrush "SOLID"; As you get deeper into scripting, you might want to decide on consistent styles. It makes things easier to read, and so easier to troubleshoot.

You haven't set a markerType/markerShape for any of your markers. The strings in markersArray do not match the names of the markers you have created. You have used the script handles instead. Check your commands on the wiki for proper syntax.

You still have a comma after your first "select 0." Commas are used to separate elements in an array.