hansen111

Yup, when im actually coding the system im going to have a routine putting players in arrays so its easy to use, it would be something like this (Not tested but you get the idea). //INIT _zoneNumbers = [0,1,2,3,4,5,6]; _gridZonePlayers = []; {_gridZonePlayers pushBack []} forEach _zoneNumbers; //ROUTINE { _player = _x; _mapgrid = mapGridPosition _player; { _zonenumber = _x; if(!isNil ("mygrid_" + str _zonenumber + _mapgrid)) exitWith { _playersInZone = _gridZonePlayers select _zonenumber; _playersInZone pushBack _player; }; } forEach _zoneNumbers; } forEach Allplayers; //To get the array of players in the zone 1; _zoneOnePlayers = _gridZonePlayers select 1; Edit: And btw if someone is wondering about grid sizes, radius ect then this system is based of the standard arma grid that the mapGridPosition function returns, a grid is 100m X 100m, every position in that grid translates to the same unique grid id which the mapGridPosition function returns when inputting the position. This system does NO distance checks but uses only mapGridPosition hence its much faster. If you need a circle distance check then you need to do normal distance checks but only for the few players inside the corresponding grid and not all players, again optimizing the method compared to only triggers.

It was mostly pseudo code to prove the system, I have now edited it so it would actually run, but you have to understand the system here instead of typos. The facts remain, the grid system on 7 zone case on 30 soldiers is 275 times faster (minus 1 call to the mapGridPosition function which I cant find a ms time on). Again the whole difference is that you dont have to do 7 distance checks but 7 isNil checks (+ 1 mapGridPosition call) Edit: And oh btw, yes im using grids. If you want to know if someone is in the circle area you have to run distance checks on those that is in the main grid, its still very few distance checks compared to running only triggers.

Ok, so I will illustrate this better, here is the situation for a case: https://steamcommunity.com/sharedfiles/filedetails/?id=2301831648 We have 7 zones, we want to check 1 time a second what players are in these zones. Now I know of all the modules and functions in the wiki ect. that does this but we can do a lot better performance wise, or at least i think so :-) by using the grid system, I will explain why: So the normal routine to check if someone (or something) is in a certain area is by doing a function, module, trigger that uses distance checks in a certain time period in a certain area, like 1 time a second for this example, we have to do this for each zone, so 7 triggers if we use those. BIS have made a great article explaining the performance of different functions here: https://community.bistudio.com/wiki/Code_Optimisation In there we can see: // with a 30 items array _someoneIsNear = (allUnits findIf { _x distance [0,0,0] < 1000 }) != -1; // 0.0275 ms _someoneIsNear = { _x distance [0,0,0] < 1000 } count allUnits > 0; // 0.0645 ms _someoneIsNear = { if (_x distance [0,0,0] < 1000) exitWith { true }; false } forEach allUnits; // 0.0390 ms that it would take 0.0275 ms to do 30 distance checks (30 soldiers). This is for 1 zone, we have 7, so it would be for each check: 0.0275 * 7 = 0,1925 ms In the grid system we would not need to do 7 distance checks, we need to do 7 isNil checks og 1 call to the mapGridPosition function, but only 1: _mapgrid = mapGridPosition player; { if(isNil ("mygrid_" + _x + _mapgrid)) then {hint "not in zone"}; } forEach _zones; Remember we ran a short init code before the mission begins that sets the zone variables, this is done only 1 time in init: //INIT GRID FOR MONITORING _gridCenter = [_gridX,_gridY]; _gridID = "mygrid_" + _gridnum + (mapGridPosition _gridCenter); missionNameSpace setVariable [_gridID, true]; On the BIS optimisation link above you can read the time 1 isNil check takes: isNil "varName"; // 0.0007 ms So we have reduced a 7 time distance check (0.0275 * 7 = 0,1925 ms) to a 7 time isNil check (0.0007 ms * 7 = 0,0049 ms). The grid system is 275 times faster! - from that we have to deduct the time that 1 call to the mapGridPosition takes so its a bit slower but still a fantastic optimisation!

Sure or some other stock function module we already have in the wiki, the important thing is if the grid system can greatly outperform those stock functions/modules. I did some testing and so far it seems the standard distance function is highly optimized, on 7 million iterations on my system there is only 4.5 seconds gained by using: isNil "somevar" instead of using player distance _pos <= _radius !? That is super surprising to me. Why would checking if a varibale isNil take almost as long as a full distance check!? I will test further..

