Shizweak

Try the following:
 
Remove MaxBandwidth (ARMA will figure this out itself quite fine)
Increase MaxSizeGauranteed to 768
 
You can also remove the whole class sockets { maxPacketSize=1400; }; - 1400 is the default anyway, and should work perfectly fine for 99.9% of users. If particular users are getting kicked/timed out constantly, tell them to look at their routers MTU setting.
 
In regards to your current settings, you are allowing each client to send 256 messages PER CYCLE, with maximum sizes of 128 and 256 respectively. So if you have 40 players, there is going to be ~10,000 messages trying to be sent per server cycle, and with your current MaxSizeGauranteed setting, you are most likely capping this out (or getting close, and choking on CPU) - which is why messages are pending. You want non guaranteed messages to be smaller (as they contain position changes etc, so you need these to go out ASAP), however guaranteed messages are not as time sensitive and can be aggregated into larger packets. Essentially you are sending lots of small guaranteed messages, which in turn has a higher overhead.
 
In terms of further tweaking, you can try reduce MaxMsgSend to 128/192, and keep slighting increasing MaxSizeGauranteed (don't got over 1400, I'd say a max of 1024). If you are seeing visible desync (e.g. vehicles careering over/off the road while a passenger) you can slightly decrease MaxSizeNongauranteed and even look at moving MinErrorToSendNear up a little.
 
(Anyone feel free to correct me on anything above)
 
 
Get real, this has nothing to do with the "new hize" (I think you meant hive) - it's related to ARMA's network configuration and the amount of data being streamed to the connected clients. 
 
You will probably find most of the people having this issue are either limited by hardware or bandwidth because they are hosting with providers who are either overselling on CPU, or throughput. That or they have simply copy/pasted a basic.cfg from somewhere else without understanding the values.
 
Either way, not a very nice way to talk to/about developers who are working so hard for free as BetterDeadThanZed has mentioned.

Try the following:
 
Remove MaxBandwidth (ARMA will figure this out itself quite fine)
Increase MaxSizeGauranteed to 768
 
You can also remove the whole class sockets { maxPacketSize=1400; }; - 1400 is the default anyway, and should work perfectly fine for 99.9% of users. If particular users are getting kicked/timed out constantly, tell them to look at their routers MTU setting.
 
In regards to your current settings, you are allowing each client to send 256 messages PER CYCLE, with maximum sizes of 128 and 256 respectively. So if you have 40 players, there is going to be ~10,000 messages trying to be sent per server cycle, and with your current MaxSizeGauranteed setting, you are most likely capping this out (or getting close, and choking on CPU) - which is why messages are pending. You want non guaranteed messages to be smaller (as they contain position changes etc, so you need these to go out ASAP), however guaranteed messages are not as time sensitive and can be aggregated into larger packets. Essentially you are sending lots of small guaranteed messages, which in turn has a higher overhead.
 
In terms of further tweaking, you can try reduce MaxMsgSend to 128/192, and keep slighting increasing MaxSizeGauranteed (don't got over 1400, I'd say a max of 1024). If you are seeing visible desync (e.g. vehicles careering over/off the road while a passenger) you can slightly decrease MaxSizeNongauranteed and even look at moving MinErrorToSendNear up a little.
 
(Anyone feel free to correct me on anything above)
 
 
Get real, this has nothing to do with the "new hize" (I think you meant hive) - it's related to ARMA's network configuration and the amount of data being streamed to the connected clients. 
 
You will probably find most of the people having this issue are either limited by hardware or bandwidth because they are hosting with providers who are either overselling on CPU, or throughput. That or they have simply copy/pasted a basic.cfg from somewhere else without understanding the values.
 
Either way, not a very nice way to talk to/about developers who are working so hard for free as BetterDeadThanZed has mentioned.

OK, had a chance to test it, it appears the above solution does work - removes all ammo from all guns on a vehicle.
 
