On this page you can download the latest Version of the 'DCZ server side implementation'.
This “plugin” for DCS is needed to get the proper results out of a DCS Mission.
The results are written as a file which can be uploaded to DCZ to further progress in your DCZ game.

To install the 'DCZ server side implementation' simply unpack the following zip inside your DCS saved games folder.
For example into : C:\Users\yourWindowsName\Saved Games\DCS\
This would result into the following files and locations :
C:\Users\yourWindowsName\Saved Games\DCS\Scripts\DCZ.dll
C:\Users\yourWindowsName\Saved Games\DCS\Scripts\dkjson.lua
C:\Users\yourWindowsName\Saved Games\DCS\Scripts\Hooks\DCZGameGUI.lua

The following main features come with the server side implementation of DCZ :
- Special Slotblocking System
- Mission-End report (JSON) with several stateinformation of all partizipated units
- Specialised troop transporting system
- Counting system of troops for trigger zones
- Dynamic AI Aircraft activation system for client slot groups

To get the dll running during a DCS mission the loaded mission file must contain a trigger zone called 'DCZMission' (without the single quotes).

The radius of the trigger zone is used as a parameter to determine the length of the mission. For example if the 'DCZMission' trigger zone has a radius of 7200m the dll will forcibly end the mission after 7200 seconds mission time (which are 120 mins or 2 hours) and write the outcome file. After this the dll tries to load the next mission in the mission list of the server.

Shortly after the mission has started and the dll has been triggered by the proper trigger zone, DCZ.dll will scan the mission for all units. Every unit which is set to “client” will be treated by the dll in the following way.

If no one has entered the slot and the group belonging to the unit has not been send away as ai, there will be a static unit representation of that unit on the designated parking slot.
If the static unit representation gets destroyed the corresponding unit is no longer part of the game. Hence the slot for this unit get blocked for the rest of the mission.

Entering a slot of a unit will let the static representation dissapear. If a player doesnt get killed/destroyed but leaves a client-slot, the corresponding static representation of the unit will reappear. Should a player get killed/destroyed while having a client-slot occupied, the player gets reassigned to the observer position and the units slot will be blocked for the rest of the mission. The unit is lost.

Groups which consists of units were some are set to 'client' and others are not may result in unpredictable behaviour and is not supported by DCZ.dll.
The DCZ.dll behaviour for Units which have been set to 'client' but doesnt start as “from ramp cold” are unknown/untested.

A group of units which have been set to “client” in the mission editor can be send away as ai group. Through the f10 radio menu every player being part of a coalition can dynamically start the whole group as ai. The static representations of these units dissapear and ai units which immediatly start their mission will be spawned instead.
Every slot behind units of a group which has been activated as ai units will be blocked for the rest of the mission.
AI units which get destroyed will not respawn and the slot behind the unit keeps being blocked of course.

If either the time for this mission ends or both coalition have agreed to end the mission (through f10 radio menu) then the dll will generate an ending report in json ( https://en.wikipedia.org/wiki/JSON ) with the following structure : The root object consists of the properties 'events' , 'situation' and 'soldiersInZone'.

• 'events' is an array of objects which holds the basic events during the mission. (e.g. landing, starting, shot events, hit events, destruction events, etc.)
  
• 'situation' consists of 'transports' and 'units'.
  
  • 'transports' is a list of all groups which were capable of transporting soldiers. Every entry shows the soldiers which were transported at the end of the mission.
    
  • 'units' is a list of all units which participated during the mission. Every 'unit' entry consists of 'ammo', 'ammo2', 'fuelConsump', 'fuelRest', 'groupId', 'groupName', 'isAlive', 'name', 'sensors', 'sensors2', 'unitId', 'x', 'y'.
    
    • 'ammo' : Holds all the ammonition of the unit at the end of the mission.
      
    • 'ammo2' : Holds all the ammonition of the unit which were either fired or lost during the mission.
      
    • 'fuelConsump' :
      
      • For Aircrafts - Number represents 1/100 % of internal fuel consumed during the mission. e.g. 0.25 for MiG-21bis means that this unit had 0.25 * 2280 kg fuel = 570 kg fuel consumed during the mission.
        
      • For non-Aircrafts - Total driven distance in meters.
        
    • 'fuelRest' :
      
      • For Aircrafts - Number represents 1/100 % of internal fuel. e.g. 0.25 for MiG-21bis means that this unit had 0.25 * 2280 kg fuel = 570 kg fuel at the end of the mission.
        
      • For non-Aircrafts - Always 0.
        
    • 'groupId'
      
    • 'groupName'
      
    • 'isAlive' : Either 'dead' or 'alive' depending of if the unit was killed/destroyed during the mission.
      
    • 'name'
      
    • 'sensors' : All sensors the unit carried at the end of the mission.
      
    • 'sensors2' : All sensors which were lost during the mission.
      
    • 'unitId'
      
    • 'x' : Last known position x-component.
      
    • 'y' : Last known position x-component.
      
• 'soldiersInZone' : See 'Counting system'.
  

Every group consisting of units which can carry troops, as indicated underhttps:www.digitalconflictzones.net/wiki/doku.php?id=blue-tech or https://www.digitalconflictzones.net/wiki/doku.php?id=red-tech, can carry units of the type ===== Counting system ===== ===== Download =====