hambeast

We are not making it GSP exclusive and anyone with a dedicated server will be able to apply to host a server after we reach 0.5. GSP customers will have limited access to files at first as we will not be able to make everyone of their customers agree to our terms.

All should be the same. BE will be discontinuing support/functionality on gamespy builds, steam builds will remain with active BE.
 
GUID/UID will remain the same. The only thing that will be different is steam ownership verification (the account must own the game to play it).

umm 103718 and 112555 are not compatible.  You can run the new patch on either though

We all know that feeling, you just got your server tweaked and optimized just how you like it and an Epoch update comes out!  OH NO! what do we do?  Wait for the mod authors to release their own patch?  Hell no!  We diffmerge!
 
If you followed my guide on how to override mod files, you may be asking "what happens if the files we overrode changed on an update?"  well the answer depends if it was changed.  Here is how you can locate all the changes if there are any and make the changes needed to keep your server running.
 
What you'll need: Diffmerge, A working copy of DayZEpoch Server, modifications
Difficulty: Advanced
 
 
Scenario 1: An epoch mod update came out and you being a good admin want to make sure there were no changes made to your reference file.
For this guide, we will assume you modified the variables.sqf by using my tutorial
 
Locate the files you have made changes to Locate the original file Diffmerge the two files and compare changes, merging where necessary Right click your original file and select "Diffmerge->Open With Diffmerge" Click "Browse" on the 2nd line referencing the "right" file.  Note diffmerge always goes from left to right.  Meaning the file you wish to change or update needs to be on the right hand side! Here's what the diffmerge window looks like, note the changes in red.  You can see where we added the new class reference.

 
If we click the down arrow (Next Change) we can scroll all the way to the right and see where we added our new skin
 

 
 
That's it.  Just take a look at all the changes and use your reasoning to determine if you need to make changes.
 
If you are being studious, you may have noticed a few more changes near the bottom of the file represented by the red "-" on the left.  Ignore these, normally you would only see the top two changes.

Issues with loot tables are caused by the changes to the format of the config entries. Changes were done (in DayZ CE) to A. reduce the amount of large arrays, C. make loot tables more readable.
 
The old format is
lootType[] = {"YourItem1", "YourItem2"}, {0.5,0.5}; 
 
New Format
lootType[] = {{"YourItem1",0.5},{"YourItem2",0.5}};  
Note that the array is not necessarily shorter, but it does consist of shorter arrays. I.e. in a large entry you will not have 2 200 element nested arrays, you will have 1 array consisting of 200 2 element nested arrays.
 
Yes, this is from a discussion in the DayZ CE Repo *it's a private repo). @dddlazer
http://pastebin.com/AWgv27iR
 
You cannot use the magical var _forEachIndex in count. And you cannot nest multiple counts.

Yes, allot has changed since 1.0.4.2 and we are not even finished with the 1.8 code merge. Any script that used the older loot table format will need to be updated.

They are different. Your cd key is written to the registry. Your GUID is your cd key ran through some crypto algorithm. That's why you can see people's GUID when they join some servers and see it on every server if they get battle eye disconnected for client not responding. I have never heard of anyone being able to reverse engineer the cd key from the GUID. 

We paid $0 to GP or any other gaming host for our origins server and we got to rank #3 worldwide and held it for quite some time.  Until they released an update to break all the "leaked servers" and then we went back to epoch but at that point there was not building system and it was really rough and laggy.  Went to overwatch for a bit and then switched to epoch when it was fleshed out a bit more.
 
glad to say epoch is the best mod I've played since we started.

It was always going to happen, I'm amazed BIS let it go on for so long.
 
KingCunt and his team made fortunes from his license deals with GSP's
They killed off the Taviana.com mod by letting Martin in their bed and giving him money, Hicks was refused permission to use the new updates of Taviana
They sent out false DMCA notices to Opendayz when they released a new version of Taviana, sending fake DMCA notices is actully illegal.
They had weapons and vehicles removed from Epoch, remember the 'Hello Kity' cars ? Vilas was sent round all Dayz mods and have them remove his mods, only Origins were allowed to use his mod, again money was exchanged.
BIS introduced the Dayz mod license share alike terms because of Origins, not because some server admins sell items to pay for server costs, KingCunt and GP made fortunes selling other peoples code, at one point there were 8,000 Origin servers, each one of them paying them a fee each month