EDIT: Oops, as someone gracefully reminded me - we also need to strip ammo from dynamically spawned vehicles:
 
 
Firstly, in your mission file, lets create an array of vehicles we want to strip ammo from - this way we can always just edit the mission file if we decide to add new armed vehicles. Inside init.sqf, simply add a new variable called "DZE_StripAmmo" near the others at the top of the file, e.g. here is what I have (not the full file, just the custom variables):
dayz_fullMoonNights = true; DZE_BuildingLimit = 500; DZE_StripAmmo = ["BAF_Jackal2_L2A1_D", "HMMWV_MK19", "HMMWV_Armored", "HMMWV_M2", "BRDM2_HQ_Gue", "BTR40_MG_TK_INS_EP1"]; You may add any armed vehicle to this array, to have it's weapons stripped of ammo.
 
 
 
Secondly, you want to edit the dayz_server code (extract the pbo), and jump into dayz_server/init/server_functions.sqf, and around line 260 we have the following:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; Update this, to include the ammo removal:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; if(_vehicle in DZE_StripAmmo) then { _veh setVehicleAmmo 0 };  Done, save the file.    
 
And finally, you want to edit the server monitor which is in dayz_server/system/server_monitor.sqf - open up the file and jump down to around line 130, we have:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; Update this to also include the ammo removal:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; if(_type in DZE_StripAmmo) then { _object setVehicleAmmo 0 }; Save the file, repack your server pbo, and your mission file if you choose to pack it - and give it a run!
 
You can find the class names for vehicles from A2 AND A2:OA here:
http://community.bistudio.com/wiki/ArmA_2:_Vehicles
http://community.bistudio.com/wiki/ArmA_2_OA:_Vehicles

OK, had a chance to test it, it appears the above solution does work - removes all ammo from all guns on a vehicle.
 
EDIT: Oops, as someone gracefully reminded me - we also need to strip ammo from dynamically spawned vehicles:
 
 
Firstly, in your mission file, lets create an array of vehicles we want to strip ammo from - this way we can always just edit the mission file if we decide to add new armed vehicles. Inside init.sqf, simply add a new variable called "DZE_StripAmmo" near the others at the top of the file, e.g. here is what I have (not the full file, just the custom variables):
dayz_fullMoonNights = true; DZE_BuildingLimit = 500; DZE_StripAmmo = ["BAF_Jackal2_L2A1_D", "HMMWV_MK19", "HMMWV_Armored", "HMMWV_M2", "BRDM2_HQ_Gue", "BTR40_MG_TK_INS_EP1"]; You may add any armed vehicle to this array, to have it's weapons stripped of ammo.
 
 
 
Secondly, you want to edit the dayz_server code (extract the pbo), and jump into dayz_server/init/server_functions.sqf, and around line 260 we have the following:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; Update this, to include the ammo removal:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; if(_vehicle in DZE_StripAmmo) then { _veh setVehicleAmmo 0 };  Done, save the file.    
 
And finally, you want to edit the server monitor which is in dayz_server/system/server_monitor.sqf - open up the file and jump down to around line 130, we have:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; Update this to also include the ammo removal:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; if(_type in DZE_StripAmmo) then { _object setVehicleAmmo 0 }; Save the file, repack your server pbo, and your mission file if you choose to pack it - and give it a run!
 
You can find the class names for vehicles from A2 AND A2:OA here:
http://community.bistudio.com/wiki/ArmA_2:_Vehicles
http://community.bistudio.com/wiki/ArmA_2_OA:_Vehicles

This is still a work in progress due to a couple of issues with BattlEye (script restrictions) and fixing some problems with automatic slot assignment for the HC. However, all the code is working when the HC is slotted correctly by an admin.
 
As some of you may know, the headless client is essentially another client that joins the game - but doesn't have a GUI. This allows you to offload AI to a separate process, which makes them more responsive under heavy load and in turn makes them a lot more deadly.
 
I've made a couple of small videos, based off of the scenario I'll be setting up on my public server - this is a military base on Skalitsky island. I'm also using a modified version of the Excelsior bridge (I made it longer and connect at different points of the island/main land).
 