Hello all So im writing a function (grid system) to avoid overhead on a algorithm that checks if players are in certain areas, the question is: Do the standard triggers/modules support this already or do they just iterate through all players with something like _unit distance _center on a defined interval? If its the ladder then using the already supported mapGridPosition function would greatly reduce overhead: //INIT GRID FOR MONITORING _gridCenter = [_gridX,_gridY]; _gridID = "mygrid_" + _gridNum + (mapGridPosition _gridCenter); missionNameSpace setVariable [_gridID, true]; //CHECKING IF PLAYER IS IN GRID _gridID = "mygrid_" + _gridNum + (mapGridPosition player); Method 1: if(isNil _gridID) then {hint "player IS NOT in grid"}; Method 2: if(missionNameSpace getVariable [_gridID, false]) then {hint "player IS in grid"}; So the question becomes: what is the speed comparison between _unit distance _center <= _radius and isNil ("mygrid_" + mapGridPosition player) ? I guess i will run some simulations on this. Thoughts? Thanks in advance.

Love the mod, very well done

You can always issue the Crew Exit (4) command :)

DropBox Link Updated today: - Moved High Command Transport Interface Activation To An Action (scroll-wheel) - Action For Activating Interface Is Only Available When Player Is In High Command Mode (LEFT CONTROL + SPACE)

Sure, just leave a thanks note in your credits

Operation Takistani Freedom Episode 1 - The Lalazar Oil Fields https://youtu.be/taqVFxMCrys Its been 10 years since a coalition, led by USA, defeated the Takistani army in Operation Desert Wind. A puppet government was put in place but Takistan was plagued by civil war in the following years. The civil unrest created the perfect conditions for the growth of the terrorist group called ISID. The group won some important battles against the Takistani government and seized control of oil fields which they use to finance their army. The ISID have claimed responsibility for terrorist attacks all over the world and this year the US Army have been sent back to help the Takistani army defeat ISID. In part 1 you will take the role of an A-10 pilot on a mission to soften up some hard ISID targets around the Lalazar oil Fields in preparation for a Takistani assault aimed at taking back the oil field. Events soon spiral out of control and the hunter becomes the hunted. Required Mods (All on steam - subscribe with 1 click): - CBA_A3 - CUP Terrains - Core - CUP Terrains - Maps - CUP Units - CUP Weapons - CUP Vehicles Hit the thumps up button on steam workshop if you like to see more missions in the OTF Campaign. Steam Link: http://steamcommunity.com/sharedfiles/filedetails/?id=799495845 DropBox: https://www.dropbox.com/s/34cmreeu1kpxg07/OTF%2520Part%25201%2520-%2520The%2520Lalazar%2520Oil%2520Fields.takistan.pbo?dl=1

Confirmed, really frustrating when vanilla things that should always work brakes like this. Hellcat gunship is useless atm.

Best mission seen so far on helo support missions, but Why oh why did you exclude the possibility of having a few AI pilot slots, just 1 slot for ai for taking out a few enemy vehicles would make a lot of difference. Most importantly, is it true i cant find the mission file anywhere? is this encrypted epo files? Please BI do not continue down this road, there is no Huron or any buyable dlc content that needs protection here, you effectly Lock out the possibilities of mission builders learning and making great edits the community wants, this behavior goes against everything i love about arma!

Correct, I have now found the REAL cause of the problem, in my case its actually a BI error in High Command Module. Your RPT error log will be spammed with the above error when setting a Destroy waypoint on enemy hc icon for one of yor hc groups when in High Command Mode (L CTRL + SPACE). That is giving a destroy waypoint for one of your hc groups, the spamming of the RPT log with these errors was so intense that my gaming rig dropped a lot of fps. At least I know what is causing it now.

It looks like setting the waypoint completion radius too small was the problem, REMOVING the following line in script seemed to have resolved this issue: _wp setWaypointCompletionRadius 0.5; Will report back here if issues continue for future readers having this problem. EDIT: I later found out this had nothing to do with the problem...read on...

Hi all My RPT log is getting spamed with these (Single Player): Destroy waypoint not linked to a target: Near target acquisition is slow and may even select friendly unit. Searched but did not find a clear answer, anyone know what is causing this? Thanks,