It would also be an idea to mirror this over to the BIS community wiki, too. That deserves an upgrade in readability. Good work :)

Very eager to see what you post in security part, as it is first thing I usually think of whenever I do something (apart from performance).
Also - high five for the avatar, best series ever. Period.

It's not shit, it's chocolate, look!

did you try turning it off and on again?

Lesson 2: Handling JIP clients
 
What is JIP? JIP stands for "Join in Progress" aka players who join after the mission has already started.  
 
You know how to change a players skin by sending out public variables but how do you make sure every player who joins has their skin changed?
 
For this example, we will assume there is an event running and for some reason you want to make sure every player who joins the server knows the event is running and if the event is started, lets make sure they get their skin.
 
We will also be introducing the idea of server side and client side event handlers in this lesson.
 
Brief flow of events:
* Client connects
* Client asks server if event is running
* Server checks to see if event is running
* If event is running, server changes players skin
 
Server Side JIP Check and Validator:
This code will handle requests from the client.
// server side check, make sure only the server runs this code if (isDedicated) then { // DEBUG: Manually set our event to running... You would normally do this thru a menu etc. // note, that this variable is only set on the server itself, so the client has no idea of the value // if you wanted, you could pass this thru instead of a skin but that's out of the scope of this tutorial Server_Event = true; // expects: [player] // Handles our client JIP requests "PV_JIP_Event_Check" addPublicVariableEventHandler { private ["_packet","_player","_owner","_skinClassName"]; // deserialize our packet _packet = _this select 1; _player = _packet select 0; _owner = owner player; _skinClassName = "FR_GL"; // my personal skin // check to see if Server_Event has been set by an admin/script. if (!isNil "Server_Event") then { // validate Server_Event is true, if true, our even is running if (Server_Event) then { // our event is running, change skin of JIP player PV_ChangePlayerSkin = ["FR_GL"]; _owner publicVariableClient "PV_ChangePlayerSkin"; }; }; }; }; Client Side JIP Check:
This code will be fired off when the client finishes loading their mission.
// client side, JIP checker, this runs whenever the user loads their mission file if (!isDedicated) then { // call our JIP check to see if a mission is running PV_JIP_Event_Check = [player]; // only send the public variable to the server! publicVariableServer "PV_JIP_Event_Check"; }; Client Side Skin Changer:
A slightly modified version of the 1st lesson's skin changer PV handler.
// client side, Skin changer, this runs whenever our server sends the PV to the client. Modified to use less bandwidth // this line says ONLY run on the ClientSide. The server will see this and ignore it. This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then { // expects: [_skinClassName] "PV_ChangePlayerSkin" addPublicVariableEventHandler { private ["_packet", "_skinClassName", "_playerUID", "_characterID"]; // handle our packet. _this select 0 returns the PV name, _this select 1 returns our input packet _packet = _this select 1; // should contain [_skinClassName] _skinClassName = _packet select 0; // since we are only running this on the local client, we don't need the playeruid and characteruid passed // we can just grab them from the local player object _playerUID = getPlayerUID player; _characterID = player getVariable ["CharacterID","0"]; // set our player to the skin [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph; }; }; Place all of this code (in this order if you like) at the bottom of your init.sqf in the your mpmission.
 
Now when a player connects to your server, they will have their skin changed.   If you want to play around with this, You could add a custom menu in "fn_playerActions.sqf" that only admins see that sends a PV to the server to say set "Event_Status" to true of false.  However, this guide is quick and dirty so it will always set a player skin, since we declare "Event_Status" as true.

FYI, this guide is for advanced arma coders.  This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding.  You must also have an understanding of locality as in client vs server side.
 