The AI setup is randomised to an extent, there are 6 separate groups on the island - which all patrol/fortify several different areas. Each group has several different units, with different load outs (at the moment I have assault troops with AK74 GL, support LMG/snipers with PKP and SVD respectively) and each restart it chooses random amounts of clones for each unit, and places them randomly within the marker areas for their group. Each group has the potential to spawn about 30 units on average, so the maximum AI for this scenario would be 180 AI.
 
In the below examples, anywhere between 120-150 AI were spawned, the second example shows how deadly the AI are when you give them a DKSHM mounted vehicle!
 
Initial run:
 http://www.youtube.com/watch?v=em9cDZk2Y9k
 
Second run, AI using mounted vehicles:
http://www.youtube.com/watch?v=QRLp6lAA-TE
 
I'll be placing some weapons/building/general supply caches as loot incentives for raiding the island - although it won't be an easy task and most likely requiring assistance from water/air/road to be successful. Will be releasing the code once I'm happy with it.
 
 

Just install snap building into a fresh copy of player_build.sqf from the dayz_code pbo (easy enough), then change the following:
_isOk = true; _proceed = true; _counter = 0; /* while {_isOk} do { [10,10] call dayz_HungerThirst; player playActionNow "Medic"; _dis=20; _sfx = "repair"; [player,_sfx,0,false,_dis] call dayz_zombieSpeak; [player,_dis,true,(getPosATL player)] spawn player_alertZombies; r_interrupt = false; _animState = animationState player; r_doLoop = true; _started = false; _finished = false; while {r_doLoop} do { _animState = animationState player; _isMedic = ["medic",_animState] call fnc_inString; if (_isMedic) then { _started = true; }; if (_started and !_isMedic) then { r_doLoop = false; _finished = true; }; if (r_interrupt or (player getVariable["combattimeout", 0] >= time)) then { r_doLoop = false; }; if (DZE_cancelBuilding) exitWith { r_doLoop = false; }; sleep 0.1; }; r_doLoop = false; if(!_finished) exitWith { _isOk = false; _proceed = false; }; if(_finished) then { _counter = _counter + 1; }; cutText [format[(localize "str_epoch_player_139"),_text, _counter,_limit], "PLAIN DOWN"]; if(_counter == _limit) exitWith { _isOk = false; _proceed = true; }; }; */  All that does is set _proceed to true, and comments out the code that does the animation loop while constructing. I haven't tested this, but it should work fine.

Just install snap building into a fresh copy of player_build.sqf from the dayz_code pbo (easy enough), then change the following:
_isOk = true; _proceed = true; _counter = 0; /* while {_isOk} do { [10,10] call dayz_HungerThirst; player playActionNow "Medic"; _dis=20; _sfx = "repair"; [player,_sfx,0,false,_dis] call dayz_zombieSpeak; [player,_dis,true,(getPosATL player)] spawn player_alertZombies; r_interrupt = false; _animState = animationState player; r_doLoop = true; _started = false; _finished = false; while {r_doLoop} do { _animState = animationState player; _isMedic = ["medic",_animState] call fnc_inString; if (_isMedic) then { _started = true; }; if (_started and !_isMedic) then { r_doLoop = false; _finished = true; }; if (r_interrupt or (player getVariable["combattimeout", 0] >= time)) then { r_doLoop = false; }; if (DZE_cancelBuilding) exitWith { r_doLoop = false; }; sleep 0.1; }; r_doLoop = false; if(!_finished) exitWith { _isOk = false; _proceed = false; }; if(_finished) then { _counter = _counter + 1; }; cutText [format[(localize "str_epoch_player_139"),_text, _counter,_limit], "PLAIN DOWN"]; if(_counter == _limit) exitWith { _isOk = false; _proceed = true; }; }; */  All that does is set _proceed to true, and comments out the code that does the animation loop while constructing. I haven't tested this, but it should work fine.

I have exactly that in my init.sqf:
 
 
And it works fine for me, however, plot poles can still be used - and they still protect the area they are placed.
 
Perhaps get in touch with HFB.

