Grahame

Okay folks, I have made some changes (will update the first post with them) based on suggestions and good video reports from @Kenobi- Cheers mate!
First, a small change to the take clothes code in CfgActionMenu_target.hpp so that the option to take clothes will not be provided when looking at dead things with no uniforms, like the vanilla Epoch adversaries like sappers, cloakers and zombies and the Ryan's Zombies zombies (which are not the same):
// Take Clothes class take_clothes { condition = "((!alive dyna_cursorTarget) && ((dyna_cursorTarget isKindOf 'SoldierWB') || (dyna_cursorTarget isKindOf 'SoldierEB') || (dyna_cursorTarget isKindOf 'SoldierGB')))"; action = "[dyna_cursorTarget, player] call TakeClothes;"; icon = "x\addons\a3_epoch_code\Data\UI\buttons\group_requests_ca.paa"; tooltip = "Take Clothes"; }; The definition of the base classes for west, east and guer soldiers should catch most AI wearing uniforms from any mod. That definitely is the case for CUP.
Changed the custom/TakeClothes.sqf script to set a variable on the corpse so a uniform can only be changed once, even if you subsequently take the uniform off them (thanks @Ghostrider-GRG) and present a message to the player if they attempt to take it again:
/* Author: Grahame Description: Take and wear any clothes from a dead player or AI Licence: Arma Public License Share Alike (APL-SA) - https://www.bistudio.com/community/licenses/arma-public-license-share-alike */ private ["_target","_player","_target_uniform","_player_uniform","_target_carried_items","_player_carried_items","_clothes_taken"]; _target = _this select 0; _player = _this select 1; _target_carried_items = []; _player_carried_items = []; _items_to_add = []; _clothes_taken = _target getvariable ["CLOTHESTAKEN", "false"]; if (_clothes_taken != "true") then { _target setvariable ["CLOTHESTAKEN", "true", true]; _target_uniform = uniform _target; _player_uniform = uniform _player; _target_carried_items = uniformItems _target; _player_carried_items = uniformItems _player; _items_to_add = _player_carried_items + _target_carried_items; _target forceAddUniform _player_uniform; _player forceAddUniform _target_uniform; { _player addItem _x; } foreach _items_to_add; } else { ["Clothes have already been taken from this body", 5] call Epoch_message; }; As a result of that change you will also need to add !"CLOTHESTAKEN" to your setvariable.txt BattlEye filter.
Please let me know if you find any other issues.

I wrote that one based on the code in Epoch's admin tools...

And here is a better solution, now using the dynaMenu and checking that the vehicle is unlocked and you were the last driver (thus dealing with the issue of object locality). All changes are in the mission file.
Add the following to epoch_config/Configs/CfgActionMenu/CfgActionMenu_target.hpp:
// Flip Vehicle class flip_vic { condition = "dyna_isVehicle && !dyna_locked"; action = "[dyna_cursorTarget] call FlipVic;"; icon = "x\addons\a3_epoch_code\Data\UI\buttons\build_upgrade.paa"; tooltip = "Flip Vehicle"; }; Add a script in the folder where you store your custom ones, for example custom/, called FlipVehicle.sqf with the following contents:
private ["_target"]; _target = _this select 0; if (local _target) then { _target setVectorUp [0, 0, 1]; ["Flipped vehicle",5] call epoch_message; } else { ["You were not the driver of this vehicle",5] call epoch_message; }; Add the following lines into your mission's init.sqf replacing the script's folder with where ever you put yours:
if(hasInterface) then{ FlipVic = compileFinal preprocessFileLineNumbers "custom\FlipVehicle.sqf"; }; RePBO the mission, upload to the server...