A note on locality:  Your mpMissions folder is NOT only client side.  When I started coding I made this assumption and I was wrong.
 
 
Lesson 1:  Event Handlers Basics
 
Event handlers are the bread and butter of Arma2 MP coding.  They are little logic functions that the server sets aside until they are called by a public variable.  In my experience they have very low overhead so don't be afraid to make use of them.
 
example 1: Change players skin
Add this code to the bottom of your init.sqf (in your mpMission)
// expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide.  The server will see this and ignore it.  This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then {   "PV_ChangePlayerSkin" addPublicVariableEventHandler {     // handle our packet.  _this select 0 returns the PV name, _this select 1 returns our input packet    _packet = _this select 1;  // should contain [_playerUID, _characterID, _skinClassName]    _playerUID = _packet select 0;    _characterID = _packet select 1;    _skinClassName = _packet select 2;       // set our player to the skin    [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph;   }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler.  Here is how we send the command to all players.  This code can be called anywhere, on a client, or from the server itself.
 
example:
  PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName];   publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server?   We do this with publicVariableClient.  I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client  
Now when we send our public variable we only send it to the client we wish to.  There are a myriad of ways to get player objects loaded into memory but that will be covered later.

FYI, this guide is for advanced arma coders.  This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding.  You must also have an understanding of locality as in client vs server side.
 
A note on locality:  Your mpMissions folder is NOT only client side.  When I started coding I made this assumption and I was wrong.
 
 
Lesson 1:  Event Handlers Basics
 
Event handlers are the bread and butter of Arma2 MP coding.  They are little logic functions that the server sets aside until they are called by a public variable.  In my experience they have very low overhead so don't be afraid to make use of them.
 
example 1: Change players skin
Add this code to the bottom of your init.sqf (in your mpMission)
// expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide.  The server will see this and ignore it.  This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then {   "PV_ChangePlayerSkin" addPublicVariableEventHandler {     // handle our packet.  _this select 0 returns the PV name, _this select 1 returns our input packet    _packet = _this select 1;  // should contain [_playerUID, _characterID, _skinClassName]    _playerUID = _packet select 0;    _characterID = _packet select 1;    _skinClassName = _packet select 2;       // set our player to the skin    [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph;   }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler.  Here is how we send the command to all players.  This code can be called anywhere, on a client, or from the server itself.
 
example:
  PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName];   publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server?   We do this with publicVariableClient.  I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client  
Now when we send our public variable we only send it to the client we wish to.  There are a myriad of ways to get player objects loaded into memory but that will be covered later.

FYI, this guide is for advanced arma coders.  This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding.  You must also have an understanding of locality as in client vs server side.
 
A note on locality:  Your mpMissions folder is NOT only client side.  When I started coding I made this assumption and I was wrong.
 
 
Lesson 1:  Event Handlers Basics
 
Event handlers are the bread and butter of Arma2 MP coding.  They are little logic functions that the server sets aside until they are called by a public variable.  In my experience they have very low overhead so don't be afraid to make use of them.
 
example 1: Change players skin
Add this code to the bottom of your init.sqf (in your mpMission)
// expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide.  The server will see this and ignore it.  This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then {   "PV_ChangePlayerSkin" addPublicVariableEventHandler {     // handle our packet.  _this select 0 returns the PV name, _this select 1 returns our input packet    _packet = _this select 1;  // should contain [_playerUID, _characterID, _skinClassName]    _playerUID = _packet select 0;    _characterID = _packet select 1;    _skinClassName = _packet select 2;       // set our player to the skin    [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph;   }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler.  Here is how we send the command to all players.  This code can be called anywhere, on a client, or from the server itself.
 
example:
  PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName];   publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server?   We do this with publicVariableClient.  I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client  
Now when we send our public variable we only send it to the client we wish to.  There are a myriad of ways to get player objects loaded into memory but that will be covered later.

FYI, this guide is for advanced arma coders.  This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding.  You must also have an understanding of locality as in client vs server side.
 