Add in a missions pack like wai and you seem to get pretty much any weapon you've ever seen! the rarity of some makes banditry a little more worth while then:)... not that I'm a banditing type, far as I've experienced.. no client addons are needed to get any of these new guns.. so they must be addable by admin to the traders tables and maybe even the loot tables.. not sure on that one!

Try the following:
 
Remove MaxBandwidth (ARMA will figure this out itself quite fine)
Increase MaxSizeGauranteed to 768
 
You can also remove the whole class sockets { maxPacketSize=1400; }; - 1400 is the default anyway, and should work perfectly fine for 99.9% of users. If particular users are getting kicked/timed out constantly, tell them to look at their routers MTU setting.
 
In regards to your current settings, you are allowing each client to send 256 messages PER CYCLE, with maximum sizes of 128 and 256 respectively. So if you have 40 players, there is going to be ~10,000 messages trying to be sent per server cycle, and with your current MaxSizeGauranteed setting, you are most likely capping this out (or getting close, and choking on CPU) - which is why messages are pending. You want non guaranteed messages to be smaller (as they contain position changes etc, so you need these to go out ASAP), however guaranteed messages are not as time sensitive and can be aggregated into larger packets. Essentially you are sending lots of small guaranteed messages, which in turn has a higher overhead.
 
In terms of further tweaking, you can try reduce MaxMsgSend to 128/192, and keep slighting increasing MaxSizeGauranteed (don't got over 1400, I'd say a max of 1024). If you are seeing visible desync (e.g. vehicles careering over/off the road while a passenger) you can slightly decrease MaxSizeNongauranteed and even look at moving MinErrorToSendNear up a little.
 
(Anyone feel free to correct me on anything above)
 
 
Get real, this has nothing to do with the "new hize" (I think you meant hive) - it's related to ARMA's network configuration and the amount of data being streamed to the connected clients. 
 
You will probably find most of the people having this issue are either limited by hardware or bandwidth because they are hosting with providers who are either overselling on CPU, or throughput. That or they have simply copy/pasted a basic.cfg from somewhere else without understanding the values.
 
Either way, not a very nice way to talk to/about developers who are working so hard for free as BetterDeadThanZed has mentioned.

Try the following:
 
Remove MaxBandwidth (ARMA will figure this out itself quite fine)
Increase MaxSizeGauranteed to 768
 
You can also remove the whole class sockets { maxPacketSize=1400; }; - 1400 is the default anyway, and should work perfectly fine for 99.9% of users. If particular users are getting kicked/timed out constantly, tell them to look at their routers MTU setting.
 
In regards to your current settings, you are allowing each client to send 256 messages PER CYCLE, with maximum sizes of 128 and 256 respectively. So if you have 40 players, there is going to be ~10,000 messages trying to be sent per server cycle, and with your current MaxSizeGauranteed setting, you are most likely capping this out (or getting close, and choking on CPU) - which is why messages are pending. You want non guaranteed messages to be smaller (as they contain position changes etc, so you need these to go out ASAP), however guaranteed messages are not as time sensitive and can be aggregated into larger packets. Essentially you are sending lots of small guaranteed messages, which in turn has a higher overhead.
 
In terms of further tweaking, you can try reduce MaxMsgSend to 128/192, and keep slighting increasing MaxSizeGauranteed (don't got over 1400, I'd say a max of 1024). If you are seeing visible desync (e.g. vehicles careering over/off the road while a passenger) you can slightly decrease MaxSizeNongauranteed and even look at moving MinErrorToSendNear up a little.
 
(Anyone feel free to correct me on anything above)
 
 
Get real, this has nothing to do with the "new hize" (I think you meant hive) - it's related to ARMA's network configuration and the amount of data being streamed to the connected clients. 
 
You will probably find most of the people having this issue are either limited by hardware or bandwidth because they are hosting with providers who are either overselling on CPU, or throughput. That or they have simply copy/pasted a basic.cfg from somewhere else without understanding the values.
 
Either way, not a very nice way to talk to/about developers who are working so hard for free as BetterDeadThanZed has mentioned.