@webbieAt a very simplistic level, add a script called custom/flip_vehicle.sqf with the following code:
_target = cursorTarget; if((!isNull _target) && {alive _target} && {_target isKindOf 'Landvehicle' || _target isKindOf 'Air' || _target isKindOf 'Ship'})then { _target setVectorUp [0, 0, 1]; ['Flipped vehicle!',0,0.7,2,0] spawn bis_fnc_dynamictext; }; Add the following line to initPlayerLocal.sqf in the root of your mission file:
flipvic = player addAction ["<t color=""#F8FF24"">" +"Flip Vehicle","custom\flip_vehicle.sqf","",1,false,false,"",""]; You now have a scroll wheel action to flip a vehicle. 
Will add some code to check you are the driver (which as an aside also handles the locality issue in MP) and post an update later. 

And here is a better solution, now using the dynaMenu and checking that the vehicle is unlocked and you were the last driver (thus dealing with the issue of object locality). All changes are in the mission file.
Add the following to epoch_config/Configs/CfgActionMenu/CfgActionMenu_target.hpp:
// Flip Vehicle class flip_vic { condition = "dyna_isVehicle && !dyna_locked"; action = "[dyna_cursorTarget] call FlipVic;"; icon = "x\addons\a3_epoch_code\Data\UI\buttons\build_upgrade.paa"; tooltip = "Flip Vehicle"; }; Add a script in the folder where you store your custom ones, for example custom/, called FlipVehicle.sqf with the following contents:
private ["_target"]; _target = _this select 0; if (local _target) then { _target setVectorUp [0, 0, 1]; ["Flipped vehicle",5] call epoch_message; } else { ["You were not the driver of this vehicle",5] call epoch_message; }; Add the following lines into your mission's init.sqf replacing the script's folder with where ever you put yours:
if(hasInterface) then{ FlipVic = compileFinal preprocessFileLineNumbers "custom\FlipVehicle.sqf"; }; RePBO the mission, upload to the server...

And here is a better solution, now using the dynaMenu and checking that the vehicle is unlocked and you were the last driver (thus dealing with the issue of object locality). All changes are in the mission file.
Add the following to epoch_config/Configs/CfgActionMenu/CfgActionMenu_target.hpp:
// Flip Vehicle class flip_vic { condition = "dyna_isVehicle && !dyna_locked"; action = "[dyna_cursorTarget] call FlipVic;"; icon = "x\addons\a3_epoch_code\Data\UI\buttons\build_upgrade.paa"; tooltip = "Flip Vehicle"; }; Add a script in the folder where you store your custom ones, for example custom/, called FlipVehicle.sqf with the following contents:
private ["_target"]; _target = _this select 0; if (local _target) then { _target setVectorUp [0, 0, 1]; ["Flipped vehicle",5] call epoch_message; } else { ["You were not the driver of this vehicle",5] call epoch_message; }; Add the following lines into your mission's init.sqf replacing the script's folder with where ever you put yours:
if(hasInterface) then{ FlipVic = compileFinal preprocessFileLineNumbers "custom\FlipVehicle.sqf"; }; RePBO the mission, upload to the server...

And here is a better solution, now using the dynaMenu and checking that the vehicle is unlocked and you were the last driver (thus dealing with the issue of object locality). All changes are in the mission file.
Add the following to epoch_config/Configs/CfgActionMenu/CfgActionMenu_target.hpp:
// Flip Vehicle class flip_vic { condition = "dyna_isVehicle && !dyna_locked"; action = "[dyna_cursorTarget] call FlipVic;"; icon = "x\addons\a3_epoch_code\Data\UI\buttons\build_upgrade.paa"; tooltip = "Flip Vehicle"; }; Add a script in the folder where you store your custom ones, for example custom/, called FlipVehicle.sqf with the following contents:
private ["_target"]; _target = _this select 0; if (local _target) then { _target setVectorUp [0, 0, 1]; ["Flipped vehicle",5] call epoch_message; } else { ["You were not the driver of this vehicle",5] call epoch_message; }; Add the following lines into your mission's init.sqf replacing the script's folder with where ever you put yours:
if(hasInterface) then{ FlipVic = compileFinal preprocessFileLineNumbers "custom\FlipVehicle.sqf"; }; RePBO the mission, upload to the server...