A note on locality:  Your mpMissions folder is NOT only client side.  When I started coding I made this assumption and I was wrong.
 
 
Lesson 1:  Event Handlers Basics
 
Event handlers are the bread and butter of Arma2 MP coding.  They are little logic functions that the server sets aside until they are called by a public variable.  In my experience they have very low overhead so don't be afraid to make use of them.
 
example 1: Change players skin
Add this code to the bottom of your init.sqf (in your mpMission)
// expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide.  The server will see this and ignore it.  This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then {   "PV_ChangePlayerSkin" addPublicVariableEventHandler {     // handle our packet.  _this select 0 returns the PV name, _this select 1 returns our input packet    _packet = _this select 1;  // should contain [_playerUID, _characterID, _skinClassName]    _playerUID = _packet select 0;    _characterID = _packet select 1;    _skinClassName = _packet select 2;       // set our player to the skin    [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph;   }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler.  Here is how we send the command to all players.  This code can be called anywhere, on a client, or from the server itself.
 
example:
  PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName];   publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server?   We do this with publicVariableClient.  I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client  
Now when we send our public variable we only send it to the client we wish to.  There are a myriad of ways to get player objects loaded into memory but that will be covered later.

there's a kick and ban command built into the game engine.
 
However, I prefer the method with a bit more logging and its pretty easy.
 
just use public variables.  Example
 
[code]
// door unlock
_pos = position Player;
_name = name Player;
_doorCombo = 1234;
 
if (_unlockFailed) then {
 PV_BadKeyEntered = [_name,_doorCombo,_pos];
 publicVariable "PV_BadKeyEntered";
};
[/code]
 
Just make sure you put an entry in the publicVariables.txt for the pv so it kicks them.  It will log the time it happened, the name of the player, the door combo, and the pos.  You relly don't need to record the player name since the player will be passed to BattlEye anyways but this is just for an example.

there's a kick and ban command built into the game engine.
 
However, I prefer the method with a bit more logging and its pretty easy.
 
just use public variables.  Example
 
[code]
// door unlock
_pos = position Player;
_name = name Player;
_doorCombo = 1234;
 
if (_unlockFailed) then {
 PV_BadKeyEntered = [_name,_doorCombo,_pos];
 publicVariable "PV_BadKeyEntered";
};
[/code]
 
Just make sure you put an entry in the publicVariables.txt for the pv so it kicks them.  It will log the time it happened, the name of the player, the door combo, and the pos.  You relly don't need to record the player name since the player will be passed to BattlEye anyways but this is just for an example.

Having run a QA team for a while, I really do not want to be doing testing :D .  I will stick to mod writing for now but may jump in on any open beta.
 
Maybe you could outline what would be expected from a tester and an overview of the QA process.
 
Most do not realise the workflow involved in testing and it would be an interesting to some to understand the SDLC and methods you will be employing.
 
Without that info, this is just likely to grow in to an ever bigger me-too thread.

Hey AC!
 
I modified the script again. These changes will mostly be useful for militarized servers but I think they could be helpful for others as well.  Here are the changes:
 
* Re-arm pilot-gunner vehicles - Now you can re-arm helis and jets.
* Re-arm by ammo type - Now we get the option to re-arm a specific ammo type instead of the default (select 0)
* Block ammo types - Prevent certain ammo types from being re-armed (example is the 192 round s-5 rocket or the 1200 rnd 7.62)
* Block weapon types - Prevent certain weapons from being re-armed (want to block all guided missiles? No problem)
* Multiple magazines for ground units - Only ground units can reload multiple magazines, air units have default behavior
* added new function _fnc_getMagazines - Returns array of all magazines for selected turret
 
You can find the changes on my branch here: https://github.com/deadfred666/dayz/tree/master/service_point