This is still a work in progress due to a couple of issues with BattlEye (script restrictions) and fixing some problems with automatic slot assignment for the HC. However, all the code is working when the HC is slotted correctly by an admin.
 
As some of you may know, the headless client is essentially another client that joins the game - but doesn't have a GUI. This allows you to offload AI to a separate process, which makes them more responsive under heavy load and in turn makes them a lot more deadly.
 
I've made a couple of small videos, based off of the scenario I'll be setting up on my public server - this is a military base on Skalitsky island. I'm also using a modified version of the Excelsior bridge (I made it longer and connect at different points of the island/main land).
 
The AI setup is randomised to an extent, there are 6 separate groups on the island - which all patrol/fortify several different areas. Each group has several different units, with different load outs (at the moment I have assault troops with AK74 GL, support LMG/snipers with PKP and SVD respectively) and each restart it chooses random amounts of clones for each unit, and places them randomly within the marker areas for their group. Each group has the potential to spawn about 30 units on average, so the maximum AI for this scenario would be 180 AI.
 
In the below examples, anywhere between 120-150 AI were spawned, the second example shows how deadly the AI are when you give them a DKSHM mounted vehicle!
 
Initial run:
 http://www.youtube.com/watch?v=em9cDZk2Y9k
 
Second run, AI using mounted vehicles:
http://www.youtube.com/watch?v=QRLp6lAA-TE
 
I'll be placing some weapons/building/general supply caches as loot incentives for raiding the island - although it won't be an easy task and most likely requiring assistance from water/air/road to be successful. Will be releasing the code once I'm happy with it.
 
 

OK, had a chance to test it, it appears the above solution does work - removes all ammo from all guns on a vehicle.
 
EDIT: Oops, as someone gracefully reminded me - we also need to strip ammo from dynamically spawned vehicles:
 
 
Firstly, in your mission file, lets create an array of vehicles we want to strip ammo from - this way we can always just edit the mission file if we decide to add new armed vehicles. Inside init.sqf, simply add a new variable called "DZE_StripAmmo" near the others at the top of the file, e.g. here is what I have (not the full file, just the custom variables):
dayz_fullMoonNights = true; DZE_BuildingLimit = 500; DZE_StripAmmo = ["BAF_Jackal2_L2A1_D", "HMMWV_MK19", "HMMWV_Armored", "HMMWV_M2", "BRDM2_HQ_Gue", "BTR40_MG_TK_INS_EP1"]; You may add any armed vehicle to this array, to have it's weapons stripped of ammo.
 
 
 
Secondly, you want to edit the dayz_server code (extract the pbo), and jump into dayz_server/init/server_functions.sqf, and around line 260 we have the following:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; Update this, to include the ammo removal:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; if(_vehicle in DZE_StripAmmo) then { _veh setVehicleAmmo 0 };  Done, save the file.    
 
And finally, you want to edit the server monitor which is in dayz_server/system/server_monitor.sqf - open up the file and jump down to around line 130, we have:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; Update this to also include the ammo removal:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; if(_type in DZE_StripAmmo) then { _object setVehicleAmmo 0 }; Save the file, repack your server pbo, and your mission file if you choose to pack it - and give it a run!
 
You can find the class names for vehicles from A2 AND A2:OA here:
http://community.bistudio.com/wiki/ArmA_2:_Vehicles
http://community.bistudio.com/wiki/ArmA_2_OA:_Vehicles

Excellent work. I'd thought this might work, but didn't want to bring down my server to test it. Also, as you said above, you can use removeMagazinesTurret to strip individual weapons for different vehicles. For example, I added the AH6J Little Bird and removed ammo from the Hydras (while leaving the flares and 4000rnd M134) by adding this after your DZE_StripAmmo line.
 
server_functions.sqf:
if(_vehicle == "AH6J_EP1") then { _veh removeMagazinesTurret ["14Rnd_FFAR",[-1]]; }; server_monitor.sqf:
if(_type == "AH6J_EP1") then { _object removeMagazinesTurret ["14Rnd_FFAR",[-1]]; }; server_publishVehicle2.sqf:
if(_class == "AH6J_EP1") then { _object removeMagazinesTurret ["14Rnd_FFAR",[-1]]; };

