Harzach

Just run them consecutively. I would disable VCOM first. (Group this setVariable ["vcm_Disabled",true]; Null = [this,"2","track"] execVM "ups.sqf";

Tangential to the topic, but why do you continually define the variable _veh? //snip _veh = _this #0; _veh removeWeaponTurret ["cannon_120mm_long",[0]]; _veh = _this #0; _veh removeMagazinesTurret ["20Rnd_120mm_APFSDS_shells_Tracer_Yellow",[0]]; _veh = _this #0; _veh removeMagazinesTurret ["12Rnd_120mm_HE_shells_Tracer_Yellow",[0]]; _veh = _this #0; _veh removeMagazinesTurret ["12Rnd_120mm_HEAT_MP_T_Yellow",[0]]; _veh = _this #0; _veh removeWeaponTurret ["LMG_coax",[0]]; _veh = _this #0; _veh removeMagazinesTurret ["200Rnd_762x51_Belt_Yellow",[0]]; // _veh is defined at the beginning and will remain so in that scope, there is no need to redefine it before every use. That's what variables are for. //snip _veh = _this #0; _veh removeWeaponTurret ["cannon_120mm_long",[0]]; _veh removeMagazinesTurret ["20Rnd_120mm_APFSDS_shells_Tracer_Yellow",[0]]; _veh removeMagazinesTurret ["12Rnd_120mm_HE_shells_Tracer_Yellow",[0]]; _veh removeMagazinesTurret ["12Rnd_120mm_HEAT_MP_T_Yellow",[0]]; _veh removeWeaponTurret ["LMG_coax",[0]]; _veh removeMagazinesTurret ["200Rnd_762x51_Belt_Yellow",[0]]; //

https://community.bistudio.com/wiki/setOwner

The ACE Wiki isn't comprehensive. Bookmark the ACE GitHub for future browsing: https://github.com/acemod/ACE3/tree/master/addons

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.

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

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.