Heli is out of fuel after some time so I added this code to file fnc_vehicle_patrol.sqf and now heli is flying all day long :-)
Put code below anywhere between:   while{_run}do{   and last bracket:   };

//    Refuell code START
    if (fuel _unit <= 0.2) then
    {
        _unit setFuel 1;
        diag_log "***[Sector] Vehicle refuelled sucessfully***";
    };
//    Refuell code END
 
 

I have doublechecked it and the problem was a missing recalculation of the current stock in the cleanup checks.
Anyway the "old" cfgtraderlimit is no longer needed and has been removed (last post).
Edit:
I am currently sorting some last things out..
 
Edit2:
I think I got everything now. Please take these 2 changed files and let me know, if it works as expected:
https://github.com/EpochModTeam/Epoch/blob/experimental/Sources/epoch_server/compile/epoch_traders/EPOCH_server_loadTraders.sqf
https://github.com/EpochModTeam/Epoch/blob/experimental/Sources/epoch_code/compile/traders/EPOCH_npcTraderAdd.sqf

@webbieYeah, seen that on other maps too. Apparently BIS_fnc_findsafepos() finds the same bloody location every time it's called (roughly). Will fix. Got a few things to do - will try to get this one sorted tomorrow if RL does not intervene

Actual fix (will test) would be to remove lines 60-64 in epoch_code/compile/traders/EPOCH_npc_TraderAdd.sqf:
_limit = ["CfgTraderLimits", _uiItem, 100] call EPOCH_fnc_returnConfigEntryV2; if (_itemQty >= _limit) then{ _stockLimit = true; _allowAdd = false; }; and in epoch_server/compile/epoch_traders/EPOCH_server_loadTraders.sqf, remove line 56:
_limit = ["CfgTraderLimits", _item, 100] call EPOCH_fnc_returnConfigEntryV2; Remove lines 63 to 68:
if (_limit == 0 || _currentStock == 0) then { // diag_log format ["EPOCH_DEBUG: TraderSlot: %1 | Removed %2 from Trader | _limit: %3 | _currentStock: %4",_i,str _item, _limit,_currentStock]; _arrchanged = true; _delete = true; } else { Remove lines 75-79:
if (_currentStock > _limit) then { _arrchanged = true; (_arr select 1) set [_idx,_limit]; _currentStock = _limit; }; and remove line 112:
};  

After changing values in both of those files (just changing the one in the mission file had no affect), it's working as expected.
Thanks @He-Man and @Grahame for your help!  Looking forward to fix(es) in the next release.

Actual fix (will test) would be to remove lines 60-64 in epoch_code/compile/traders/EPOCH_npc_TraderAdd.sqf:
_limit = ["CfgTraderLimits", _uiItem, 100] call EPOCH_fnc_returnConfigEntryV2; if (_itemQty >= _limit) then{ _stockLimit = true; _allowAdd = false; }; and in epoch_server/compile/epoch_traders/EPOCH_server_loadTraders.sqf, remove line 56:
_limit = ["CfgTraderLimits", _item, 100] call EPOCH_fnc_returnConfigEntryV2; Remove lines 63 to 68:
if (_limit == 0 || _currentStock == 0) then { // diag_log format ["EPOCH_DEBUG: TraderSlot: %1 | Removed %2 from Trader | _limit: %3 | _currentStock: %4",_i,str _item, _limit,_currentStock]; _arrchanged = true; _delete = true; } else { Remove lines 75-79:
if (_currentStock > _limit) then { _arrchanged = true; (_arr select 1) set [_idx,_limit]; _currentStock = _limit; }; and remove line 112:
};  

@phmThe lines should be simply removed now there are new methods to set trader limits - was a holdover from previous versions I think. Grep-ed all of EpochMod source. Used in epoch_code/compile/traders/EPOCH_npc_TraderAdd.sqf and epoch_server/compile/epoch_traders/EPOCH_server_loadTraders.sqf
The fix will require code changes to alter _limit properly but to test and give you a quick fix, change line 60 of epoch_code/compile/traders/EPOCH_npc_TraderAdd.sqf to
_limit = 5000; and line 56 of epoch_server/compile/epoch_traders/EPOCH_server_loadTraders.sqf to read the same.
Let us know whether that fixes it for you. I will try on my dev server when I finish work later if I do not hear back first.