OK, had a chance to test it, it appears the above solution does work - removes all ammo from all guns on a vehicle.
 
EDIT: Oops, as someone gracefully reminded me - we also need to strip ammo from dynamically spawned vehicles:
 
 
Firstly, in your mission file, lets create an array of vehicles we want to strip ammo from - this way we can always just edit the mission file if we decide to add new armed vehicles. Inside init.sqf, simply add a new variable called "DZE_StripAmmo" near the others at the top of the file, e.g. here is what I have (not the full file, just the custom variables):
dayz_fullMoonNights = true; DZE_BuildingLimit = 500; DZE_StripAmmo = ["BAF_Jackal2_L2A1_D", "HMMWV_MK19", "HMMWV_Armored", "HMMWV_M2", "BRDM2_HQ_Gue", "BTR40_MG_TK_INS_EP1"]; You may add any armed vehicle to this array, to have it's weapons stripped of ammo.
 
 
 
Secondly, you want to edit the dayz_server code (extract the pbo), and jump into dayz_server/init/server_functions.sqf, and around line 260 we have the following:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; Update this, to include the ammo removal:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; if(_vehicle in DZE_StripAmmo) then { _veh setVehicleAmmo 0 };  Done, save the file.    
 
And finally, you want to edit the server monitor which is in dayz_server/system/server_monitor.sqf - open up the file and jump down to around line 130, we have:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; Update this to also include the ammo removal:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; if(_type in DZE_StripAmmo) then { _object setVehicleAmmo 0 }; Save the file, repack your server pbo, and your mission file if you choose to pack it - and give it a run!
 
You can find the class names for vehicles from A2 AND A2:OA here:
http://community.bistudio.com/wiki/ArmA_2:_Vehicles
http://community.bistudio.com/wiki/ArmA_2_OA:_Vehicles

OK, had a chance to test it, it appears the above solution does work - removes all ammo from all guns on a vehicle.
 
EDIT: Oops, as someone gracefully reminded me - we also need to strip ammo from dynamically spawned vehicles:
 
 
Firstly, in your mission file, lets create an array of vehicles we want to strip ammo from - this way we can always just edit the mission file if we decide to add new armed vehicles. Inside init.sqf, simply add a new variable called "DZE_StripAmmo" near the others at the top of the file, e.g. here is what I have (not the full file, just the custom variables):
dayz_fullMoonNights = true; DZE_BuildingLimit = 500; DZE_StripAmmo = ["BAF_Jackal2_L2A1_D", "HMMWV_MK19", "HMMWV_Armored", "HMMWV_M2", "BRDM2_HQ_Gue", "BTR40_MG_TK_INS_EP1"]; You may add any armed vehicle to this array, to have it's weapons stripped of ammo.
 
 
 
Secondly, you want to edit the dayz_server code (extract the pbo), and jump into dayz_server/init/server_functions.sqf, and around line 260 we have the following:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; Update this, to include the ammo removal:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; if(_vehicle in DZE_StripAmmo) then { _veh setVehicleAmmo 0 };  Done, save the file.    
 
And finally, you want to edit the server monitor which is in dayz_server/system/server_monitor.sqf - open up the file and jump down to around line 130, we have:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; Update this to also include the ammo removal:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; if(_type in DZE_StripAmmo) then { _object setVehicleAmmo 0 }; Save the file, repack your server pbo, and your mission file if you choose to pack it - and give it a run!
 
You can find the class names for vehicles from A2 AND A2:OA here:
http://community.bistudio.com/wiki/ArmA_2:_Vehicles
http://community.bistudio.com/wiki/ArmA_2_OA:_Vehicles

OK, had a chance to test it, it appears the above solution does work - removes all ammo from all guns on a vehicle.
 
