Clean

2025-08-15 10:37:49 +00:00 · 2018-10-20 12:42:00 +02:00 · 2018-10-20 12:42:00 +02:00 · b20fa48c68
commit b20fa48c68
921 changed files with 997850 additions and 0 deletions
--- a/.appveyor/appveyor.yml
+++ b/.appveyor/appveyor.yml
@ -0,0 +1,101 @@
+version: 2.4.a.{build}
+shallow_clone: false
+skip_branch_with_pr: false
+skip_commits:
+  message: /!nobuild/
+skip_tags: false
+
+
+environment:
+  access_token_documentation:
+    secure: JVBVVL8uJUcLXN+48eRdELEeCGOGCCaMzCqutsUqNuaZ/KblG5ZTt7+LV4UKv/0f
+  LUAROCKS_VER: 2.4.1
+  LUA_VER: 5.1.5
+  LUA: lua5.3
+  matrix:
+  - LUA_VER: 5.1.5
+
+platform:
+  - x64
+
+
+init:
+  - ps: if ($env:APPVEYOR_PULL_REQUEST_NUMBER -and $env:APPVEYOR_BUILD_NUMBER -ne ((Invoke-RestMethod `
+        https://ci.appveyor.com/api/projects/$env:APPVEYOR_ACCOUNT_NAME/$env:APPVEYOR_PROJECT_SLUG/history?recordsNumber=50).builds | `
+        Where-Object pullRequestId -eq $env:APPVEYOR_PULL_REQUEST_NUMBER)[0].buildNumber) { `
+        throw "There are newer queued builds for this pull request, failing early." }
+#  - ps: iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
+
+install:
+# Outcomment if lua environment invalidates and needs to be reinstalled, otherwise all will run from the cache.
+  - call choco install -y 7zip.commandline
+  - call choco install -y lua51
+  - call choco install -y luarocks
+  - call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
+  - cmd: PATH = %PATH%;C:\ProgramData\chocolatey\lib\luarocks\luarocks-2.4.4-win32\systree\bin
+  - cmd: set LUA_PATH = %LUA_PATH%;C:\ProgramData\chocolatey\lib\luarocks\luarocks-2.4.4-win32\systree\share\lua\5.1\?.lua;C:\ProgramData\chocolatey\lib\luarocks\luarocks-2.4.4-win32\systree\share\lua\5.1\?\init.lua
+  - cmd: set LUA_CPATH = %LUA_CPATH%;C:\ProgramData\chocolatey\lib\luarocks\luarocks-2.4.4-win32\systree\lib\lua\5.1\?.dll 
+  - call luarocks install luafilesystem 1.6.3-2
+#   - call luarocks install markdown 0.32-2
+  - call luarocks install metalua-compiler 0.7.3-1
+  - call luarocks install metalua-parser 0.7.3-2
+  - call luarocks install penlight 0.9.8-1
+  - call luarocks install checks
+
+
+cache:
+  - C:\ProgramData\chocolatey\lib
+  - C:\ProgramData\chocolatey\bin
+
+
+build_script:
+  - ps: | 
+      git checkout "$env:appveyor_repo_branch" 2>&1
+      git clone -q --depth=1 -b "$env:appveyor_repo_branch" https://github.com/FlightControl-Master/MOOSE.git c:\Projects\Moose 
+      git clone -q --depth=1 -b "W3" https://github.com/FlightControl-User/luadocumentor.git c:\Projects\luadocumentor
+      $env:LUA_PATH = "c:\Projects\luadocumentor\?.lua;C:\ProgramData\chocolatey\lib\luarocks\luarocks-2.4.4-win32\systree\share\lua\5.1\?.lua;C:\ProgramData\chocolatey\lib\luarocks\luarocks-2.4.4-win32\systree\share\lua\5.1\?\init.lua"
+      $env:LUA_CPATH = "C:\ProgramData\chocolatey\lib\luarocks\luarocks-2.4.4-win32\systree\lib\lua\5.1\?.dll"
+      dir c:\Projects
+      dir
+      echo "Removing old Documentation"
+      del Documentation\*
+      echo "Documenting"
+      lua5.1 c:\Projects\luadocumentor\luadocumentor.lua -d ./Documentation "c:/Projects/Moose/Moose Development/Moose"
+      echo "Updating Files"
+      cd .\Documentation
+      foreach( $file in Get-ChildItem . -Filter *.html ) 
+      { 
+        ( Get-Content $file ).replace( '<head>',  '<head><!-- Global site tag (gtag.js) - Google Analytics --><script async src="https://www.googletagmanager.com/gtag/js?id=UA-97385487-1"></script><script>window.dataLayer = window.dataLayer || [];function gtag(){dataLayer.push(arguments);}gtag(''js'', new Date());gtag(''config'', ''UA-97385487-1'');</script>' ) | Set-Content $file  
+      } 
+      cd ..
+      echo "Commit to GITHUB"
+      git config --global credential.helper store  
+      Add-Content "$env:USERPROFILE\.git-credentials" "https://$($env:access_token_documentation):x-oauth-basic@github.com`n" 
+      git config --global user.email "sven.van.de.velde@telenet.be" 
+      git config --global user.name "FlightControl-User" 
+      git add ./Documentation 2>&1
+      git commit -m "MOOSE generated documentation [skip ci]" 2>&1 
+      git push origin "$env:appveyor_repo_branch" 2>&1
+      dir
+  - ps: | 
+      if( $env:appveyor_repo_branch -eq 'develop' )     
+      {
+        $apiUrl = 'https://ci.appveyor.com/api'
+        $token = 'qts80b5kpq0ooj4x6vvw'
+        $headers = @{
+          "Authorization" = "Bearer $token"
+          "Content-type" = "application/json"
+          }
+        $RequestBody = @{ accountName = 'FlightControl-Master'; projectSlug = 'moose-docs-develop'; branch = 'master'; environmentVariables = @{} } | ConvertTo-Json
+        # get project with last build details
+        $project = Invoke-RestMethod -method Post -Uri "$apiUrl/builds" -Headers $headers -Body $RequestBody
+      }
+
+artifacts:
+#  - path: 'Documentation\**\*'
+#    name: Documentation
+
+on_finish:
+#  - ps: $blockRdp = $true; iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
+ 
+ 
--- a/.project
+++ b/.project
@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<projectDescription>
+	<name>MOOSE_DOCS</name>
+	<comment></comment>
+	<projects>
+	</projects>
+	<buildSpec>
+	</buildSpec>
+	<natures>
+	</natures>
+</projectDescription>
--- a/Beta_Test_Guide.md
+++ b/Beta_Test_Guide.md
@ -0,0 +1,146 @@
+
+
+You are interrested in **testing the bleeding edge functionalities** and features added by contributors every day, 
+and you are **not afraid of bugs** that will inevitably crop up from time to time ? Then this page is for you !  
+  
+You are going to learn :
+
+1. **Installation:** How to set up your development environment
+2. **Repository:** How is the Moose repository organized
+3. **Loading:** How Moose is loaded in the missions and how this can make your workflow more efficient
+4. How to use tools to process your .miz files efficiently
+5. How Moose's release cycle work
+6. How the Issue Tracker is managed
+
+This might be a bit daunting at first, but the rewards in term of simplified workflow and direct access to new features is well worth the effort! If you have any problem during the setup or at any other point, don't hesitate to ask the [community](Communities) for help!
+
+This guide assumes that **you already setup your development environment**, like a "normal" mission designer. Which means Lua Development Tools (LDT) is installed on your computer, and you already know how to create a mission using MOOSE. If it is not the case, please follow the instructions [here](http://flightcontrol-master.github.io/MOOSE/Usage_Guide.html) before proceeding.
+
+# 1) Installation
+
+## 1.1) Get your MOOSE repository installed on your PC and linked with GITHUB
+
+### 1.1.1) Install GITHUB desktop
+
+Install [GITHUB](https://desktop.github.com) desktop. 
+Since the MOOSE code is evolving very rapidely between Releases, we store the MOOSE code on GitHub, and we use the GitHUb to sync it between the remote repository (the "origin") and your local MOOSE repository. That way, only one click is needed to update to the latest version of GitHub.
+
+### 1.1.2) Link the MOOSE repository
+
+Link the MOOSE repository on GITHUB to your freshly installed GITHUB desktop. 
+This is done by browing to the [MOOSE repository at GITHUB](https://github.com/FlightControl-Master/MOOSE), and selecting the green button **Clone or Download** -> **Open in Desktop**.
+![](Installation/GitHub_Clone.jpg)
+
+Specify a local directory on your PC where you want to store the MOOSE repository contents.
+Sync the MOOSE repository to a defined local MOOSE directory on your PC using GITHUB desktop (press the sync button).
+You now have a copy of the code on computer, which you can update at any time by simply pressing the sync button.
+
+### 1.2) Install 7-Zip
+
+Install [7-Zip](http://www.7-zip.org/) if you don't already have it. It is a free and open source file archiver program. Since DCS' .miz files are simply renamed .zip files, 7-Zip is very usefull to manimulate them. We are providing the MOOSE testers and contributors with tools to batch process their .miz files, and they rely on 7-Zip. Keep the path to your 7-Zip installation handy, it will be use in the next step !
+  
+  
+  
+  
+# 2) Repository
+
+The MOOSE repository has a couple of folders, but the most important one is the **Moose Development** folder.  
+This directory contains an other folder called **Moose**. This is the most important folder, as this contains all the MOOSE source code!
+
+The other directories contained within the repository are for administration and automation of the deployment process.
+  
+  
+   
+# 3) Loading the repository within your missions.
+
+## 3.1) Static Loading
+
+**Moose Static Loading** is what the "normal" mission designer uses.  
+Simply put, you would include all the code of MOOSE by including **just one Moose.lua file**.  
+So by executing a DO SCRIPT FILE within your mission, you would load the complete MOOSE code within your mission.
+This process is very useful **when you are using a stable Release** of Moose which don't change often, 
+because it is really easy to set up for the mission designer.  
+It also allows him to **release missions** which are contained in their entirety in the .miz file.  
+But in a context in wich Moose changes often, static loading would require the generation of a new Moose.lua 
+**for every change within the MOOSE framework** and you would need to replace the old Moose.lua in the .miz file you are using to test the changes. 
+Add to this cumbersome process the fact that the Mission Editor doesn't like changes to the .miz file while it is open, 
+which means you would need to close and reopen the Mission Editor for every change, 
+and this process becomes unworkable for both the tester and the contributor.
+
+## 3.2) Dynamic Loading
+
+So, beyond the Static Loading, there is the Dynamic Loading, which allows a much more smooth proces while testing your missions.
+
+Enter **Moose Dynamic loading**. In this process, the **Moose.lua** you insert in your .miz file **looks for every .lua** 
+which constitute Moose in `DCSWorld\Scripts`, **and asks DCS to load them** during the mission startup.  
+This way, the latest changes to the MOOSE .lua files in `DCSWorld\Scripts` are automatically taken into account when you restart the mission, 
+no need to fiddle around with the .miz file or to close the mission editor!
+Now, there is still a problem left : you wouldn't want to have to copy the MOOSE .lua files from your local repository to `DCSWorld\Scripts`, 
+everytime you retrieve a new version of Moose. The solution to this problem is a dynamic link!  
+Simply put, it makes sure that the folder `DCSWorld\Scripts\Moose` is always in sync with your local MOOSE repository on your disk.  
+That way, **everytime you want to update to the next Moose, you simply sync your local repository** with the remote with GitHub, **and restart your mission** !
+Note that if you want to **release your missions to end users**, you will need to make it **use the static loading process**. There is a tool to automate this task, read below.
+
+# 4) Tools to help you manage your .miz files
+
+***TODO : Add a list of the .miz files tools a briefly explain their usages***
+
+# 5) The release cycle
+
+To ensure that the next Release of Moose is as bug-free and feature rich as possible, every Moose contributor respects a release cycle. 
+![](Installation/MOOSE_Release_Cycle.JPG)
+
+If you are not familiar with Git, this might be a bit criptic, but the idea behind it is simple : 
+
+* Most of the time, contributors write code, be it features or bug fixes, and the testers report bugs.
+* When a good amount of features are added to the last release, FlightControl decides to enter in a "Feature Freeze" period. **No new features are added** during this period (but they can still be worked on), and **every bug must be eliminated**. That is the period during which bug reports are paramount!
+* Now that this version of **Moose is stable**, we can release it for every mission designer, and go back to the start for the next cycle.
+
+
+# 6) The Issue Tracker
+
+## 6.1) How to report a bug ?
+
+If you **encounter** what seem to be a **bug**, which is bound to happen sooner or later since you are testing the brand new untested features of Moose, you will want to **report it** so that it can be solved by the contributors. We use the standard GitHub [Issue Tracker](https://github.com/FlightControl-Master/MOOSE/issues). Here is the process to create a new issue :
+
+* First, do a quick **search on the issue tracker** to see if someone hasn't already reported your issue. If it is the case, comment on this issue that you are able to reproduce it, and add the informations listed below.
+* **Create a new issue**.
+* **Add the information** listed below
+* Add the **lablel possible bug**
+* Thank you for helping us make Moose better!
+
+**_Informations we need to solve the issue_**
+
+* **A descriptive title**, not too long if possible. For exemple, `CTD when calling SPAWN:New()` is a good title. `I found a bug in MOOSE` is not.
+* Explain **what you are trying to do**, as well as **how you expect Moose to be behave**.
+* Which **version of Moose** and DCS World you are using. This can be found in `dcs.log`
+* Did the code you are using worked in previous version of either DCS World or Moose? Which one?
+* The **code** or portion of code **that triggered the problem**. Please put  **_\`\`\`lua_**  one line before your code, and  **_\`\`\`_**  at the end, to make your code readable.
+* The relevant part of **`dcs.log`**. Please put **_\`\`\`_** before and after your copy-pasted log to make it readable.
+
+![Example of a great bug report](Installation/GitHub_Issue_example.JPG)
+
+## 6.2) How to add a feature request ?
+
+* **A descriptive title**, not too long if possible.
+* Explain in detail **what you want Moose to do** in which circonstance.
+* If possible, add some pseudocode or a high level design implementation to better explain how your feature would work.
+* Add the **lablel enhancment**
+
+## 6.3) The life and death of an issue
+
+**_What is going to happen next to my issue?_**
+
+* A contributor will set some labels and a milestone to your issue, in order to classify it.
+* You might be asked to clarify some part of your issue, please answer as swiftly as possible.
+* You might be asked to sync your local repository and try again, if we think we fixed your issue. If we can confirm it to be fixed the issue is closed.
+
+**_Wait, my issue was closed, and it never got fixed ! / Nobody is paying attention to it !_** 
+
+This can happen for multiple reasons :
+
+* Your issue is a duplicate. (There is alredy a issue in our issue tracker for this)
+* Nobody was able to reproduce your bug, so we think it's a problem on your end
+* Your feature request asks for a feature that already exists
+* We think your feature request is a really good idea, but it's a huge time commitment. We therefore postponed it to the Realease after the next one, or to a later Release.
+* We are working hard and simply don't have the time. We will get around to check your issue, please be patient!
--- a/Communities.md
+++ b/Communities.md
@ -0,0 +1,40 @@
+# MOOSE framework support channels
+
+MOOSE is broadcasted, documented and supported through various social media channels.
+
+## 1. [MOOSE on YouTube](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg)
+
+MOOSE has a [broadcast channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg) on youtube. 
+These videos are grouped into playlists, which explain specific MOOSE capabilities, 
+and gradually build up the "understanding" and "what is possible" to do with the MOOSE framework.
+I really, really encourage all to watch the explanation videos.
+
+Some mandatory videos to watch are:
+
+  * [MOOSE Introduction](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl1JEtVcyf9sazUV5_fGICz4)
+
+  * [MOOSE Setup](https://www.youtube.com/watch?v=-Hxae3mTCE8&t=159s&index=1&list=PL7ZUrU4zZUl0riB9ULVh-bZvFlw1_Wym2)
+  * [MOOSE Spawning](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl1jirWIo4t4YxqN-HxjqRkL)
+  * [MOOSE Tasking](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl3CgxN2iAViiGLTPpQ-Ajdg)
+  * [MOOSE Task Dispatching](https://www.youtube.com/playlist?list=PL7ZUrU4zZUl3I6ieFM-cjey-rncF1ktNI)
+
+## 2. [MOOSE on Eagle Dynamics forums](https://forums.eagle.ru/showthread.php?t=138043)
+
+This is a default thread at the Eagle Dynamics forums where the MOOSE framework can be discussed and supported.
+The thread is called [MOOSE - Mission Object Oriented Scripting Framework](https://forums.eagle.ru/showthread.php?t=138043).
+
+## 3. MOOSE development on [GitHub](https://github.com/FlightControl-Master/MOOSE).
+
+I encourage that you create also a user at GitHub.
+On the GitHub site, you can register issues, feedback and comments in the issues section of the site.
+This allows to track this feedback and issues, in order to provide a structured support and create a milestone plan.
+In other words, treat this development as a project.
+
+## 4. [MOOSE community on Discord](https://discord.gg/yBPfxC6) 
+
+Join our MOOSE community on Discord. 
+A place where mission designers and developers come together to discuss the latest features.
+We are now with about 5 people supporting Mission Designers on Discord.
+
+There are currently more than 300 members on our discord MOOSE channel.
+
--- a/Communities/Slack.JPG
+++ b/Communities/Slack.JPG
--- a/Configuration/Donate.png
+++ b/Configuration/Donate.png
--- a/Configuration/Master.png
+++ b/Configuration/Master.png
--- a/Configuration/Site.png
+++ b/Configuration/Site.png
--- a/Contribution_Guide.md
+++ b/Contribution_Guide.md
@ -0,0 +1,190 @@
+*** UNDER CONSTRUCTION ***
+
+So, you are already familiarized with Lua and you think the best way to get the new feature you want fast is to program it yourself ? Or you feel like reporting bugs isn't enough, you want to fix them yourself ? Either way, you need some more information to contribute to Moose.
+
+This guide assumes that **you are already familiar with Moose** and that **you already set up your development environment**. If it is not the case, please go through the [Tester Guide](Beta_Test_Guide.html) before proceeding.
+
+In this document, we will review
+
+1. GitHub/Git organisation
+2. Contribution guidelines
+3. Coding standards
+4. The Luadoc
+5. Moose release cycle
+6. The Issue Tracker : labels and milestones
+
+# 1) GitHub/Git organisation
+
+You are assumed to be familar with at least the basics of GitHub (branches, commits, pull requests...). If it is not the case, please at least read [this tutorial](https://guides.github.com/introduction/flow/). If something isn't clear still, ask us, we'll be glad to explain!
+
+## 1.1) The Repositories
+
+Moose is in fact located on **three repositories** :
+
+* [**MOOSE**](https://github.com/FlightControl-Master/MOOSE) contains the Moose's **code**, the **documentation** and the file necessary to the **setup**
+* [**MOOSE_MISSIONS**](https://github.com/FlightControl-Master/MOOSE_MISSIONS) contains the **test missions**. Be aware that the [master-release branch](https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master-release) contains the statically loaded test missions, while the [master branch](https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master) contains their dynamically loaded counterparts. will want to create a local repository for this one and to sync it.
+* [**MOOSE_PRESENTATIONS**](https://github.com/FlightControl-Master/MOOSE_PRESENTATIONS) contains bits and bob related to Moose, like Moose's logos and PowerPoint files to present a specific feature of Moose.
+
+## 1.2) Branches
+
+On the [MOOSE](https://github.com/FlightControl-Master/MOOSE) repository, three branches are protected, which means that you cannot merge or commit directly to them, you need to create a pull request;
+
+* [master](https://github.com/FlightControl-Master/MOOSE/tree/master) stores Moose's current latest semi-stable code.
+* master-release stores Mosse's last release code. There is no reason you would want to modify this branch.
+* [master-backup](https://github.com/FlightControl-Master/MOOSE/tree/master-backup). We sometime backup the master into master-backup, in case the worst happen. There is no reason you would want to modify this branch.
+
+You are encourgaed to **create your own branch, named after you pseudonyme**, to test stuff and do some small-scale bugfixes. When you want to work on bigger features, you should **create a new branch named after the feature** you are working on. Don't forget to delete it when the feature is merged with master!
+
+## 1.3) Commits
+
+The usual [Git commit](https://chris.beams.io/posts/git-commit/) guidelines apply. Don't overthink it though, time is better spent coding or managing the Issue Tracker than writing long-form commit descriptions.
+
+## 1.4) Merge/Pull Requests
+
+When the code you are working on is finished, you will want to **resolve the merge conflicts** between your branch and master, and then **create a pull request**. Explain clearly what your code does (with a link to the relevant issue). If it meets the requirements below, it will be approved ASAP by FlightControl.
+
+# 2) Contribution guidelines
+
+We try to **follow a contribution process**, to make sure we work efficiently together. It isn't set in stone, but it gives an idea of what should be done. We wouldn't want two contributors both working on the same issue at the same time, would we ? This process is more geared towards the implementation of new features, the process for bug fixes is more flexible and several steps can be overlooked.
+
+1. Think about **what you are trying to achieve.** Writing some pseudocode is a great way to undersatnd the challenges you are going to face.
+2. **Discuss your idea** with the community **on Slack**. Maybe there is a way to do it you didn't even think about, or maybe you could team up with someone who is already working on it!
+3. Create a **high level design document**. It doesn't need to be thorough, but you need to have an idea of which class do you want to write, which class they should inherit from, which methods are needed in each class...
+4. Write an **issue on GitHub** with your high level design document, apply the label "enhancement" to it, and assign it to yourself.
+5. Create a **new branch** named after the feature **on MOOSE's repository** to work on (you will be given contributor access).
+6. **Write your code** in this branch, following the Coding Standards. **Sync** fairly regularly **this branch with master**, so that you don't have tons of merge conflicts at the end.
+7. When done, **write a/some test mission(s)** to showcase how to use your feature to the community.
+8. **Generate the Luadoc**.
+9. **Relsove merge conflicts** with master and **create a new pull request**.
+10. **Delete your branch** if you are not going to use it again.
+
+# 3) Coding Standards
+
+To ensure a good degree of **consistency** in Moose's code, we follow the following standards :
+
+* The code need to be **intellisense/Luadoc compatible**. See below for more information
+* The code needs to be **commented**. Remember : _“Programs must be written for people to read, and only incidentally for machines to execute.”_ - Hal Abelson. Keep in mind that you code will be red by non-programmers and beginners.
+* **Indentation** should be 2 spaces (default in LDT)
+* **Class names** should be in **capital letters** (e.g. `SPAWN`)
+* **Class should all inherit from `Core.Base#BASE`**
+* **Methods** should start by a **capital letter** (e.g. `GetName()`)
+* If your **method** is intended for **private use** only, its name should **start with an underscore** (e.g. `_GetLastIndex()`)
+* **Variables** should start with a **capital leter** (e.g. `IndexString`)
+* Provide a **trace** for the mission designer at the start of every method, and when it is appropriate. Trace functions are inherited from `BASE` :
+  * `F()`, `F2()` and `F3()` for function calls,
+  * `T()`, `T2()` and `T3()` for function logic, 
+  * `E()` for errors. 
+
+# 4) The Luadoc
+
+The **Luadoc system** is not only **useful for the contributor** to understand the code, but **also the mission designer**, as it used to automatically generate the [HTML documentation](http://flightcontrol-master.github.io/MOOSE/Documentation/index.html).
+It thus needs to follow some strict standards.
+Keep in mind the following informations :
+
+* Every Luadoc block needs to start with **three minus signs** (`---`).
+* The generated html file will use **Markdown**. If you are not familar with it, use this [reference](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
+* You can create **hyperlinks** by writing
+  * `@{Module#CLASS.Method}` for a method
+  * `@{Module#CLASS}` for a class
+  * `Module` can be ommited if the hyperlink points to the same module (e.g. `@{#CLASS`} is valid if CLASS is in the Module the link is in)
+* Luadoc **types the variables**. the following types are available
+  * `Folder.Module#CLASS` (a Moose class)
+  * `Dcs.DCSTypes#Class` (a DCS class)
+  * `#string`
+  * `#number` (integer or floating point)
+  * `#boolean`
+  * `#nil`
+
+## 4.1) Modules
+
+Every new file should contain at least one module, which is documented by a comment block. You can copy paste the following model and fill in the blanks :
+
+```lua
+--- **Name of the Module** - Short Description
+-- 
+-- ===
+-- 
+-- Long description. Explain the use cases.
+-- Remember that this section will be red by non programmers !
+-- 
+-- ===
+--
+-- ### Authors : Your name/pseudnyme
+--
+-- @module Module
+```
+
+## 4.2) Classes
+
+Every class should be documented by a comment block. You can copy paste the following model and fill in the blanks :
+
+```lua
+--- **Name of the CLASS** class, extends @{Module#CLASS}
+-- 
+-- Long description. Explain the use cases.
+-- Remember that this section will be red by non programmers !
+--
+-- @type CLASSNAME
+-- @field #type AttributeName (add a @field for each attribute)
+-- @extends Folder.Module#CLASS
+```
+
+## 4.3) Methods
+
+Every method should be documented by a comment block. You can copy paste the following model and fill in the blanks :
+
+```lua
+--- Description of the method
+-- @param #type (add a @param for each parameters, self included, even if it's implied)
+-- @return #type (add other @return fields if the method can return different variables)
+-- @usage (can be omitted if the usage is obvious)
+-- -- Explain how to use this method
+-- -- on multiple lines if you need it !
+```
+
+# 5) Moose release cycle
+To ensure that the next Release of Moose is as bug-free and feature rich as possible, every Moose contributor **respects a release cycle**. 
+![](Installation/MOOSE_Release_Cycle.JPG)
+
+The key takeways are:
+
+* During "normal" time, **write your features** and correct bugs **as you please**.
+* During "Feature Freeze", you can still work on your features, but you are **strongly encouraged to prioritize bug fixes**, especially if it involves your code. **No pull request for new features will be accepted during feature freeze !**
+* After the Release, it's back to the start for a new cycle.
+
+# 6) The Issue Tracker : labels and milestones
+
+## 6.1) Milestones
+
+You can see Milestone as the GitHub way to say Release. Moose repository has **three active [Milestone](https://github.com/FlightControl-Master/MOOSE/milestones) at any time** :
+
+* The next milestone (e.g. Moose-2.0)
+* The milestone after the next one (e.g. Moose-2.1)
+* The "future" milestone (Moose-Future)
+
+Every **bug is assigned to the next milestone**, and should be fixed before the release. **Features are assigned to any milestone depending on the importance** of it and how hard it is to implement. Typically, a feature that is currently worked on is assigned to the next milestone, an very long-term feature is assigned to Moose-Future, and any other feature is assigned to the milestone after the next one, the goal being to have a nice todo list for the contributor to pick and choose from at the end of feature freeze. If you come accross a issue that isn't assigned to a milestone, feel free to add it to the correct one !
+
+## 6.2) Labels
+
+We heavily use **GitHub's label system** on the Issue Tracker to categorize each issue. Each **issue is assigned the relevant label(s) at birth** by a contributor, and they are then updated to reflect the current state of the issue. If you come accross an untagged issue, feel free label it ! You can consult the [full list of labels available](https://github.com/FlightControl-Master/MOOSE/labels), but **please asks the community before adding or removing a label** to the list.
+
+* Bugs
+  * question : not even a bug report
+  * possible bug : might be a bug, but hasn't been reproduced yet
+  * bug : the bug has been confirmed / reproduced
+  * fixed : We think the bug is fixed. but there is a good reson why we are not closing the issue just yet. Usually used in conjunction with ready for testing
+* Feature requests
+  * enhancement : this issue is a feature request
+  * implemented : we implemented this enhancement, but there is a good reson why we are not closing the issue just yet. Usually used in conjunction with ready for testing
+* Documentation work
+  * documentation
+* Urgency 
+  * urgent (fix in a few days) : This is used primarly for bugs found in the latest Release.
+  * not urgent (can wait)
+* Work load (this is merely to help contributer choose issues conpatible with the free time they have)
+  * hard work
+  * trivial
+* Will not fix
+  * wontfix
+  * duplicate : this issue already exists somewhere else
+  * invalid
--- a/Debugging/DEBUG_Add_Favorites.JPG
+++ b/Debugging/DEBUG_Add_Favorites.JPG
--- a/Debugging/DEBUG_Breakpoint.JPG
+++ b/Debugging/DEBUG_Breakpoint.JPG
--- a/Debugging/DEBUG_Breakpoint_List.JPG
+++ b/Debugging/DEBUG_Breakpoint_List.JPG
--- a/Debugging/DEBUG_Bug.JPG
+++ b/Debugging/DEBUG_Bug.JPG
--- a/Debugging/DEBUG_Debugger.JPG
+++ b/Debugging/DEBUG_Debugger.JPG
--- a/Debugging/DEBUG_Dynamic.JPG
+++ b/Debugging/DEBUG_Dynamic.JPG
--- a/Debugging/DEBUG_Engine.JPG
+++ b/Debugging/DEBUG_Engine.JPG
--- a/Debugging/DEBUG_Favorites.JPG
+++ b/Debugging/DEBUG_Favorites.JPG
--- a/Debugging/DEBUG_Flag.JPG
+++ b/Debugging/DEBUG_Flag.JPG
--- a/Debugging/DEBUG_Intro.JPG
+++ b/Debugging/DEBUG_Intro.JPG
--- a/Debugging/DEBUG_LDT_Setup.JPG
+++ b/Debugging/DEBUG_LDT_Setup.JPG
--- a/Debugging/DEBUG_Listener.JPG
+++ b/Debugging/DEBUG_Listener.JPG
--- a/Debugging/DEBUG_Loader.JPG
+++ b/Debugging/DEBUG_Loader.JPG
--- a/Debugging/DEBUG_MissionScripting.JPG
+++ b/Debugging/DEBUG_MissionScripting.JPG
--- a/Debugging/DEBUG_Run_Listener.JPG
+++ b/Debugging/DEBUG_Run_Listener.JPG
--- a/Debugging/DEBUG_Session.JPG
+++ b/Debugging/DEBUG_Session.JPG
--- a/Debugging/DEBUG_Source.JPG
+++ b/Debugging/DEBUG_Source.JPG
--- a/Debugging/DEBUG_Static.JPG
+++ b/Debugging/DEBUG_Static.JPG
--- a/Debugging/DEBUG_Tracking.JPG
+++ b/Debugging/DEBUG_Tracking.JPG
--- a/Documentation/AI.AI_A2A.html
+++ b/Documentation/AI.AI_A2A.html
--- a/Documentation/AI.AI_A2A_Cap.html
+++ b/Documentation/AI.AI_A2A_Cap.html
--- a/Documentation/AI.AI_A2A_Dispatcher.html
+++ b/Documentation/AI.AI_A2A_Dispatcher.html
--- a/Documentation/AI.AI_A2A_GCI.html
+++ b/Documentation/AI.AI_A2A_GCI.html
--- a/Documentation/AI.AI_A2A_Patrol.html
+++ b/Documentation/AI.AI_A2A_Patrol.html
--- a/Documentation/AI.AI_Bai.html
+++ b/Documentation/AI.AI_Bai.html
--- a/Documentation/AI.AI_Balancer.html
+++ b/Documentation/AI.AI_Balancer.html
--- a/Documentation/AI.AI_Cap.html
+++ b/Documentation/AI.AI_Cap.html
--- a/Documentation/AI.AI_Cargo.html
+++ b/Documentation/AI.AI_Cargo.html
--- a/Documentation/AI.AI_Cargo_APC.html
+++ b/Documentation/AI.AI_Cargo_APC.html
--- a/Documentation/AI.AI_Cargo_Airplane.html
+++ b/Documentation/AI.AI_Cargo_Airplane.html
--- a/Documentation/AI.AI_Cargo_Dispatcher.html
+++ b/Documentation/AI.AI_Cargo_Dispatcher.html
--- a/Documentation/AI.AI_Cargo_Dispatcher_APC.html
+++ b/Documentation/AI.AI_Cargo_Dispatcher_APC.html
--- a/Documentation/AI.AI_Cargo_Dispatcher_Airplane.html
+++ b/Documentation/AI.AI_Cargo_Dispatcher_Airplane.html
--- a/Documentation/AI.AI_Cargo_Dispatcher_Helicopter.html
+++ b/Documentation/AI.AI_Cargo_Dispatcher_Helicopter.html
--- a/Documentation/AI.AI_Cargo_Helicopter.html
+++ b/Documentation/AI.AI_Cargo_Helicopter.html
--- a/Documentation/AI.AI_Cas.html
+++ b/Documentation/AI.AI_Cas.html
--- a/Documentation/AI.AI_Formation.html
+++ b/Documentation/AI.AI_Formation.html
--- a/Documentation/AI.AI_Patrol.html
+++ b/Documentation/AI.AI_Patrol.html
--- a/Documentation/Actions.Account.html
+++ b/Documentation/Actions.Account.html
--- a/Documentation/Actions.Assign.html
+++ b/Documentation/Actions.Assign.html
--- a/Documentation/Actions.Assist.html
+++ b/Documentation/Actions.Assist.html
--- a/Documentation/Actions.Route.html
+++ b/Documentation/Actions.Route.html
--- a/Documentation/Cargo.Cargo.html
+++ b/Documentation/Cargo.Cargo.html
--- a/Documentation/Cargo.CargoCrate.html
+++ b/Documentation/Cargo.CargoCrate.html
--- a/Documentation/Cargo.CargoGroup.html
+++ b/Documentation/Cargo.CargoGroup.html
--- a/Documentation/Cargo.CargoSlingload.html
+++ b/Documentation/Cargo.CargoSlingload.html
--- a/Documentation/Cargo.CargoUnit.html
+++ b/Documentation/Cargo.CargoUnit.html
--- a/Documentation/Core.Base.html
+++ b/Documentation/Core.Base.html
--- a/Documentation/Core.Database.html
+++ b/Documentation/Core.Database.html
--- a/Documentation/Core.Event.html
+++ b/Documentation/Core.Event.html
--- a/Documentation/Core.Fsm.html
+++ b/Documentation/Core.Fsm.html
--- a/Documentation/Core.Goal.html
+++ b/Documentation/Core.Goal.html
--- a/Documentation/Core.Menu.html
+++ b/Documentation/Core.Menu.html
--- a/Documentation/Core.Message.html
+++ b/Documentation/Core.Message.html
--- a/Documentation/Core.Point.html
+++ b/Documentation/Core.Point.html
--- a/Documentation/Core.Radio.html
+++ b/Documentation/Core.Radio.html
--- a/Documentation/Core.Report.html
+++ b/Documentation/Core.Report.html
--- a/Documentation/Core.ScheduleDispatcher.html
+++ b/Documentation/Core.ScheduleDispatcher.html
--- a/Documentation/Core.Scheduler.html
+++ b/Documentation/Core.Scheduler.html
--- a/Documentation/Core.Set.html
+++ b/Documentation/Core.Set.html
--- a/Documentation/Core.Settings.html
+++ b/Documentation/Core.Settings.html
--- a/Documentation/Core.Spawn.html
+++ b/Documentation/Core.Spawn.html
--- a/Documentation/Core.SpawnStatic.html
+++ b/Documentation/Core.SpawnStatic.html
--- a/Documentation/Core.Spot.html
+++ b/Documentation/Core.Spot.html
--- a/Documentation/Core.UserFlag.html
+++ b/Documentation/Core.UserFlag.html
--- a/Documentation/Core.UserSound.html
+++ b/Documentation/Core.UserSound.html
--- a/Documentation/Core.Velocity.html
+++ b/Documentation/Core.Velocity.html
--- a/Documentation/Core.Zone.html
+++ b/Documentation/Core.Zone.html
--- a/Documentation/DCS.html
+++ b/Documentation/DCS.html
--- a/Documentation/Functional.ATC_Ground.html
+++ b/Documentation/Functional.ATC_Ground.html
--- a/Documentation/Functional.Arty.html
+++ b/Documentation/Functional.Arty.html
--- a/Documentation/Functional.CleanUp.html
+++ b/Documentation/Functional.CleanUp.html
--- a/Documentation/Functional.Designate.html
+++ b/Documentation/Functional.Designate.html
--- a/Documentation/Functional.Detection.html
+++ b/Documentation/Functional.Detection.html
--- a/Documentation/Functional.Escort.html
+++ b/Documentation/Functional.Escort.html
--- a/Documentation/Functional.MissileTrainer.html
+++ b/Documentation/Functional.MissileTrainer.html
--- a/Documentation/Functional.Movement.html
+++ b/Documentation/Functional.Movement.html
--- a/Documentation/Functional.PseudoATC.html
+++ b/Documentation/Functional.PseudoATC.html
--- a/Documentation/Functional.Range.html
+++ b/Documentation/Functional.Range.html
--- a/Documentation/Functional.Rat.html
+++ b/Documentation/Functional.Rat.html
--- a/Documentation/Functional.Scoring.html
+++ b/Documentation/Functional.Scoring.html
--- a/Documentation/Functional.Sead.html
+++ b/Documentation/Functional.Sead.html
--- a/Documentation/Functional.Suppression.html
+++ b/Documentation/Functional.Suppression.html
--- a/Documentation/Functional.Warehouse.html
+++ b/Documentation/Functional.Warehouse.html
--- a/Documentation/Functional.ZoneCaptureCoalition.html
+++ b/Documentation/Functional.ZoneCaptureCoalition.html
--- a/Documentation/Functional.ZoneGoal.html
+++ b/Documentation/Functional.ZoneGoal.html
--- a/Documentation/Functional.ZoneGoalCargo.html
+++ b/Documentation/Functional.ZoneGoalCargo.html
--- a/Documentation/Functional.ZoneGoalCoalition.html
+++ b/Documentation/Functional.ZoneGoalCoalition.html
--- a/Documentation/Tasking.CommandCenter.html
+++ b/Documentation/Tasking.CommandCenter.html
--- a/Documentation/Tasking.DetectionManager.html
+++ b/Documentation/Tasking.DetectionManager.html
--- a/Documentation/Tasking.Mission.html
+++ b/Documentation/Tasking.Mission.html
--- a/Show More
+++ b/Show More