Hi, I've been trying to do this for a while and I can't seem to get it right.   It is quite simple, it is a function that destoys a certain part of the buidlings in a array of buildings.    params["_houses","_amount"]; private _number = (count _houses) * _amount; for [{private _i = 0}, {_i < _number}, {_i = _i + 1}] do { (_houses select _i) setdamage [1, false]; }; It works in SP without issues, however in multiplayer weird stuff starts happening. It will work as intended for some players, but other with see both the wrecked building and the original building, most of the time flickering.  I thought it was a JIP issue, and it probably is. But I've read a lot a posts and the wiki about a dozen of times and setDamage is global, and should work with the JIP queue (as said here http://killzonekid.com/arma-scripting-tutorials-scripted-charges-v2/ at the end) And I trust bohemia with what they do, it usually works. So I guess I am missing something   I could just do everything with a remoteExec[0,true] but that seems a little brutal and will generate a lot of unecessary traffic, I would rather not include that feature if that is the only solution. i could also store the buidlings somewhere and destoyThem whenever someone enters the server, it is less worse than the remoteExec but it still is a bit nasty since their is no local version of setDamage.   So the question is, has anyone ever managed to do that in a "performance friendly" way?  
Thank you for your time :)

Thanks for the suggestion!

I suppose a marker would be more efficient than a trigger. This should be fairly easy to start with, I'm trying to iterate as I go. Not sure if I will have the same issue I had with the trigger, if so I will report back. The issue was that the player exiting a vehicle within the trigger caused them to be vulnerable for 10 seconds. The vehicle would not remain invulnerable. 

To extrapolate it out, It's basically a KOTH style safezone. 

So it would be something like... Before we delete the vehicle in the action take a note of its type, I know not particularly needed for your script as they are all of the same type, but if you wanted to expand this later its easier to incorporate it now. //We create the cargo container that we want our aircraft to be transported in _blackHawkContainer = "B_Slingload_01_Cargo_F" createVehicle _blackHawkPos; //Make note of vehicle number and vehicle type on the wreck container _blackHawkContainer setVariable[ "wreckInfo", [ _vehNum, typeOf _target ] ]; Then for the trigger we do not need the inArea check, if the container is in thisList ( it must be satisfying the triggers activation settings) then it must already be in the trigger area. //Does something in the triggers thisList have a variable on it called wreckInfo thisList findIf{ !isNil ( _x getVariable "wreckInfo" ) } >= 0       TBH for this I would spawn a trigger from script for each wreck container( it means they maybe a few triggers active at a time depending on how many vehicles are currently dead but should not be a problem, you can even change their polling rate to make things less resource intensive ). Each trigger can then be set to [ "VEHICLE", "PRESENT", true ] then the trigger is only looking for this particular wreck crate "VEHICLE", eliminates all the confusion about getting the right object from the trigger.         Ok this system is getting quite large now and has many parts that are all crammed into one script. It is at this point in a project where I would start thinking about what I have and separate it out into its parts. So lets think this through, we have... Initialisation of vehicles applying eventHandler adding wreck ( marker, action ) packaging wreck ( container, trigger ) repairing vehicle ( spawning new vehicle ) ...so lets make a script for each of these independently.   Run out of time for today, going to continue when a get back later this evening/tomorrow.

So you should start to work on it. There is no time to lose.     Let's say 20 Areas (.et) with an update rate of 10 seconds (as shown in the main post) definitely will NOT affect the match performance.
EDITED May 17th: Performing new tests deactivating the Despawn System only for those Areas, the mission works fine in an unchangeable FPS, which is perfect. I will edit the main post with the info.

Thank you!