EDIT: Oops, as someone gracefully reminded me - we also need to strip ammo from dynamically spawned vehicles:
 
 
Firstly, in your mission file, lets create an array of vehicles we want to strip ammo from - this way we can always just edit the mission file if we decide to add new armed vehicles. Inside init.sqf, simply add a new variable called "DZE_StripAmmo" near the others at the top of the file, e.g. here is what I have (not the full file, just the custom variables):
dayz_fullMoonNights = true; DZE_BuildingLimit = 500; DZE_StripAmmo = ["BAF_Jackal2_L2A1_D", "HMMWV_MK19", "HMMWV_Armored", "HMMWV_M2", "BRDM2_HQ_Gue", "BTR40_MG_TK_INS_EP1"]; You may add any armed vehicle to this array, to have it's weapons stripped of ammo.
 
 
 
Secondly, you want to edit the dayz_server code (extract the pbo), and jump into dayz_server/init/server_functions.sqf, and around line 260 we have the following:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; Update this, to include the ammo removal:
_veh = createVehicle [_vehicle, _position, [], 0, "CAN_COLLIDE"]; if(_vehicle in DZE_StripAmmo) then { _veh setVehicleAmmo 0 };  Done, save the file.    
 
And finally, you want to edit the server monitor which is in dayz_server/system/server_monitor.sqf - open up the file and jump down to around line 130, we have:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; Update this to also include the ammo removal:
_object = createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; if(_type in DZE_StripAmmo) then { _object setVehicleAmmo 0 }; Save the file, repack your server pbo, and your mission file if you choose to pack it - and give it a run!
 
You can find the class names for vehicles from A2 AND A2:OA here:
http://community.bistudio.com/wiki/ArmA_2:_Vehicles
http://community.bistudio.com/wiki/ArmA_2_OA:_Vehicles

That all depends on how many people you want driving around with loaded 50cals/grenade launchers, personally if I was to add them to the traders I'd at least make it a few 10oz bars, or even a BC.
 
In my opinion, I wish they were only available from the supply drops - being able to find them in military special loot piles makes it too easy to farm them.

This is still a work in progress due to a couple of issues with BattlEye (script restrictions) and fixing some problems with automatic slot assignment for the HC. However, all the code is working when the HC is slotted correctly by an admin.
 
As some of you may know, the headless client is essentially another client that joins the game - but doesn't have a GUI. This allows you to offload AI to a separate process, which makes them more responsive under heavy load and in turn makes them a lot more deadly.
 
I've made a couple of small videos, based off of the scenario I'll be setting up on my public server - this is a military base on Skalitsky island. I'm also using a modified version of the Excelsior bridge (I made it longer and connect at different points of the island/main land).
 
The AI setup is randomised to an extent, there are 6 separate groups on the island - which all patrol/fortify several different areas. Each group has several different units, with different load outs (at the moment I have assault troops with AK74 GL, support LMG/snipers with PKP and SVD respectively) and each restart it chooses random amounts of clones for each unit, and places them randomly within the marker areas for their group. Each group has the potential to spawn about 30 units on average, so the maximum AI for this scenario would be 180 AI.
 
In the below examples, anywhere between 120-150 AI were spawned, the second example shows how deadly the AI are when you give them a DKSHM mounted vehicle!
 
Initial run:
 http://www.youtube.com/watch?v=em9cDZk2Y9k
 
Second run, AI using mounted vehicles:
http://www.youtube.com/watch?v=QRLp6lAA-TE
 
I'll be placing some weapons/building/general supply caches as loot incentives for raiding the island - although it won't be an easy task and most likely requiring assistance from water/air/road to be successful. Will be releasing the code once I'm happy with it.
 
 

This is still a work in progress due to a couple of issues with BattlEye (script restrictions) and fixing some problems with automatic slot assignment for the HC. However, all the code is working when the HC is slotted correctly by an admin.
 
As some of you may know, the headless client is essentially another client that joins the game - but doesn't have a GUI. This allows you to offload AI to a separate process, which makes them more responsive under heavy load and in turn makes them a lot more deadly.
 
I've made a couple of small videos, based off of the scenario I'll be setting up on my public server - this is a military base on Skalitsky island. I'm also using a modified version of the Excelsior bridge (I made it longer and connect at different points of the island/main land).
 