What we are doing: Setting up an automated build process to compile the server and mission PBO on restart
Why: Ever needed to make changes to your server but had to wait for server restart?  Ever missed that window and had to wait another 3 - 4 hours till your next restart cycle? I hate that!
Requirements: PBOmanager, notepad++, firedaemon(optional) or knowledge of editing your batch scripts, a dev environemnt (you do have a dev environment don't you?), a dedicated server
Difficulty: Advanced
 
Ok guys, as stated before it is a huge pain in the ass to have to wait till your server goes down to push changes.  Why not automate it so that you can make your changes and be done with them?
 
So to start off you really should have a dev environment that mirrors your production environment.  I'm talking about a dev server here people.  Quick and dirty, just copy and paste your folder containing the Arma2OA install (you know the folder with @DayZ_Epoch_Server in it) to another directory.  Doesn't matter what the name is but you need to make changes here before you make them on your production server so you can verify that you didn't break anything.
 
 
Step 1: Install PBO manager if you have not.  you can get it here: http://www.armaholic.com/page.php?id=16369
Step 2: If you do not have unpacked folders of your PBO's living next to them in their proper directories, unpack your pbo's so that you have a folder with the same name in the same directory.  This is where you will make your changes.
Step 3: Create a batch script to run BEFORE your server starts.  This PBO will automatically pack up the folder into a PBO overwriting your old one.
 
Here is the content of my batch script "pbopack_dev.bat" (note that this is for the dev server, your path will not be the same"
 
 
"C:\Program Files\PBO Manager v.1.4 beta\PBOConsole.exe" -pack "D:\dayz\DEV_Epoch1\@DayZ_Epoch_Server\addons\dayz_server" "D:\dayz\DEV_Epoch1\@DayZ_Epoch_Server\addons\dayz_server.pbo" "C:\Program Files\PBO Manager v.1.4 beta\PBOConsole.exe" -pack "D:\dayz\DEV_Epoch1\MPMissions\DayZ_Epoch_11.Chernarus" "D:\dayz\DEV_Epoch1\MPMissions\DayZ_Epoch_11.Chernarus.pbo"  
 
Step 4: Integrate batch script into your current server restart method.  I use firedaemon, if you use a batch script, just make sure you run the previous batch before you start your server but after you have shut it down.  for firedaemon users, just add the batch script to the "pre-service programs".  Give it a nice 15 second timeout to ensure we didn't start the server too fast.
 
That's it.  Verify it works without breaking anything and you can implement this for your production servers.
 
 
Development and Deployment strategy:
 
Ok so I touched a little about this earlier but you MUST use a development environment.  Any programmer who has worked in a professional environment will know that you NEVER EVER EVER make changes to production code.  Firstly, its dangerous, secondly, it makes you look bad if you break a critical system because you were too lazy to test it properly.  Always make changes to your dev server first before you migrate those changes to the live prod environment!!!!!
 
Ideally,  you would want to have an exact mirror of your production server so that you can accurately verify your changes don't break something.
 
Here's how I do it.
 
Initial Setup:
1. Copy entire DayZ server directory to a new one (this only needs to be done once)
2. Backup your DayZ database and insert it as a new one (I use "DayzEpoch_DEV" for this)
3. Modify your hive.ini so it points to your dev database
4. Make changes on dev server and verify results.
 
After Setup:
1. Delete "@DayZ_Epoch_Server" and "mpmissions" directories from the DEV server folder.
2. Copy over "@DayZ_Epoch_Server" and "mpmissions" from your PROD server folder into the DEV server folder.
3. Make changes you need to the folders (no need to recompile as our script above does that for us)
4. Verify changes
 
Migrating changes from DEV to PROD on a Live server:
1. TEST YOUR CHANGES IN DEV
2. Navigate to your PROD server directory and delete the PBO's unpacked folders you wish to modify
3. Copy the unpacked folders from your DEV server to the PROD server
4. Wait for server restart to automatically recompile the folders into PBOs

I know what you mean. "Back to coding" is a godsent sometimes

guys, this issue is what causes so many problems in DayZ.  People want to play the game their way or not at all.
 
What you fail to realize is that those guys who shoot on sight or are "bandits" are playing the game the way they want to as well.
 
You shouldn't force your viewpoint on others just because you don't like the way they play the game.