Is the issue that CfgTraderLimits is not set up?
_limit = ["CfgTraderLimits", _item, 100] call EPOCH_fnc_returnConfigEntryV2;  

First test of infected spawns via the standard ARMA3 Epoch lootbubble. Infected spawn out of LOS and right now just a hard coded one per building.   No DayZ code was used in this new feature.   As always, apologies for the video quality, my PC is a potato...    

So there are a couple of serious glitches that are possible with the use of the Enhanced Interaction functionality within the Enhanced Movement mod on Epoch servers. Not going to list them here but they are incredibly serious and need to be fixed if you are running EM on your Epoch server. Thankfully, there is a quite easy solution to "turn off" Enhanced Interaction within the mission file. If you are already using the initPlayerLocal.sqf file for things like the autolockpicker, attaching demo charges to things and other stuff, then just add the following to it:
[] spawn { while {true} do { if !((profilenamespace getvariable ["babe_int_keys_Use",[0,""]]) isequalto [0,""]) then { profilenamespace setvariable ["babe_int_keys_Use",[0,""]]; }; uisleep 1; }; }; If you are not already using the file, but are using EM then create an initPlayerLocal.sqf with the following:
if (!isDedicated and hasInterface) then { waitUntil {alive vehicle player}; waitUntil {typeOF player != "VirtualMan_EPOCH"}; uisleep 15; [] spawn { while {true} do { if !((profilenamespace getvariable ["babe_int_keys_Use",[0,""]]) isequalto [0,""]) then { profilenamespace setvariable ["babe_int_keys_Use",[0,""]]; }; uisleep 1; }; }; }; Repack the mission PBO, upload to your server and the possible glitches are dealt with, while still allowing the lovely niceness of Enhanced Movement to continue.
Thanks very much to @He-Manfor invaluable help in crafting the solution and thanks to Duralius, a player on my server for finding the glitches and not exploiting them. Good man!

So there are a couple of serious glitches that are possible with the use of the Enhanced Interaction functionality within the Enhanced Movement mod on Epoch servers. Not going to list them here but they are incredibly serious and need to be fixed if you are running EM on your Epoch server. Thankfully, there is a quite easy solution to "turn off" Enhanced Interaction within the mission file. If you are already using the initPlayerLocal.sqf file for things like the autolockpicker, attaching demo charges to things and other stuff, then just add the following to it:
[] spawn { while {true} do { if !((profilenamespace getvariable ["babe_int_keys_Use",[0,""]]) isequalto [0,""]) then { profilenamespace setvariable ["babe_int_keys_Use",[0,""]]; }; uisleep 1; }; }; If you are not already using the file, but are using EM then create an initPlayerLocal.sqf with the following:
if (!isDedicated and hasInterface) then { waitUntil {alive vehicle player}; waitUntil {typeOF player != "VirtualMan_EPOCH"}; uisleep 15; [] spawn { while {true} do { if !((profilenamespace getvariable ["babe_int_keys_Use",[0,""]]) isequalto [0,""]) then { profilenamespace setvariable ["babe_int_keys_Use",[0,""]]; }; uisleep 1; }; }; }; Repack the mission PBO, upload to your server and the possible glitches are dealt with, while still allowing the lovely niceness of Enhanced Movement to continue.
Thanks very much to @He-Manfor invaluable help in crafting the solution and thanks to Duralius, a player on my server for finding the glitches and not exploiting them. Good man!