The AI setup is randomised to an extent, there are 6 separate groups on the island - which all patrol/fortify several different areas. Each group has several different units, with different load outs (at the moment I have assault troops with AK74 GL, support LMG/snipers with PKP and SVD respectively) and each restart it chooses random amounts of clones for each unit, and places them randomly within the marker areas for their group. Each group has the potential to spawn about 30 units on average, so the maximum AI for this scenario would be 180 AI.
 
In the below examples, anywhere between 120-150 AI were spawned, the second example shows how deadly the AI are when you give them a DKSHM mounted vehicle!
 
Initial run:
 http://www.youtube.com/watch?v=em9cDZk2Y9k
 
Second run, AI using mounted vehicles:
http://www.youtube.com/watch?v=QRLp6lAA-TE
 
I'll be placing some weapons/building/general supply caches as loot incentives for raiding the island - although it won't be an easy task and most likely requiring assistance from water/air/road to be successful. Will be releasing the code once I'm happy with it.
 
 

I'm not sure why you see them as griefing tools, when it has already been stated that the "jump starter" will be rare, and have a high chance of failure. It's the servers choice to add them to the trader, I know I certainly won't be - just like lockboxes, combo locks and sledge hammers - they are good incentives for players to get out and about in the terrain and get into some trouble.
 
In regards to base glitching, this is something that's obviously not easily solved - I have a rule on my server, which is essentially 24 hour ban for glitching through walls, then a permanent ban for a second offence. If someone claims they cracked the door code, both parties are required to email an admin with the door codes, if they match (e.g. they cracked it), we do nothing - otherwise enforce with bans for unethical play. However, most players have now setup double doors, double walls and great security around their base - the only way in is brute forcing locks, or blowing down walls - if you try to glitch into these sort of bases, you get stuck between a cavity and spend a few hours dying of starvation.
 
I also didn't assume someone could para into your base, I was just responding to the scenario you posted in your previous post - if someone is willing to leave holes in their base, that is their problem - I was simply stating that if someone puts in the effort to para into a base, with vehicle ammo and a jump starter ready to go, they are probably a half decent player, not a griefer.
 
In regards to the "ammo deal", you do have a choice (that is, if you run your own server) - the devs already stated there will be variables to enable/disable the feature if you wish. And I'm sure there will be the ability to remove the ammo from a vehicle before a restart (at some point), it's only logical.
 
I also doubt there will be door lock picks, they are combination locks, you can't "pick" a combination lock.
 
In the end, I think we just have different views of what griefing is - I run a server with zero rules (apart from no unethical play, e.g. hacking, glitching, duping, combat logging), so you can destroy bases, blow up vehicles, kill people in trading camps (although we do have Klen as a "safe zone"), take over someone else's base if they haven't put down a plot pole or put combo locks on their door. We cater for banditry and heroism, and the additions of patch 1.0.2.4 are only going to make things more interesting in my opinion.

I welcome the changes in this patch, looks like some good ones. If the backpack deletion one stops dupers in their tracks, I'm all for it - just another thing to add to the checklist before logging off.
 
In regards to mounted vehicles requiring ammo, can we get an option to remove the current ammo too, if this hasn't already been added?

I wouldn't say one is better than the other, my solution uses the existing schema and updates the Datestamp column each time the record is updated, where as the other solution uses a new field "lastactive" which gets updated with the time it was updated. I don't see any reason we need to keep the initial creation date, unless you want to track how long a vehicle has been 'alive' for.
 
In regards to the trigger, it only needs to be added once - and it will fire before each row is updated. Tested this all last night, and seems to work fine.

Another solution is to add a trigger:
DELIMITER $$ CREATE TRIGGER update_object_datestamp BEFORE UPDATE ON object_data FOR EACH ROW BEGIN SET NEW.Datestamp = NOW(); END$$ DELIMITER ;

Generally defined in the BEServer.cfg file inside your instance profiles BattlEye folder
 
e.g:
instance_11_Chernarus\BattlEye\BEServer.cfg
 
If it's not there, create it, put in the following line:
RConPassword yourpasshere