diff --git a/documentation/development/ace3-config-entries.md b/documentation/development/ace3-config-entries.md
new file mode 100644
index 0000000000..f56285052d
--- /dev/null
+++ b/documentation/development/ace3-config-entries.md
@@ -0,0 +1,98 @@
+---
+layout: wiki
+title: ACE3 Config Entries
+group: dev
+parent: wiki
+order: 2
+---
+
+### CfgVehicles
+
+```c++
+ace_nightvision_grain
+ace_nightvision_blur
+ace_recoil_enablecamshake
+ace_dragging_cancarry
+ace_dragging_carryposition
+ace_dragging_carrydirection
+ace_dragging_candrag
+ace_dragging_dragposition
+ace_dragging_dragdirection
+ace_gforcecoef
+ace_offset
+```
+
+
+### CfgWeapons
+
+```c++
+ace_recoil_shakemultiplier
+ace_overpressure_angle
+ace_overpressure_range
+ace_overpressure_damage
+ace_overheating_dispersion
+ace_overheating_slowdownfactor
+ace_overheating_jamchance
+ace_nightvision_grain
+ace_nightvision_blur
+ace_nightvision_radblur
+ace_usedtube
+ace_reloadlaunchers_enabled
+ace_bipod
+ace_overheating_allowswapbarrel
+ace_clearjamaction
+ace_checktemperatureaction
+ace_gforcecoef
+ace_protection
+ace_scopeadjust_horizontal
+ace_scopeadjust_vertical
+ace_isusedlauncher
+ace_attachable
+ace_range
+ace_detonator
+```
+
+
+### CfgAmmo
+
+```c++
+ace_bulletmass
+ace_recoil_shakemultiplier
+ace_frag_skip
+ace_frag_force
+ace_frag_classes
+ace_frag_metal
+ace_frag_charge
+ace_frag_gurney_c
+ace_frag_gurney_k
+ace_explodeondefuse
+ace_explosive
+ace_fcs_airburst
+```
+
+
+### CfgGlasses
+
+```c++
+ace_color
+ace_tintamount
+ace_overlay
+ace_overlaydirt
+ace_overlaycracked
+ace_resistance
+ace_protection
+ace_dustpath
+```
+
+
+### CfgMagazines
+
+```c++
+ace_isbelt
+ace_attachable
+ace_placeable
+ace_setupobject
+ace_delaytime
+ace_triggers
+ace_magazines_forcemagazinemuzzlevelocity
+```
diff --git a/documentation/development/ace3-events-system.md b/documentation/development/ace3-events-system.md
new file mode 100644
index 0000000000..9075347f71
--- /dev/null
+++ b/documentation/development/ace3-events-system.md
@@ -0,0 +1,171 @@
+---
+layout: wiki
+title: ACE3 Events System
+group: dev
+parent: wiki
+order: 3
+---
+
+## Event Handlers
+
+Event handlers in ACE3 are implemented through our event system. They should be used to trigger or allow triggering of specific functionality.
+
+The commands are listed below.
+
+* `[eventName, eventCodeBlock] call ace_common_fnc_addEventHandler` adds an event handler with the event name and returns the event handler id.
+* `[eventName, args] call ace_common_fnc_globalEvent` calls an event with the listed args on all machines, the local machine, and the server.
+* `[eventName, args] call ace_common_fnc_serverEvent` calls an event just on the server computer (dedicated or self-hosted).
+* `[eventName, targetObject(s), args] call ace_common_fnc_targetEvent` calls an event just on the targeted object or list of objects.
+* `[eventName, args] call ace_common_fnc_localEvent` calls an event just on the local machine, useful for inter-module events.
+
+Events can be removed or cleared with the following commands.
+
+* `[eventName, eventHandlerId] call ace_common_fnc_removeEventHandler` will remove a specific event handler of the event name, using the ID returned from `ace_common_fnc_addEventHandler`.
+* `[eventName] call ace_common_fnc_removeAllEventHandlers` will remove all event handlers for that type of event.
+
+### Pattern:
+```c++
+// tapper machine
+["tapShoulder", [_target], [otherArguments]] call EFUNC(common,targetEvent);
+
+// target machine XEH_preInit.sqf
+PREP(onTapShoulder);
+["tapShoulder", FUNC(onTapShoulder) ] call EFUNC(common,addEventHandler);
+```
+
+### Listenable Event List:
+
+
+
+
Event Key
+
Description
+
Source(s)
+
Locality
+
+
+
+
+
"playerChanged"
+
`player` changed (zeus/respawn)
+
common
+
local
+
+
+
+
"playerInventoryChanged"
+
Inventory changed
+
common
+
local
+
+
+
+
"playerVisionModeChanged"
+
Vision mode changed (e.g. NVG on)
+
common
+
local
+
+
+
+
"zeusDisplayChanged"
+
Zeus display opened/closed
+
common
+
local
+
+
+
+
"cameraViewChanged"
+
Camera view changed
+
common
+
local
+
+
+
"playerVehicleChanged"
+
Player vehicle changed
+
common
+
local
+
+
+
"playerTurretChanged"
+
Player turret changed
+
common
+
local
+
+
+
"infoDisplayChanged"
+
On info box change (e.g. entering and leaving a vehicle)
+
common
+
local
+
+
+
"inventoryDisplayLoaded"
+
On opening the inventory display
+
common
+
local
+
+
+
"interactionMenuOpened"
+
Interaction Menu Opened
+
interaction
+
local
+
+
+
"killedByFriendly"
+
On TK/Civilian Killed
+
respawn
+
local
+
+
+
"drawing_requestMarkers"
+
Request Drawing Markers
+
map
+
target
+
+
+
"drawing_sendbackMarkers"
+
Send Drawing Markers
+
map
+
target
+
+
+
"drawing_addLineMarker"
+
Line Drawn
+
map
+
global
+
+
+
"drawing_removeLineMarker"
+
Line Deleted
+
map
+
global
+
+
+
"flashbangExplosion"
+
Flashbang Goes Bang
+
grenades
+
target
+
+
+
+
+### Callable Event List:
+
+
+
+
Event Key
+
Description
+
Parameters
+
Owner
+
Locality
+
+
+
+
+
"ace_fcs_forceChange"
+
force FCS updates
+
fcs
+
fcs
+
local
+
+
+
+
diff --git a/documentation/development/arma-3-issues.md b/documentation/development/arma-3-issues.md
new file mode 100644
index 0000000000..b6ef063cbc
--- /dev/null
+++ b/documentation/development/arma-3-issues.md
@@ -0,0 +1,25 @@
+---
+layout: wiki
+title: Arma 3 Issues
+group: dev
+parent: wiki
+order: 6
+---
+
+
+Keeping track of Arma 3 issues that need to be fixed. If you want to support us and help raise Bohemia's awareness of those issues, please upvote them:
+
+**Open:**
+
+* [bux578: 0020997: MineDetector equipable in Launcher slot](http://feedback.arma3.com/view.php?id=20997)
+* [bux578: 0021176: Zeus / Curator Add Remote Controlled Event](http://feedback.arma3.com/view.php?id=21176)
+* [bux578: 0021469: Add script commands "addPrimaryWeaponMagazine" and "addSecondaryWeaponMagazine"](http://feedback.arma3.com/view.php?id=21469)
+* [bux578: 0022000: Add/Alter script command to add perfectly configured weapons to cargo](http://feedback.arma3.com/view.php?id=22000)
+* [commy2: 0021443: Unexpected behavior of += array in configs](http://feedback.arma3.com/view.php?id=21443)
+* [commy2: 0022671: setVariable is not always JIP persistent](http://feedback.arma3.com/view.php?id=22671)
+* [CorruptedHeart: 0022318: Can no longer use "MenuBack" shortcut in AddAction](http://feedback.arma3.com/view.php?id=22318)
+
+**Resolved:**
+
+* [Nou: 0020761: Memory points rfemur, lfemur, and other leg memory points returned incorrectly with SQF command selectionPosition](http://feedback.arma3.com/view.php?id=20761)
+* [commy2: 0023136: isLightOn doesn't recognize destroyed light bulbs for streetlamps](http://feedback.arma3.com/view.php?id=23136)
diff --git a/documentation/development/arma-3-scheduler-and-our-practices.md b/documentation/development/arma-3-scheduler-and-our-practices.md
new file mode 100644
index 0000000000..90646b3b4a
--- /dev/null
+++ b/documentation/development/arma-3-scheduler-and-our-practices.md
@@ -0,0 +1,94 @@
+---
+layout: wiki
+title: Arma 3 Scheduler And Our Practices
+group: dev
+parent: wiki
+order: 8
+---
+
+## Terminology
+
+#### Frame
+A single rendered frame of Arma 3.
+
+#### Scheduled Space
+
+This refers to execution would is ruled by the Arma 3 default script scheduling engine. This would include:
+* spawn
+* execVM
+
+#### Unscheduled Space
+This refers to execution which is linear; what this means is that the code will run to completion prior to executing the current frame. It must complete, but is guaranteed to run within a given frame.
+* perFrameHandler
+* Extended_EventHandlers
+* addEventHandler
+
+
+## What is the scheduler and why do I care?
+
+BIKI Article: https://community.bistudio.com/wiki/Biki2.0:Performance_Considerations
+
+The Arma 3 script scheduler basically gives a fair-share execution to all running scripts, FSMs, and SQS files running on any given client or server at any given time. See the BIKI article for a in-depth explanation of this. What this basically means though, is that all scripts get a fair share; this also means scheduled execution is drastically affected by other poorly written mods. For example, if 2 different spawn's are running in a tight loop of `do { foo } while (true);`, they will both get exactly 50% of the scheduling time.
+
+With the way mission makers and mod makers generally use spawn/execVM, this means you're actually getting drastically less execution time in the scheduled environment than you might think. This leads to visible delay issues all the way up to massive delay on execution. You can easily test and prove this by looping spawns and watching the execution times extend.
+
+What does this all mean? It means we need to live outside of the spawn execution as much as possible. There are 2 places that the majority of our functionality should stem from, which means that as long as we strictly always perform calls between functions, we are executing within the same frame. If our execution is either stemming from the perFrameHandlers, or any default Extended_EventHandlers, than we can guarantee execution within a single frame. *ANY OTHER CIRCUMSTANCE IS NOT GUARANTEED.*
+
+The scheduler will also actually halt your script mid-execution, usually at the end of a given control block, and pause you to yield to other scripts. This can lead to drastically incorrect results when performing calculations. Again, this is the reason we want all our given code to run to completion in a single given frame.
+
+## Design Patterns
+
+Because we are attempting to always run to completion; execution occurs from 2 places. Either PFH handles or event handlers; in both cases, we wish our code to run to completion. This takes a change in mind set for design to ensure your executing that way. In a nutshell though, this all distills down to the fact that you will always call other chunks of code; nothing will ever be spawned off. The only circumstance this really becomes a problem is for waiting or delay. If designed correctly, though, you can avoid those circumstances.
+
+Rules of thumb for component design:
+
+* If you need to wait for a value, don't wait, use a CBA event! This means everything should be designed and written with an event-driven model in mind.
+
+* If you have to wait, use a PFH delay/diag_tickTime check.
+
+
+### PFH-Design Pattern
+
+Line Notes:
+
+* PerFrameHandlers should be self-removing. If a PFH is no longer needed, it is responsible for removing itself.
+
+
+
+### ACE3 General Rules
+
+* Always use call whenever possible. We should be calling functions chains exclusive and not be relying on spawn/execVM ever. Consider spawn/execVM banned without good reason. All code should be a chain of execution which is traceable, and not triggered between seperate threads.
+* waitUntil and sleep are banned. If you need to use them, use scheduled delay execution instead. **Reasoning** *Sleep/waituntil surrender about 5x the scheduler time than even normal execution does. *
+* If we need a spawn or exec, we should utilize the perFrame scheduler. Spawn/execVM are subject to the Arma 3 scheduler and as such, cannot be relied upon. In order to give our players a consistent gameplay experience, we need to have total control over how and when all of our code runs.
+* PFH should be utilized at all possible times when the player can see the result of whatever the code is. This applies to missile guidance, bullets, wind, optics, interactive UI, HUD's, and rendering. We should only consider scheduled execution if the code is running out of the visual range of the player.
+
+
+### Code Examples
+
+##### Generic PFH functions
+See: https://dev.withsix.com/docs/cba/files/common/fnc_addPerFrameHandler-sqf.html for more details.
+
+```c++
+[{ code } , delayTime, [ARGS] ] call CBA_fnc_addPerFrameHandler;
+```
+
+
+##### PFH Wait
+
+```c++
+DFUNC(myDelayedFunction) = {
+ // Our argument array is passed in a PFH as select 0
+ _args = _this select 0;
+
+ // Print our arguments
+ diag_log text format["I received: %1", (_args select 0)];
+
+ // Delete this PFH, so it is only executed once
+ [_this select 1] call CBA_fnc_removePerFrameHandler;
+};
+
+// This runs the PFH once every 5 seconds, with the variable array ["balls"] being passed in
+// This executes FUNC(myDelayedFunction), that could also be a { code } block.
+// Parameter 2 is the delay (in seconds) for a PFH. This is "execute every N seconds", 0 will be every frame.
+[FUNC(myDelayedFunction), 5, ["balls"] ] call CBA_fnc_addPerFrameHandler;
+```
diff --git a/documentation/development/coding-guidelines.md b/documentation/development/coding-guidelines.md
new file mode 100644
index 0000000000..c3517dec1d
--- /dev/null
+++ b/documentation/development/coding-guidelines.md
@@ -0,0 +1,274 @@
+---
+layout: wiki
+title: Coding Guidelines
+group: dev
+parent: wiki
+order: 1
+---
+
+## Table Of Contents
+
+- [Indentation](#indentation)
+- [Braces](#braces)
+- [Modules](#how-to-create-a-new-module)
+- [Macros](#macro-usage)
+- [Events](#event-handlers)
+- [Hashes](#hashes)
+
+
+## Indentation
+
+4 spaces for indentation.
+
+```c++
+class Something: Or {
+....class Other {
+........foo = "bar";
+....};
+};
+```
+
+#### Reasoning
+
+Tabs can be tricky sometimes, especially when it comes to sharing code with others. Additionally, a lot of people tend to forget they're using tabs when they're aligning things after the first character, which causes things to fall apart when viewing the code at different tab lengths.
+
+
+## Braces
+
+- opening bracket on the same line as keyword
+- closing bracket in own line, same level of indentation as keyword
+
+**Yes:**
+
+```c++
+class Something: Or {
+ class Other {
+ foo = "bar";
+ };
+};
+```
+
+**No:**
+
+```c++
+class Something : Or
+{
+ class Other
+ {
+ foo = "bar";
+ };
+};
+```
+
+**Also no:**
+
+```c++
+class Something : Or {
+ class Other {
+ foo = "bar";
+ };
+ };
+```
+
+When using `if`/`else`, it is encouraged to put `else` on the same line as the closing bracket to save space:
+
+```c++
+if (alive player) then {
+ player setDamage 1;
+} else {
+ hint ":(";
+};
+```
+
+In cases where you , e.g, have a lot of one-liner classes, it is allowed to use something like this to save space:
+
+```c++
+class One {foo = 1;};
+class Two {foo = 2;};
+class Three {foo = 3;};
+```
+
+#### Reasoning
+
+Putting the opening bracket in it's own line wastes a lot of space, and keeping the closing bracket on the same level as the keyword makes it easier to recognize what exactly the bracket closes.
+
+
+## How to create a new module
+
+1. Copy the structure from `extras\blank` to the `addons\` folder and name it what you wish the new module to be named.
+1. Edit `script_component.hpp`, change the `COMPONENT` definition to the name of the module. Also edit each of the `DEBUG` definitions to be the name of the module (for example, `DEBUG_SETTINGS_BLANK` should be `DEBUG_SETTINGS_BALLS` for module balls)
+1. Edit the `script_component.hpp` file in the the `functions` directory to match the path of the new module, for example `#include "\z\ace\addons\blank\script_component.hpp"` for module called balls should now be `#include "\z\ace\addons\ballls\script_component.hpp"`.
+1. The module is now prepared for development
+
+
+### Function Definitions
+
+Functions should be created in the functions\ subdirectory, named `fnc_FunctionName.sqf` They should then be indexed via the `PREP(FunctionName)` macro in the XEH_preInit.sqf file. The `PREP` macro allows for CBA function caching, which drastically speeds up load times. **Beware though that function caching is enabled by default and as such to disable it you need to `#define DISABLE_COMPILE_CACHE` above your `#include "script_components.hpp"` include!**
+
+Every function should have a header of the following format:
+
+```cpp
+/*
+ * Author: [Name of Author(s)]
+ * [Description]
+ *
+ * Arguments:
+ * 0: The first argument
+ * 1: The second argument