Another class of item added to EpochCore client-side in 1.1 are deployable sleeping bags. Here is the code for placing them and a suggestion (and code) for actually making use of them to provide greater flexibility at respawn for your players.
Installation Instructions
(1) Add the sleeping bag "kits" to your loot tables and trader price lists. The class names are KitSleepingBagGreen, KitSleepingBagBlue and KitSleepingBagBrown
(2) Add the following to epoch_config/Configs/CfgItemInteractions.hpp:
class KitSleepingBagGreen : Item_Build_base { buildClass = "SleepingBagGreen_SIM_EPOCH"; }; class KitSleepingBagBlue : Item_Build_base { buildClass = "SleepingBagBlue_SIM_EPOCH"; }; class KitSleepingBagBrown : Item_Build_base { buildClass = "SleepingBagBrown_SIM_EPOCH"; }; (3) Add the following to epoch_config/Configs/CfgBaseBuilding.hpp:
class SleepingBagGreen_EPOCH : Default { removeParts[] = {{"KitSleepingBagGreen",1}}; GhostPreview = "SleepingBagGreen_Ghost_EPOCH"; staticClass = "SleepingBagGreen_EPOCH"; simulClass = "SleepingBagGreen_SIM_EPOCH"; bypassJammer = 1; }; class SleepingBagGreen_SIM_EPOCH : SleepingBagGreen_EPOCH { removeParts[] = {}; }; class SleepingBagGreen_Ghost_EPOCH : SleepingBagGreen_SIM_EPOCH {}; class SleepingBagBlue_EPOCH : Default { removeParts[] = {{"KitSleepingBagBlue",1}}; GhostPreview = "SleepingBagBlue_Ghost_EPOCH"; staticClass = "SleepingBagBlue_EPOCH"; simulClass = "SleepingBagBlue_SIM_EPOCH"; bypassJammer = 1; }; class SleepingBagBlue_SIM_EPOCH : SleepingBagBlue_EPOCH { removeParts[] = {}; }; class SleepingBagBlue_Ghost_EPOCH : SleepingBagBlue_SIM_EPOCH {}; class SleepingBagBrown_EPOCH : Default { removeParts[] = {{"KitSleepingBagBrown",1}}; GhostPreview = "SleepingBagBrown_Ghost_EPOCH"; staticClass = "SleepingBagBrown_EPOCH"; simulClass = "SleepingBagBrown_SIM_EPOCH"; bypassJammer = 1; }; class SleepingBagBrown_SIM_EPOCH : SleepingBagBrown_EPOCH { removeParts[] = {}; }; class SleepingBagBrown_Ghost_EPOCH : SleepingBagBrown_SIM_EPOCH {}; So, at this point you can place sleeping bags and they look pretty nice, but what's the point. Well, say for example that you would like to seal your jammer away in a dark place in your base but don't want to respawn in that room, but do want to respawn somewhere in a base; or perhaps you are doing a mission or you're off hunting heroes and don't want to make your way from the coast all over again... well, you can set sleeping bags to be spawn points too!
(4) Change the definition for the select_jammer class in epoch_config/Configs/CfgActionMenu/cfgActionMenu_target.hpp to:
class select_jammer { condition = "((dyna_cursorTargetType isEqualTo 'PlotPole_EPOCH') || (dyna_cursorTargetType isEqualTo 'SleepingBagGreen_EPOCH') || (dyna_cursorTargetType isEqualTo 'SleepingBagBlue_EPOCH') || (dyna_cursorTargetType isEqualTo 'SleepingBagBrown_EPOCH')) && (damage dyna_cursorTarget < 1)"; action = "[dyna_cursorTarget,player,Epoch_personalToken] remoteExec [""EPOCH_server_makeSP"",2];"; icon = "x\addons\a3_epoch_code\Data\UI\buttons\player_inspect.paa"; tooltip = "Make Spawnpoint"; }; RePBO your mission file and upload it to the server.
(5) Now unpack epoch_server.pbo. There is one file in there that needs a change which is compile/epoch_player/EPOCH_server_loadPlayer.sqf. Change line 145 from:
_jammers = nearestObjects[_CheckLocation, ["PlotPole_EPOCH"], 6]; to:
_jammers = nearestObjects[_CheckLocation, ["PlotPole_EPOCH","SleepingBagGreen_EPOCH","SleepingBagBlue_EPOCH","SleepingBagBrown_EPOCH"], 6]; RePBO epoch_server.pbo and upload to your server. You now have sleeping bags that can be built anywhere and used as respawn points.
Be aware though! Anyone can pick yours up in the wild (as they should be able to) and you will no longer spawn at its location!
(Optional 6) Also note that should you give these as starting gear you may want to add energy to a player at spawn by changing the energy entry in the CustomVarsDefaults array in epoch_config/CfgEpochClient.hpp to something like the following (which gives 1250 energy to a new spawned player):
{"Energy",1250,{2500,0}},  

