This is used to remove zeds during daytime. So zombies comes only at night. Credit goes to @juandayz
1- In your custom compiles.sqf into !dedicated section paste:
2- Copy building_spawnLoot.sqf && zombie_generate.sqf from ...\@DayZ_Epoch\addons\dayz_code\compile\
to: mpmissions\Your_Instance\dayz_code\compile\
3-A Open the new building_spawnZombies.sqf
3-B Open zombie_generate.sqf
4- Open zombie_Wildgenerate.sqf from dayz_server.pbo\compile\
*Note: if u wanna have zeds during day and not in night just change the condition on each file.
if (sunOrMoon == 1) exitWith {}; //zeds at night
by:
if (sunOrMoon != 1) exitWith {};//zeds during daytime
Thanks @juandayz
I'm guessing your player_death you are using is still from 1.0.6.1 since we no longer send the sourceWeapon as an array: https://github.com/EpochModTeam/DayZ-Epoch/commit/c671cf96614405723bff0bfc737292eac9feb449#diff-a92a5523c7a552460361786994ab777f
I have not really updated the battleye filters for 1.0.6.2, There will be a lot of changes if everyone is filtering for systemChat etc.
If I get time I'll do it in the next week or so.
name is used as the profile name the server runs on, i.e. similar to your player name, except it controls the server settings directory name and RCON message name
With hosting providers you may not be able to move the config folder as requested since a lot of the time you are only allowed access to your own directory.
There's nothing stopping you moving the config folder inside of your Arma 2 OA folder and changing the directory name.
As far as the update SQL goes, GTX should be able to enable what is required to do the update SQL, if they don't want to, it's their business they will miss out on.
There is a security vulnerability in A2/OA where config files placed inside of the A2/OA root can be read by a hacker if the file name and path is known or guessed. Files placed outside of the A2 folder, A2 documents folder and A2 appdata folder cannot be read by A2/OA so this effectively solves the vulnerability. The next best step is to make the startup bat name, profile directory, server and battle configs long and random such that they cannot be guessed and read.
On our ESLK PVE servers, players are not required to claim or mark missions where bandits are not present. They are encouraged but not required to let other players know that they've looted the mission crate.
Since this caused a surprising amount of friction when a player would travel across the map only to find an empty crate, we added code to the standard missions that puts a "crate-visited" mark on the map when a player gets within 10M of the crate. The crate may or may not be empty but at least everyone knows someone has been to the mission crate.
Here are the present and visit loops (idea lifted from the @juandayz Bombcrate mission):
Here is our complete version of the Construction mission - thanks to @salival for all the help with the coding details.
Just add it to the array:
use_blacklist = true; // use blacklist
blacklist = [
[[0,16000,0],[1000,-0,0]], // Left
[[0,16000,0],[16000.0,14580.3,0]], // Top
[[8246,15485,0],[square coords here]] //custom 1
];
But you need another point. The blacklist defines areas so you need 2 points that act like the edges for a square.
Hi guys,
Here's an in vehicle garage door opener I wrote a while ago, Original idea was from Sanbird.
It will scan while you're inside a vehicle for either a locked cinder or a locked wooden door, providing you have access to it, it will allow you to open/close it from inside the car.
https://github.com/oiad/garageDoorOpener
**** For Epoch 1.0.6.2 only **** >> Download <<
Visit this link: https://github.com/oiad/garageDoorOpener/tree/garageDoorOpener-Epoch-1.0.6.2
===
Credits:
All credit belongs to all authors of used source files:
DayZ Epoch developers, collaborators and contributors (thank you guys for your excellent work!)
@Markk311, @f3cuk, @Jossy, @BangL, @nerdalertdk, @Caveman - creators of this system
@JasonTM, @salival, @ebayShopper - for keeping system alive, further developing and fantastic support
Special Thanks goes to:
@_Lance_ for deep addon testing and most usefull feedback. Thanks to him we know, how IWAC works under heavy load on populated server (12 concurrent missions :))
@totis, who brings great ideas into this script and did a great tester job!
@DAmNRelentless for offering German translation and taking care of addon Github repo.
@salival for his ZSC remote msg script which we are using
... all great guys helping make WAI better (I'm pretty sure I forgot a lot of people...). Thank you all for your great job!
===
Download v1.3.1 [Last update: 2018-01-16]
===
Introduction:
... once upon a time, *mr. yeahBUT* and *mr. no_name* chatting:
---
Q: mr. yeahBUT
IWAC? OMG, what is it?
A: mr. no_name
Well, it's Autoclaim addon for WAI mission system.
---
Q: mr. yeahBUT
...yeah, but is it usefull? What it can do?
A: mr. no_name
Not sure about the first question part... but it could be.
If one of your server rules says somenthing like: "Player has to claim mission in sidechat and mark mission on map with name", well, this addon is just for you.
It's fully automatic, which means - no more sentences like: "I forgot...", "Who is doing mission xy?", "Could you please remove your marker once mission is finished?" etc.
This little addon will make all the job for you and your players.
---
Q: mr. yeahBUT
pffff... I have PVP server. Totally useless!
A: mr. no_name
Probably yes... Do you wanna hear more?
---
Q: mr. yeahBUT
hmmm.. not really, but I have nothing to do right now, so continue...
A: mr. no_name
...OK my friend. I have certainly nothing to do either, so I will... :) What's your question?
---
Q: mr. yeahBUT
ok.. let's start with somenthing I can picture in my mind. Do you have any screenshot so I can see it in action?
A: mr. no_name
yeah, sure...
---
Q: mr. yeahBUT
What is that red circle around mission?
A: mr. no_name
This is somenthing I call it "claiming zone". You can configure it using these variables:
iben_wai_ACzoneActivate = true; // Turn claiming border ON/OFF
iben_wai_ACzoneMarkerColor = "ColorRed"; // Border color
iben_wai_ACdistance = 1300; // Distance from mission center to claiming border
---
Q: mr. yeahBUT
hm.. 1300m? It's a little bit too much. Should be much shorter distance.
A: mr. no_name
It's completely up to you. If you want to be loved by your snipers, set it to 400m and set AI skills to max - no kidding, I experienced this setup already :))
Also remember - there is somenthing called timeout distance in WAI - you can search variable `wai_timeout_distance` in WAI config.
If `wai_timeout_distance` < `iben_wai_ACdistance`, mission can dissapear in front of player's face (which doesn't mean it's a bad thing...)
---
Q: mr. yeahBUT
Well, it's too bad. Can you imagine what happen if two or three missions spawns close to each other? You think it's not a problem player could claim multiple missions?
A: mr. no_name
How should I answer this question...? Let's start with this: When you try to setup any system, you should think about it.
I mean - there are variables `wai_avoid_missions` and `wai_avoid_traders` in WAI config for example.
Just use bellow formulas and you should prevent mission (mission claim zones) overlapping:
wai_avoid_missions = ((iben_wai_ACdistance * 2) + 500);
wai_avoid_traders = (iben_wai_ACdistance + 200 + 500);
// ... also see picture bellow:
---
Q: mr. yeahBUT
That's nice, but I've already experienced mission placement is not perfect... there is a chance player will claim two missions!
A: mr. no_name
In fact, it's not possible. If player is already 'claimer', he is registered and system doesn't allow him to claim multiple times (you can see it in the video at the bottom).
---
Q: mr. yeahBUT
Alright... what's that flag with name? I don't want to expose player name!
A: mr. no_name
It's up to you again. You can configure all about player marker using these variables:
iben_wai_ACshowNames = true; // If false, text = "Claimed by a player [realtime status info]"
iben_wai_ACmarkerType = "hd_flag";
iben_wai_ACmarkerColor = "ColorBlack";
---
Q: mr. yeahBUT
ok... yeah, but it's too bad to expose player by setting marker on his position...
A: mr. no_name
You are not exposing his position. Marker is created in random spot within given range. You can adjust it by setting variable:
iben_wai_ACmarkerRange = 400;
---
Q: mr. yeahBUT
cool... so why not create flag object to be visible close mission? Cool idea, huh?
A: mr. no_name
yeah, sure it is :) You can use these variables:
iben_wai_ACcreateFlagOjb = true;
iben_wai_ACmarkerFlagClass = "FlagCarrierINDFOR_EP1";
// ... see the picture bellow:
---
Q: mr. yeahBUT
How will player know about claiming is happening?
A: mr. no_name
You can enable message system and let player know. Just use bellow variable and install client side files:
iben_wai_ACplayerMsg = true;
---
Q: mr. yeahBUT
Yeah, but... still. Why should all players force to read useless msg that are not about them?
Also... that's server resources waste to broadcoast so many msgs...!
A: mr. no_name
Actually msg is private. Only player involved is informed and can see the msg.
---
Q: mr. yeahBUT
Yeah... but there is couple more troubles. For example: Mission just spawn close to my position or I'm just passing by location.
I don't want to be a part of mission fight, but still... I'm in zone... That's not good.
A: mr. no_name
You can use bellow variable and set it to some reasonable value in seconds.
That gives passing by players enough time to decide to stay or leave claiming area.
iben_wai_ACsafeClaimDelay = 60;
---
Q: mr. yeahBUT
Too many troubles... what about players in bases?
A: mr. no_name
Just make your decision if you want to allow players fight missions from base or not. You can use following variables.
This way you can force autoclaim system to ignore these players.
iben_wai_ACplotRestriction = true;
iben_wai_ACplotRange = 30; // If 'iben_wai_ACplotRestriction' is true, what distance from plotpole is not allowed?
---
Q: mr. yeahBUT
Hm, but what if player claimed the mission and dies, loses connection etc. What then, ha...?
A: mr. no_name
As you can see at the above picture, there is marker with player name (or anonymous name) and so called `realtime status`.
If player is alive and fighting inside claiming zone, status is `Active`. If player is gone - timeout is fired.
That means, system will wait given time for claimer return. If timeout runs off, mission is free for claiming.
You can set some reasonable time for timeout in seconds:
iben_wai_ACtimeout = 300;
---
Q: mr. yeahBUT
What about my admins? I don't want them to claim missions just because they are helping inside zone...
A: mr. no_name
Yeah, got it. You can exclude your admins from system:
iben_wai_ACexcludeAdmins = true;
iben_wai_ACadmins = ["0","0"]; // List your admins UID's
---
Q: mr. yeahBUT
Wait! I'm using moving missions like 'patrol'. It's a nonsense to use autoclaim for that kind of missions!
A: mr. no_name
Agree. If you have any kind of moving missions, or custom missions you want to be free for all, just exclude them:
iben_wai_ACexcludedTypes = ["patrol"];
---
Q: mr. yeahBUT
Ok then. So... I have couple more minutes before my favourite movie starts. So last a few questions:
I believe you will face problems in such scenarios like: multiple players in the same time in the zone - who will be first?
What about other players? And what about player or better players in vehicle?
You will not be able to sort them out and it's gonna be chaos!
A: mr. no_name
Well, I made the best I could in given time and space. I don't want to go too deep, but imagin autoclaim system as somenthing like simple `memory buffer`.
This buffer is **(a)** able to recognize all players in area (including all players inside vehicles); **(b)** is able to sort them out by distance.
It's very small probability two players will reach the same distance in the same time - the only exception crossed my mind are players
n the same vehicle - they share the same distance. But system is able to recognize them and sort them from driver to cargo.
But anyway, system is able to handle these scenarios pretty well (at least I hope so according to test results); **(c)** System works in layers - from register list, wait list to claim list. Each layer is equiped by self-cleaning mechanism,
so each list is real image of status in claiming zone. (self-cleaning means, once player leave area etc., he is kicked from list
and next player in list takes his place - there are no `dead souls in list`).
---
Q: mr. yeahBUT
OK... here we go. So another loop for WAI. It's already server performace killer as it is...!
A: mr. no_name
Hm... good point! And no, we are not creating any extra loop (not single one...). We are using already existing loops -
and we are using these loops only and only if it's reasonable and exiting them immediately if condition isn't met.
According to couple weeks testing on populated server with cca 20 players, no FPS drop was recognized.
BTW: you can add some debug logs to loop critical points and see the result.
---
Q: mr. yeahBUT
...yeah, but I can imagine how installation is gonna be difficult...
A: mr. no_name
Actually, it's not. Visit this github repo and clone or download files. Follow repo structure and merge it with your server/client files.
---
Q: mr. yeahBUT
That's all you can say about installation??? Are you serious??
A: mr. no_name
No and yes. One more thing - addon is designed the way so you don't need to touch any of WAI core files (except a few lines in init).
If you will follow repo structure, you can quickly switch between default WAI files and addon files by setting bellow variable to true/false.
iben_wai_ACuseAddon = true;
// :: WARNING > If you don't know what I mean by "merge files" at this momment,
// :: you should probably wait a little bit and learn, before you start to play with (especially) server-side files.
---
Q: mr. yeahBUT
Hmmm... my movie has just started... have to go now. And BTW... your English sucks... and this addon too... bye...
A: mr. no_name
:( ... I know... bye...
===
Later in time...
===
Q: mr. yeahBUT
Hey! IWAC is now part of WAI by default?
A: mr. no_name
Yes, it is. Since v1.2. It's updated for Epoch 1.0.6.2...
---
Q: mr. yeahBUT
I don't get it... Seems v1.3.1 is out and it's not the same version as WAI has inside the package. What does it mean?
A: mr. no_name
Well, it's just a little improvement. Couple days ago several people made a fix for "mission overlapping". We decided to stick with our approach.
If you update to v1.3.1, you will get 2 new options in your 'customsettings.sqf' file (see bellow + detailed info in 'customsettings.sqf'_).
Now, what is important:
'iben_wai_ACcoordProtectorTimer' gvar means:
"If you give me any value > 0 in seconds, I'm gonna protect your just finished mission area against new mission spawn for given time."
Protection is processed only if:
valid spot for new mission was already found;
there is at least 1 item in 'iben_wai_ACprotectedCoord' array
(that means, at least one mission was completed and coordinates has to be protected agains new mission spawn).
If you decide to update and you don't want use this fix, just set 'iben_wai_ACcoordProtectorTimer' value to 0.
Default position fnc will be used with default WAI fix (note: if you've already updated your WAI core files).
iben_wai_ACcoordProtectorTimer = 300; // @since v1.3
if (iben_wai_ACdevmode) then {
iben_waiACfindPosLimiter = 999; // @since v1.3
};
// :: If iben_wai_ACcoordProtectorTimer > 0 && iben_wai_ACdevmode is true,
// :: you will see in your server RPT somenthing like that:
// 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [find_position.sqf] >> 'iben_wai_ACcoordProtectorTimer' active (300s) >> Initialising custom position FNC for mission coord protection..."
// 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [IBEN_fnc_AC.sqf] >> Currently protected missions coordinates (iben_wai_ACprotectedCoord) >> [[561.226,[12890.3,11228.4,0.0142517],"MainHero1"]]"
// 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [find_position.sqf] >> Spot found. Checking if spot is in protected coordinates >> iben_wai_ACprotectedCoord >> [[561.226,[12890.3,11228.4,0.0142517],"MainHero1"]]"
// 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [find_position.sqf] >> Loop complete valid position >> [6129.23,8784.35,0] >> in 1/999 attempts"
---
The end.
===
Showcase:
===
IWAC - private server msgs, map markers, status, respawn:
===
===
IWAC - multiple claiming protection, exclude plotpole area option:
===
===
That's all I've got... enjoy, have fun...
Cheers...
===
Wicked AI 2.2.3
This release is updated for DayZ Epoch/Overpoch 1.0.6.2.
>>>Download Here<<<
The install instructions are in the github readme file for each version.
Updates for DayZ Epoch 1.0.6.2 (Release 2.2.3)
Streatman's new attachment system L85 and SVD models.
Optional dynamic text mission announcements.
ZSC compatible remote message system using a modified version of Salival's remote_message.sqf
iBen's mission auto claim addon.
Two new options for mission vehicle keys: key in crate & key in vehicle gear.
Minor bug fixes with missions.
Updates for DayZ Epoch1.0.6.1 (Release 2.2.2)
Integrated Caveman's mission pack.
Optional AI counter in mission marker loops.
ZSC check wallet option.
Optional mission static spawn points.
Updated with 1.0.6+ classnames in weapon arrays and vehicles.
Pistol spawning in crates.
Credits
@f3cuk - WAI version 2.2.0
@ebayShopper - 1.0.6+ updates (release 2.2.1), right click solution for ItemRadio, mod detection method.
@Caveman - extended mission pack
@salival - ZSC remote messaging (for dynamic text option), many additional fixes - too numerous to list
@Zupa - ZSC check wallet
@theduke - testing and class name updates
@DAmNRelentless - additional configurable variable and check for ZSC option, dynamic text coding examples
@iben Auto-claim addon
@BigEgg Vehicle key in crate solution
For complete instructions on how to use iben's autoclaim addon see the following topic
Call it land,sqf or bridges.sqf, or whatever you want and call it from init.sqf.
These are 3 bridges.
1. From Homburg to the big island west.
2. From the big island to the small island down south
3. From these small island to Berner Platte,
You're welcome!
BTW, I personally do not like the editor. Too inaccurate, too cumbersome and insecure. I'd rather reckon a little.
at the bottom of serverfunctions.sqf or in a seperate file called from serverfunctions.sqf you put this:
fnc_bridgeA2 = {
private ["_start","_obj"];
_start = createVehicle [_this select 2,_this select 0,[],0,"CAN_COLLIDE"];
_start setVectorUp [0,0,1];
_start setDir (_this select 1);
_start setPosATL (_this select 0);
for "_i" from 1 to (_this select 3) do {
_obj = createVehicle [_this select 2,_this select 0,[],0,"CAN_COLLIDE"];
_obj attachTo [_start, [_i*(_this select 4),_i*(_this select 5),_i*(_this select 6)]];
};
};
//examples of use:
//first (array) is the coords, second (number) is the direction, third (classnames) is the object you want to use,
//fourth (number) is the count (how many objects), last three (numbers) is the offset.
//[[7688.9277, 5936.1899, 1.23430218], 87.44249,"MAP_Bridge_wood_25",4,17,0,0] call fnc_bridgeA2;
//[[13640.5,3862.64,-1], 105,"Land_nav_pier_m_2",17,40,0,0] call fnc_bridgeA2;
//[[4638.26,2564.16,0.00143909],120,"MAP_runway_main_40",17,0,40,0] call fnc_bridgeA2;
//[[4649.19,2515.24,0.00143909],120,"MAP_runway_poj_draha",16,0,40,0] call fnc_bridgeA2;
//[[11812.4,12838.6,0.00143433],110,"MAP_runway_main_40",18,0,40,0] call fnc_bridgeA2;
//[[11814.2,12799.4,0.00143433],110,"MAP_runway_poj_draha",17,0,40,0] call fnc_bridgeA2;
//[[12938.8,3690.2,0.00156188],120,"Land_Ind_Expedice_2",16,3.5,30.65,0] call fnc_bridgeA2;
this creates a bridge at a defined spawnpoint and can be made as long as you want it to be.
mmm
maybe:
_hastools = ["ItemKnife"] call player_hasTools;
_hasitems1 = ["ItemAntibiotic"] call player_checkItems;
_hasitems2 = ["ItemAntibacterialWipe"] call player_checkItems;
if (call {_hastools} && {_hasitems1} && {_hasitems2}) then {};
or:
_hastools = ["ItemKnife"] call player_hasTools;
_hasitems1 = ["ItemAntibiotic","ItemAntibacterialWipe"] call player_checkItems;
if (call {_hastools} && {_hasitems1} ) then {};
or:
_inventory = items player;
_hastools = "ItemKnife" in _inventory;
or:
if (("ItemAntibiotic" in magazines player) && ("ItemAntibacterialWipe" in magazines player)) then{};
or if u need check current weapons and items:
_Gun = currentWeapon player;
if ((_Gun in ["revolver_EP1","revolver_gold_EP1"]) && ("ItemAntibiotic" in magazines player) && ("ItemAntibacterialWipe" in magazines player))then{};
Or you can use negatives.. to exit from the script early:
if !(("ItemAntibiotic" in magazines player) && ("ItemAntibacterialWipe" in magazines player)) exitWith{};
_inventory = items player;
_hastools = "ItemKnife" in _inventory;
if (!_hastools) exitWith{};
and that is all i know about it.. maybe thers others ways.
@gernika do you say something like...
///structure//
_VariableName = [["Item ID",Amount],["Item ID",amount]] call player_removeItems;
/////////////
_remove= [["CinderBlocks",2],["ItemBloodbag",3]] call player_removeItems;
and if u need check if players have this items:
_hasitem = [["CinderBlocks",2], ["ItemBloodbag",3]] call player_checkItems;
Yup u can add any kind of flying veh since the line about obj monitor was added.
dayz_serverObjectMonitor set [count dayz_serverObjectMonitor,_aircraft];
This prevent the veh sched destroy your veh cuz is not signed . I say flying veh cuz cannot imagine landveh in this script. Explain it before cleandirella comes to say me you can add anykind of veh.
gernika got a reaction from chi in Zombies After Dark
gernika got a reaction from JohnnyBravo666 in Death messages script? 1.0.6.1?
gernika got a reaction from Cherdenko in [Release] Paycheck/Loyality Reward