Another item added to EpochCore client-side in 1.1 is a Large Workbench - using the ARMA model for a steel work table with drawers and a vice. Here is the code for placing them and a suggestion (and code) for actually making use of them to provide greater flexibility in crafting for your players.
Installation Instructions
(1) Add the large workbench "kit" to your loot tables and trader price lists. The class name is KitWorkbenchLarge
(2) Add the following to epoch_config/Configs/CfgItemInteractions.hpp:
class KitWorkbenchLarge : Item_Build_base { buildClass = "WorkbenchLarge_SIM_EPOCH"; }; (3) Add the following to epoch_config/Configs/CfgBaseBuilding.hpp:
class WorkbenchLarge_EPOCH : Default { removeParts[] = {{"KitWorkbenchLarge",1}}; GhostPreview = "WorkbenchLarge_Ghost_EPOCH"; staticClass = "WorkbenchLarge_EPOCH"; simulClass = "WorkbenchLarge_SIM_EPOCH"; }; class WorkbenchLarge_SIM_EPOCH : WorkbenchLarge_EPOCH { removeParts[] = {}; }; class WorkbenchLarge_Ghost_EPOCH : WorkbenchLarge_SIM_EPOCH {}; So, those minor changes will allow you to build a large workbench from a kit and then utilize it within Epoch's crafting system. All further changes will be made to epoch_config/Configs/CfgCrafting.hpp.
Let's start our examination of that with the crafting of the large workbench itself. The crafting system in Epoch is really nice, quite simple (though it can look imposing at first glance) and very flexible. Basically it comprises parts and kits that are built from them and allows the specification of either things (water or fire) or objects to be nearby in order to build the kit. For the building of the large workbench you will need to add the following new entry:
class KitWorkbenchLarge : Kit { recipe[] = {{"PartPlankPack",8},{"ItemCorrugatedLg",2},{"ItemPipe",2},{"ItemCorrugated",2},{"VehicleRepair",1}}; nearby[] = {{"Workbench","","workbench",{1,{"WorkBench_EPOCH","WorkbenchLarge_EPOCH"}},3,1,0,1}}; model = "\A3\Structures_F_Heli\Furniture\Workbench_01_F.p3d"; previewPosition[] = {0.8,1,0.27}; previewScale = 0.15; previewVector = 0; }; This entry illustrates nicely the configuration for a craftable item. Let's look at a few lines in it starting with the recipe[]. This specifies which items are needed to build the kit, in this case 8 lumber packs, 2 large salvage metal, two pipes, two small salvage metals and a vehicle repair parts (for the vice). In order to show the Large Workbench as a buildable from these individual items in the crafting menu you need to add the Large Workbench to their entries' usedin[] array, for example:
Okay, at this point you can click on any of these parts and a Large Workbench will be shown as a possible recipe for the part. Now let's look at the nearby[] array in the Large Workbench's crafting definition. This specifies things that are needed nearby in order to complete the crafting, in this case:
nearby[] = {{"Workbench","","workbench",{1,{"WorkBench_EPOCH","WorkbenchLarge_EPOCH"}},3,1,0,1}}; Now, reading the very handy comment at the head of CfgCrafting.hpp shows what each part of this line means:
USAGE: nearby[] = { { "Fire", //Name of field, anything "", //image folder path (ie "\x\addons\a3_epoch_code\Data\UI\crafting\"), empty for Epoch default "fire", //image prefix, suffix will be added by code. 2 possible suffixes: [_true.paa, _false.paa] {1,{"ALL"}}, //ARRAY of p3D {0,{"filename.p3d","filename.p3d"}} or ARRAY of logic classes {1,{"AIR","LAND","className"}} or 2 WorldInteractions check {2,{"water"}} Integer to switch array mode 3, //distance to check in meters 1, //count 1, //BOOL: object has to be on fire 0 //BOOL: object has to be alive (not destroyed) }; }; So you can see in the nearby[] array for Large Workbenches that it needs either a standard Epoch workbench or a large workbench itself within 3m of the player in order to build one. You can have as many requirements as you want in that list including categories defined in epoch_config/Configs/CfgEpochClient/WorldInteractions.hpp like "Water" or "Tree" or ... "bankTerminal" 
Now you can craft a Large Workbench and then build it, you can now use the fact you have one to make crafting just a little more immersive by, for example, only allowing small things to be crafted with a standard Epoch workbench and requiring a large workbench for more complicated or larger buildables. For example, let's say we leave buckets of mortar as being able to be crafted on a small one. You probably also want to allow your to craft them on a large one as well so you would have both items in the nearby[] array for them:
class MortarBucket : Item { usedIn[] = {"KitFoundation","KitCinderWall","KitHesco3","KitCinderFloor","KitCinderHalfFloor","KitCinderQuarterFloor","KitCinderTower","KitSandbagWall","KitSandbagWallLong","KitBagBunker","KitWaterPump","KitWell"}; nearby[] = {{"Fire","","fire",{1,{"ALL"}},3,1,1,0},{"Workbench","","workbench",{1,{"WorkBench_EPOCH","WorkbenchLarge_EPOCH"}},3,1,0,1}}; recipe[] = {{"ItemRock",12},{"water_epoch",2}}; previewPosition[] = {0.799442,1,0.426761}; previewScale = 0.6; previewVector = 0; }; Now this is an interesting item (the reason I picked it...) because it demonstrates making a craftable dependent on multiple things nearby, in this case a burning fire and either a small or large workbench... cool huh?
For the wooden buildables I like to allow a small workbench so each of their definitions would have both the large and small workbench in the nearby[] array like this:
class KitStudWall : Kit { recipe[] = {{"PartPlankPack",4}}; model = "\x\addons\a3_epoch_assets\models\Wooden_Wall_SIM.p3d"; nearby[] = {{"Workbench","","workbench",{1,{"WorkBench_EPOCH","WorkbenchLarge_EPOCH"}},3,1,0,1}}; previewPosition[] = {0.797675,1,0.398882}; previewScale = 0.07; previewVector = 0; }; But for cinder buildables I think you need a more flexible work environment, thus the small workbench is removed from their nearby[] arrays, for example:
class KitCinderFloor : Kit { usedIn[] = {"KitCinderTower"}; recipe[] = {{"CinderBlocks",4},{"MortarBucket",4}}; nearby[] = {{"Large Workbench","","workbench",{1,{"WorkbenchLarge_EPOCH"}},3,1,0,1}}; model = "\x\addons\a3_epoch_community\models\cinderfloor.p3d"; previewPosition[] = {0.800198,1,0.262418}; previewScale = 0.055; previewVector = 3.6; }; That's pretty much it. Now you can build a large workbench, craft one and make other items dependent on it - or indeed any other object in the game. As a final example here's a modified entry for an energy pack that relies on you having a power source within 30m, and a fire and a large workbench within 3m:
class EnergyPack : Item { usedIn[] = {"EnergyPackLg"}; nearby[] = {{"Fire","","fire",{1,{"ALL"}},3,1,1,0},{"Large Workbench","","workbench",{1,{"WorkbenchLarge_EPOCH"}},3,1,0,1},{"Power Source","","electricity",{1,{"Land_spp_Tower_F","Land_wpp_Turbine_V2_F","Land_wpp_Turbine_V1_F","SolarGen_EPOCH","Land_Wreck_Satellite_EPOCH"}},30,1,0,1}}; recipe[] = {{"CircuitParts",1},{"ItemCopperBar",1},{"clean_water_epoch",1}}; previewPosition[] = {0.8,1,0.29}; previewScale = 1.75; previewVector = 2.8; }; Now let your imagination run wild!

I have ported some of the Extra Wicked AI missions from ARMA2/DayZ/Epoch's Wicked AI system. They are a purely derivative product based on this work:
Missions ported so far are: Abandoned Trader, Ambushed HMMWV, Army Base, Drone Pilot, Old MacDonald's Farm and Slaughter House. 
I will be continuing this work with the others when I have time.
NOTE: In order to use these missions you will require CUP Terrains Core on your server. For those running non-vanilla ARMA3 maps, for example Chernarus Redux that should not be an issue.
Download
https://www.dropbox.com/s/19ln1t6yhsmbldw/Extra_WAI_Missions.zip?dl=0
Installation
(1) Copy the files in the downloadable archive to your Wicked AI's missions/bandit folder.
(2) Add the missions to the mission array in WAI's config.sqf, for example:
wai_bandit_missions = [ ["abandoned_trader",5], ["ambushed_hmmwv",5], ["army_base",5], ["drone_pilot",4], ["macdonald",5], ["slaughter_house",5], ["nuke",4], ["Mi_48",6], ["MV_22",6], ["sniper_team",8], ["rebel_base",5], ["medi_camp",5], ["dropside",5], ["comm_center",10], ["C_192",11], ["destroyed_ural",11] RePBO Wicked AI and upload to @epochhive/addons and enjoy!

Another WIP thing... testing the Left Shoulder Scripted Weapon mod with Epoch. Server side mod only so no worries about adding to player's clients.
While the animations are a bit clunky it works... Need to add code to Epoch to save the "hidden" weapon in the database or it will be lost on a disconnect
https://steamcommunity.com/sharedfiles/filedetails/947704792
 

So there are a couple of serious glitches that are possible with the use of the Enhanced Interaction functionality within the Enhanced Movement mod on Epoch servers. Not going to list them here but they are incredibly serious and need to be fixed if you are running EM on your Epoch server. Thankfully, there is a quite easy solution to "turn off" Enhanced Interaction within the mission file. If you are already using the initPlayerLocal.sqf file for things like the autolockpicker, attaching demo charges to things and other stuff, then just add the following to it:
[] spawn { while {true} do { if !((profilenamespace getvariable ["babe_int_keys_Use",[0,""]]) isequalto [0,""]) then { profilenamespace setvariable ["babe_int_keys_Use",[0,""]]; }; uisleep 1; }; }; If you are not already using the file, but are using EM then create an initPlayerLocal.sqf with the following:
if (!isDedicated and hasInterface) then { waitUntil {alive vehicle player}; waitUntil {typeOF player != "VirtualMan_EPOCH"}; uisleep 15; [] spawn { while {true} do { if !((profilenamespace getvariable ["babe_int_keys_Use",[0,""]]) isequalto [0,""]) then { profilenamespace setvariable ["babe_int_keys_Use",[0,""]]; }; uisleep 1; }; }; }; Repack the mission PBO, upload to your server and the possible glitches are dealt with, while still allowing the lovely niceness of Enhanced Movement to continue.
Thanks very much to @He-Manfor invaluable help in crafting the solution and thanks to Duralius, a player on my server for finding the glitches and not exploiting them. Good man!

Another WIP thing... testing the Left Shoulder Scripted Weapon mod with Epoch. Server side mod only so no worries about adding to player's clients.
While the animations are a bit clunky it works... Need to add code to Epoch to save the "hidden" weapon in the database or it will be lost on a disconnect
https://steamcommunity.com/sharedfiles/filedetails/947704792
 

Another WIP thing... testing the Left Shoulder Scripted Weapon mod with Epoch. Server side mod only so no worries about adding to player's clients.
While the animations are a bit clunky it works... Need to add code to Epoch to save the "hidden" weapon in the database or it will be lost on a disconnect
https://steamcommunity.com/sharedfiles/filedetails/947704792