mirror of
https://github.com/FlightControl-Master/MOOSE.git
synced 2025-08-15 10:47:21 +00:00
Update to latest changes
This commit is contained in:
Sven Van de Velde
parent
a334511601
commit
eb9fc7589f
@ -1,149 +0,0 @@
|
||||
*** UNDER CONSTRUCTION ***
|
||||
|
||||
You are interrested in **testing the bleeding edge functionnalities** 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. How to set up your development environment
|
||||
2. How is the Moose repository organized
|
||||
3. 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**.
|
||||
|
||||
|
||||
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 !
|
||||
|
||||
### 1.3) Run the Install script
|
||||
|
||||
Because DCS is going to load Moose dynamically (more on that later), we need to do some (slightly) advanced stuff to finish the setup of your own development enviroment. Thankfully we wrote a program to do it automatically for you !
|
||||
|
||||
|
||||
Browse to your local MOOSE repository and run `Moose Development Environment Setup\MooseDevelopmentEnvironmentSetup.exe` **as an administrator** (Select the file > Right Click > Run as administrator).
|
||||
|
||||
* The splash screen opens, click ok
|
||||
* Enter (or browse for) the 3 paths asked and click ok. Don't worry about trailing backslashs.
|
||||
* Let the program do its magic !
|
||||
* When the program finishes, it will inform you that you need to restart your computer to use the .miz files management tools.
|
||||
|
||||
If you encounter a problem during this installation, please contact the [community](Communities), with the mdes.log file which was generated next to the executable file. We'll try our best to help you!
|
||||
|
||||
_Wait, I'm not running a program randomly found on the internet like that. I don't even know what it does, and why does it have to be run as an administartor anyway?!_
|
||||
And you shouldn't. Here is the explanation of what this tool does (but the explanation is a bit technical, your are warned!):
|
||||
|
||||
* Create a hard link between your local repository and `DCSWorld/Scripts/`
|
||||
* Add 7-Zip to your PATH environment variable (this explains the restart requirement)
|
||||
* Copy a precompiled version of Lua 5.1 to your `Program Files` (this explains the administrator priviledge requirement)
|
||||
|
||||
The executable is made with AutoIt, its script is available near the executable. Open it as a text file if you want to know what it does. If you are still reluctant to do this, the whole process can be done manually by experienced users, get in touch with the [community](Communities)!
|
||||
|
||||
# 2) MOOSE Directory Structure
|
||||
|
||||
***TDOD : Update this section because of the repo changes***
|
||||
|
||||
The MOOSE framework is devided into a couple of directories:
|
||||
|
||||
* Moose Development: Contains the collection of lua files that define the MOOSE classes. You can use this directory to build the dynamic luadoc documentation intellisense in your eclipse development environment.
|
||||
* Moose Mission Setup: Contains the Moose.lua file to be included in your scripts when using MOOSE classes (see below the point Mission Design with Moose).
|
||||
* Moose Test Missions: Contains a directory structure with Moose Test Missions and examples. In each directory, you will find a miz file and a lua file containing the main mission script.
|
||||
* Moose Training: Contains the documentation of Moose generated with luadoc from the Moose source code. The presentations used during the videos in my [youtube channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg), are also to be found here.
|
||||
|
||||
# 3) Static Loading vs Dynamic Loading
|
||||
|
||||
## 3.1) Static Loading
|
||||
|
||||
**Moose static loading** is what the "normal" mission designer uses. Simply put, there **is a tool which concatenates every .lua file** which constitutes Moose **into just one: Moose.lua**. This is the file which is loaded in Mission Editorr by the mission designer.
|
||||
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 and the replacement 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
|
||||
|
||||
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 Moose's .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's .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! It is created by the Install Scipt (see above), and, simply put, makes sure that the folder `DCSWorld\Scripts\Moose` is always in sync with your local repository. 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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
## 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!
|
||||
@ -1,40 +0,0 @@
|
||||
# 1) MOOSE framework support channels
|
||||
|
||||
MOOSE is broadcasted, documented and supported through various social media channels.
|
||||
|
||||
## 1.1) MOOSE broadcast channels on YouTube
|
||||
|
||||
MOOSE has a [broadcast channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg/playlists) 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)
|
||||
|
||||
## 1.2) MOOSE on Eagle Dynamics forums
|
||||
|
||||
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).
|
||||
|
||||
## 1.3) MOOSE on GITHUB.
|
||||
|
||||
I encourage that you create also a user at GITHUB.
|
||||
On the MOOSE framework 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.
|
||||
|
||||
## 1.4) MOOSE on slack.com
|
||||
|
||||
Slack is a team community site. It is a great environment to discuss online the framework.
|
||||
Various channels are allocated in the environment to discuss specific topics.
|
||||
A channel exists per MOOSE class, so that a focused discuss is possible.
|
||||
|
||||
|
||||
|
||||
@ -1,190 +0,0 @@
|
||||
*** 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**.
|
||||
|
||||
|
||||
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
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 8.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 109 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 87 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 57 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
305
docs/README.md
305
docs/README.md
@ -1,305 +0,0 @@
|
||||
# 1. MOOSE framework
|
||||
|
||||
MOOSE is a **M**ission **O**bject **O**riented **S**cripting **E**nvironment, and is meant for mission designers and mission hosters.
|
||||
It allows to quickly setup complex missions using pre-scripted scenarios using the available classes within the MOOSE Framework.
|
||||
MOOSE works with DCS world 1.5. and 2.0.
|
||||
|
||||
|
||||
|
||||
## MOOSE framework goal
|
||||
|
||||
The goal of MOOSE is to allow mission designers to enhance their scripting with mission orchestration objects, which can be instantiated from defined classes within the framework. This will allow to write mission scripts with minimal code embedded. Of course, the richness of the framework will determine the richness of the misson scenarios.
|
||||
The MOOSE is a service that is produced while being consumed ... , it will evolve further as more classes are developed for the framework, and as more users are using it.
|
||||
|
||||
MOOSE is NOT meant to be a one-man show, it is meant to evolve within a growing community around the framework.
|
||||
|
||||
Within the community, key users will start supporting, documenting, explaining and even creating new classes for the framework.
|
||||
It is the ambition to grow this framework as a de-facto standard for mission designers to use.
|
||||
|
||||
|
||||
# 2. MOOSE Framework
|
||||
|
||||
The following classes are currently embedded within MOOSE framework and can be included within your mission scripts:
|
||||
|
||||
MOOSE is an Object Oriented framework and defines **Classes**, which are components that combine **Methods** and **Variables**/**Properties** as one encapsulated structure (table).
|
||||
Mission Designers can what we call **Instantiate Objects** from these MOOSE classes.
|
||||
|
||||
An example of what this means is shortly explained using the SPAWN class of MOOSE, which you can use to spawn new groups into your running mission.
|
||||
The SPAWN class simplifies the process of spawning, and it has many methods that you can use to create variations how you want your spawn object to spawn new groups.
|
||||
|
||||
```lua
|
||||
local SpawnObject = SPAWN:New( "GroupName" ) -- This creates a new SpawnObject from the SPAWN class, using the :New method constructor to instantiate a new SPAWN object searching for the GroupName as the late activated group defined within your Mission Editor.
|
||||
-- Nothing is spawned yet..., so let's use now the SpawnObject to spawn a new GROUP.
|
||||
|
||||
local SpawnGroup = SpawnObject:Spawn() -- Here we use the :Spawn() method of the SPAWN class. This method creates a new group from the GroupName template as defined within the Mission Editor.
|
||||
```
|
||||
|
||||
MOOSE Classes derive or inherit from each other, that means, within MOOSE there is an **Inheritance** structure where **inherited MOOSE Classes** are re-using properties and methods from the **Parent MOOSE Class**.
|
||||
This powerful concept is used everywhere within the MOOSE framework. The main (Parent) Class in the MOOSE framework is the BASE class. Every MOOSE Class is derived from this top BASE Class.
|
||||
So is also the SPAWN class derived from the BASE class. The BASE class provides powerful methods for debugging, event handling and implements the class handling logic.
|
||||
As a normal MOOSE user, you won't implement any code using inheritance but just know that the inheritance structure is omni present in the intellisense and documentation.
|
||||
You'll need to browse to the right MOOSE Class within the inheritance tree structure to identify which methods are properties are defined for which class.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## MOOSE Demonstration Missions
|
||||
|
||||
The framework comes with demonstration missions which can be downloaded [here](https://github.com/FlightControl-Master/MOOSE_MISSIONS/releases), that you can try out and helps you to code.
|
||||
These missions provide examples of defined use cases how the MOOSE framework can be utilized. Each test mission is located in a separate directory, which contains at least one .lua file and .miz file.
|
||||
The .lua file contains the mission script file that shows how the use case was implemented.
|
||||
You can copy/paste code the code snippets from this .lua file into your missions, as it will accellerate your mission developments.
|
||||
You will learn, see, and understand how the different MOOSE classes need to be applied, and how you can create
|
||||
more complex mission scenarios by combining these MOOSE classes into a complex but powerful mission engine.
|
||||
|
||||
Some of these exact test missions are also demonstrated in a video format on the [YouTube channel](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg).
|
||||
|
||||
|
||||
## 2.1. MOOSE Human Tasking Classes
|
||||
|
||||
MOOSE Tasking Classes provide a comprehensive Mission Orchestration System.
|
||||
Through COMMANDCENTERs, multiple logical MISSIONs can be orchestrated for coalitions.
|
||||
Within each MISSION, various TASKs can be defined.
|
||||
Each TASK has a TASK ACTION flow, which is the flow that a player (hosted by a UNIT) within the simulator needs to follow and accomplish.
|
||||
|
||||
* [COMMANDCENTER](Documentation/CommandCenter.html): Orchestrates various logical MISSIONs for a coalition.
|
||||
|
||||
* [MISSION](Documentation/Mission.html): Each MISSION has various TASKs to be executed and accomplished by players.
|
||||
|
||||
* [TASK_A2A_DISPATCHER](Documentation/Task_A2A_Dispatcher.html): Automatically and dynamically dispatch A2A tasks to be executed by human players, as a result of the detection of airborne targets within a Mission scope.
|
||||
|
||||
* [TASK_A2G_DISPATCHER](Documentation/Task_A2G_Dispatcher.html): Automatically and dynamically dispatch A2G tasks to be executed by human players, as a result of the detection of ground targets within a Mission scope.
|
||||
|
||||
* [TASK_A2A](Documentation/Task_A2A.html): Models a A2A CAP, INTERCEPT and SWEEP tasks where a Player is routed towards an attack zone without enemies nearby, and various ground targets need to be eliminated.
|
||||
|
||||
* [TASK_A2G](Documentation/Task_A2G.html): Models a A2G SEAD, CAS and BAI tasks where a Player is routed towards an attack zone with enemies nearby, and various ground targets need to be eliminated.
|
||||
|
||||
|
||||
## 2.2. MOOSE AI Controlling Classes
|
||||
|
||||
MOOSE AI Controlling Classes provide mechanisms to control AI over long lasting processes.
|
||||
These AI Controlling Classes are based on FSM (Finite State Machine) Classes, and provided an encapsulated way to make AI behave or execute an activity.
|
||||
|
||||
* [AI A2A Defenses](Documentation/AI_A2A_Dispatcher.html): Create automatic A2A defense systems executed by AI and perform CAP or GCI.
|
||||
* [AI\_A2A\_GCICAP](Documentation/AI_A2A_Dispatcher.html#AI_A2A_GCICAP): Using an easy process you can define an A2A defense system using the Mission Editor.
|
||||
* [AI\_A2A\_DISPATCHER](Documentation/AI_A2A_Dispatcher.html#AI_A2A_DISPATCHER): Same as AI\_A2A\_GCICAP, but is for more advanced or developer type mission designers. This class provides more options.
|
||||
|
||||
* [AI\_BALANCER](Documentation/AI_Balancer.html): Compensate in a multi player mission the abscence of players with dynamically spawned AI air units. When players join CLIENTS, the AI will either be destroyed, or will fly back to the home or nearest friendly airbase.
|
||||
|
||||
* [AI\_PATROL\_ZONE](Documentation/AI_Patrol_Zone.html): Make an alive AI Group patrol a zone derived from the ZONE_BASE class. Manage out-of-fuel events and set altitude and speed ranges for the patrol.
|
||||
|
||||
* [AI\_CAP](Documentation/AI_Cap.html): Make an alive AI Group perform Combat Air Patrol as a dynamic process.
|
||||
|
||||
* [AI\_CAS](Documentation/AI_Cas.html): Make an alive AI Group perform Close Air Support as a dynamic process.
|
||||
|
||||
* [AI\_BAI](Documentation/AI_Bai.html): Make an alive AI Group perform Battlefield Air Interdiction as a dynamic process.
|
||||
|
||||
|
||||
## 2.3. MOOSE Functional Classes
|
||||
|
||||
MOOSE Functional Classes provide various functions that are useful in mission design.
|
||||
|
||||
* [ESCORT](Documentation/Escort.html): Makes groups consisting of helicopters, airplanes, ground troops or ships within a mission joining your flight. You can control these groups through the ratio menu during your flight. Available commands are around: Navigation, Position Hold, Reporting (Target Detection), Attacking, Assisted Attacks, ROE, Evasion, Mission Execution and more ...
|
||||
|
||||
* [MISSILETRAINER](Documentation/MissileTrainer.html): Missile trainer, it destroys missiles when they are within a certain range of player airplanes, displays tracking and alert messages of missile launches; approach; destruction, and configure with radio menu commands. Various APIs available to configure the trainer.
|
||||
|
||||
* [DETECTION](Documentation/Detection.html): Detect other units using the available sensors of the detection unit. The DETECTION_BASE derived classes will provide different methods how the sets of detected objects are built.
|
||||
|
||||
* [SCORING](Documentation/Scoring.html): Administer the scoring of player achievements, and create a CSV file logging the scoring events for use at team or squadron websites.
|
||||
|
||||
* [SEAD](Documentation/Sead.html): Make SAM sites avoid SEAD missiles being fired at.
|
||||
|
||||
* [DESIGNATE](Documentation/Designate.html): Make AI automatically designate detected targets, and provide menu options for players to give instructions to the AI how to designate (by laser, smoke or illumination).
|
||||
|
||||
* [AIRBASEPOLICE](Documentation/AirbasePolice.html): Control the speed of players at the airbases. Speeding players are eliminated (does not work due to a bug in the DCS).
|
||||
|
||||
* [CLEANUP\_AIRBASE](Documentation/CleanUp.html): Keeps the airbases clean from clutter. (Only partly functional due to a bug in DCS, destroyed objects cannot be removed).
|
||||
|
||||
* [RAT](Documentation/Rat.html): Random Air Traffic engine developed by FunkyFranky, use the available airspace!
|
||||
|
||||
* [ATC_GROUND](Documentation/ATC_Ground.html): Monitor players on the airbase and make them behave and provide instructions.
|
||||
* [ATC_GROUND](Documentation/ATC_Ground.html#ATC_GROUND_CAUCASUS): ATC Ground operations for Caucasus.
|
||||
* [ATC_GROUND](Documentation/ATC_Ground.html#ATC_GROUND_NEVADA): ATC Ground operations for Nevada.
|
||||
* [ATC_GROUND](Documentation/ATC_Ground.html#ATC_GROUND_NORMANDY): ATC Ground operations for Normandy.
|
||||
|
||||
* [ZONE\_CAPTURE\_COALITION](Documentation/ZoneCaptureCoalition.html): Create a zone capturing process around a zone! Zones can be guarded, attacked, empty or captured.
|
||||
|
||||
|
||||
## 2.4. MOOSE Wrapper Classes
|
||||
|
||||
MOOSE Wrapper Classes provide an object oriented hierarchical mechanism to manage the DCS objects within the simulator.
|
||||
Wrapper classes provide another easier mechanism to control Groups, Units, Statics, Airbases and other objects.
|
||||
|
||||
* [OBJECT](Documentation/Object.html): This class provides the base for MOOSE objects.
|
||||
|
||||
* [IDENTIFIABLE](Documentation/Identifiable.html): This class provides the base for MOOSE identifiable objects, which is every object within the simulator :-).
|
||||
|
||||
* [POSITIONABLE](Documentation/Positionable.html): This class provides the base for MOOSE positionable objects. These are AIRBASEs, STATICs, GROUPs, UNITs ...
|
||||
|
||||
* [CONTROLLABLE](Documentation/Controllable.html): This class provides the base for MOOSE controllable objects. These are GROUPs, UNITs, CLIENTs.
|
||||
|
||||
* [AIRBASE](Documentation/Airbase.html): This class wraps a DCS Airbase object within the simulator.
|
||||
|
||||
* [GROUP](Documentation/Group.html): This class wraps a DCS Group objects within the simulator.
|
||||
|
||||
* [UNIT](Documentation/Unit.html): This class wraps a DCS Unit object within the simulator.
|
||||
|
||||
* [CLIENT](Documentation/Client.html): This class wraps a DCS Unit object within the simulator, which has a skill Client or Player.
|
||||
|
||||
* [STATIC](Documentation/Static.html): This class wraps a DCS StaticObject object within the simulator.
|
||||
|
||||
|
||||
## 2.5. MOOSE Core Classes
|
||||
|
||||
These classes define the base building blocks of the MOOSE framework. These classes are heavily used within the MOOSE framework.
|
||||
|
||||
* [BASE](Documentation/Base.html): The main class from which all MOOSE classes are derived from. The BASE class contains essential functions to support inheritance and MOOSE object execution tracing (logging within the DCS.log file in the saved games folder of the user).
|
||||
|
||||
* [DATABASE](Documentation/Database.html): Creates a collection of GROUPS[], UNITS[], CLIENTS[] and managed these sets automatically. Provides an API set to retrieve a GROUP, UNIT or CLIENT instance from the _DATABASE object using defined APIs. The collections are maintained dynamically during the execution of the mission, so when players join, leave, when units are created or destroyed, the collections are dynamically updated.
|
||||
|
||||
* [EVENT](Documentation/Event.html): Provides the Event Dispatcher base class to handle DCS Events, being fired upon registered events within the DCS simulator. Note that EVENT is used by BASE, exposing OnEvent() methods to catch these DCS events.
|
||||
|
||||
* [SCHEDULER](Documentation/Scheduler.html): This class implements a timer scheduler that will call at optional specified intervals repeatedly or just one time a scheduled function.
|
||||
|
||||
* [SPAWN](Documentation/Spawn.html#SPAWN): Spawn new groups (and units) during mission execution.
|
||||
|
||||
* [SPAWNSTATIC](Documentation/SpawnStatic.html#SPAWNSTATIC): Spawn Static objects using a predefined "template".
|
||||
|
||||
* [Finite State Machines](Documentation/Fsm.html): Finite State Machine provides a process management or state machine capability for various scenarios.
|
||||
* [FSM](Documentation/Fsm.html#FSM): The main FSM class can be used to build a generic Finite State Machine.
|
||||
* [FSM\_CONTROLLABLE](Documentation/Fsm.html#FSM_CONTROLLABLE): An FSM class to control a Controllable. A controllable is a group or unit that can be controlled.
|
||||
|
||||
* [MENU](Documentation/Menu.html): Set Menu options under the radio menu (F10). MENU classes also manage the recursive removal of menus, and the intelligent refresh of menu options (only the changes are applied).
|
||||
* [MENU\_MISSION](Documentation/Menu.html#MENU_MISSION): Set a main menu structure for the complete mission, for all players.
|
||||
* [MENU\_MISSION\_COMMAND](Documentation/Menu.html#MENU_MISSION_COMMAND): Set a main menu command for the complete mission, for all players.
|
||||
* [MENU\_COALITION](Documentation/Menu.html#MENU_COALITION): Set a menu structure for a coalition, for all players of that coalition.
|
||||
* [MENU\_COALITION\_COMMAND](Documentation/Menu.html#MENU_COALITION_COMMAND): Set a menu command for a coalition, for all players of that coalition.
|
||||
* [MENU\_GROUP](Documentation/Menu.html#MENU_GROUP): Set a menu structure for a group, for all players of that group.
|
||||
* [MENU\_GROUP\_COMMAND](Documentation/Menu.html#MENU_GROUP_COMMAND): Set a menu command for a group, for all players of that group.
|
||||
|
||||
* [SET](Documentation/Set.html): Create SETs of MOOSE objects. The SET can be filtered with defined filter criteria. Iterators are available that iterate through the SET, calling a function for each object within the SET.
|
||||
* [SET\_GROUP](Documentation/Set.html#SET_GROUP): Create a SET of GROUP objects.
|
||||
* [SET\_UNIT](Documentation/Set.html#SET_UNIT): Create a SET of UNIT objects.
|
||||
* [SET\_CLIENT](Documentation/Set.html#SET_CLIENT): Create a SET of CLIENT objects.
|
||||
* [SET\_AIRBASE](Documentation/Set.html#SET_AIRBASE): Create a SET of AIRBASE objects.
|
||||
* [SET\_CARGO](Documentation/Set.html#SET_CARGO): Create a SET of CARGO objects.
|
||||
|
||||
* [MESSAGE](Documentation/Message.html): A message publishing system, displaying messages to Clients, Coalitions or All players.
|
||||
|
||||
* [COORDINATE](Documentation/Point.html#COORDINATE): Manage 2D and 3D points in the simulation space, and use its methods for various actions on the coordinate.
|
||||
* [POINT\_VEC2](Documentation/Point.html#POINT_VEC2): Manage 2D points in the simulation space.
|
||||
* [POINT\_VEC3](Documentation/Point.html#POINT_VEC3): Manage 3D points in the simulation space.
|
||||
|
||||
* [ZONES](Documentation/Zone.html#ZONE): Create a zone object from a trigger zone as defined in the Mission Editor.
|
||||
* [ZONE\_POLYGON](Documentation/Zone.html#ZONE_POLYGON): Create a zone object from a group object, which is late activated, and its route points define the zone.
|
||||
* [ZONE\_RADIUS](Documentation/Zone.html#ZONE_RADIUS): Create a zone object from a 2D vector on the battlefield, with a defined radius.
|
||||
* [ZONE\_UNIT](Documentation/Zone.html#ZONE_UNIT): Create a zone object around a unit on the battlefield, with a defined radius. This, this zone is a moving zone!
|
||||
* [ZONE\_GROUP](Documentation/Zone.html#ZONE_GROUP): Create a zone object around a group on the battlefield, with a defined radius. The first object in the group has the zone, and is thus a moving zone!
|
||||
|
||||
* [CARGO](Documentation/Cargo.html): Manage Cargo in the simulation.
|
||||
* [CARGO\_GROUP](Documentation/Cargo.html#CARGO_GROUP): Manage Cargo that is defined as a GROUP object within the simulation.
|
||||
|
||||
* [BEACON](Documentation/Radio.html): Create beacons.
|
||||
* [RADIO](Documentation/Radio.html): Create radio communication.
|
||||
|
||||
|
||||
|
||||
# 3. MOOSE usage
|
||||
|
||||
The delivery of MOOSE follows a structured release process. Over time, new features are added that can be used in your mission.
|
||||
|
||||
### The latest release of MOOSE can be downloaded **[here](https://github.com/FlightControl-Master/MOOSE/releases)**.
|
||||
|
||||
There are 3 different ways how you can use MOOSE, each with a different engagement and complexity level:
|
||||
|
||||
|
||||
## 3.1. Use MOOSE as a Mission Designer
|
||||
|
||||
Refer to the detailed **[Usage Guide](Usage_Guide.html)** for more information.
|
||||
|
||||
|
||||
## 3.2. Beta test MOOSE
|
||||
|
||||
Beta testers of MOOSE are requested to install additional software.
|
||||
|
||||
As a return or as a reward, testers get:
|
||||
|
||||
* Newly developed features planned for the next MOOSE release can be tested and incorporated in your missions early.
|
||||
* You can evaluate and contribute to the stability of the next release.
|
||||
* Your mission creation workflow becomes very flexible. New features are dynamically added to you missions.
|
||||
|
||||
Please read the detailed **[Beta Test Guide](Beta_Test_Guide.html)** for more information.
|
||||
|
||||
|
||||
## 3.3. Contribute on the MOOSE development
|
||||
|
||||
Those people who have experience in lua development or are excited to contribute to the MOOSE project are welcome.
|
||||
|
||||
Please consult the **[Contribution Guide](Contribution_Guide.html)** for more information.
|
||||
|
||||
|
||||
## 3.4. Debug your code interactively using LDT
|
||||
|
||||
Have a look at the **[Interactive Debug Guide](Interactive_Debug_Guide.html)** to setup your system so you can debug your mission code.
|
||||
|
||||
|
||||
|
||||
# 4. MOOSE Support Channels
|
||||
|
||||
MOOSE is broadcasted, documented and supported through various social media channels.
|
||||
|
||||
Click here for the **[communities guide](Communities.html)** of the MOOSE framework.
|
||||
|
||||
|
||||
|
||||
# 5. Credits
|
||||
|
||||
Note that most of the framework is based on code i've written myself,
|
||||
but some code of it is also based on code that i've seen as great scripting code and ideas,
|
||||
and which has been revised and/or reworked to fit into the MOOSE framework.
|
||||
I see this framework evolving towards a broader public, and the ownership may dissapear (or parts of it). Consider this code public domain.
|
||||
Therefore a list of credits to all who have or are contributing (this list will increase over time).
|
||||
|
||||
You'll notice that within this framework, there are functions used from mist. I've taken the liberty to copy those atomic mist functions that are very nice and useful, and used those.
|
||||
|
||||
|
||||
**Greyecho**
|
||||
Contributed the devevelopment of the new release system, and the development of the RADIO and BEACON functionalities.
|
||||
We'll see more appearing from him.
|
||||
|
||||
**Prof_hilactic**
|
||||
SEAD Defenses. I've taken the script, and reworded it to fit within MOOSE. The script within MOOSE is hardly recognizable anymore from the original. Find here the posts: http://forums.eagle.ru/showpost.php?...59&postcount=1
|
||||
|
||||
**xcom**
|
||||
His contribution is related to the Event logging system. I've analyzed and studied his scripts, and reworked it a bit to use it also within the framework (I've also tweaked it a bit). Find his post here: http://forums.eagle.ru/showpost.php?...73&postcount=1
|
||||
|
||||
**Dutch_Baron (James)**
|
||||
Working together with James has resulted in the creation of the AIBALANCER class. James has shared his ideas on balancing AI with air units, and together we made a first design which you can use now :-)
|
||||
|
||||
**Stuka (Danny)**
|
||||
Working together with Danny has resulted in the MISSILETRAINER class. Stuka has shared his ideas and together we made a design. Together with the 476 virtual team, we tested this CLASS, and got much positive feedback!
|
||||
|
||||
**Mechanic (Gabor)**
|
||||
Worked together with Gabor to create the concept of the DETECTION and FAC classes. Mechanic shared his ideas and concepts to group detected targets into sets within detection zones... Will continue to work with G<>bor to workout the DETECTION and FAC classes.
|
||||
|
||||
**Shadoh**
|
||||
Interacted on the eagle dynamics forum to build the FOLLOW class to build large WWII airplane formations.
|
||||
|
||||
**Grimes**
|
||||
Without the effort of Grimes with MIST and his continuous documentation of the DCS API, the development of MOOSE would not have been possible.
|
||||
MOOSE is complementary to [MIST](https://github.com/mrSkortch/MissionScriptingTools/releases), so if you use MIST in parallel with MOOSE objects, this should work.
|
||||
The documentation of the [DCS API] is the work of Grimes. Please consult his documentation in case of any question concerning the DCS API level.
|
||||
|
||||
For the rest I also would like to thank the numerous feedback and help and assistance of the moose community at SLACK.COM.
|
||||
Note that there is a vast amount of other scripts out there.
|
||||
I may contact you personally to ask for your contribution / permission if i can use your idea or script to tweak it to the framework.
|
||||
Parts of these scripts will have to be redesigned to fit it into an OO framework.
|
||||
|
||||
The rest of the framework functions and class definitions were my own developments, especially the core of MOOSE.
|
||||
Trust I've spent hours and hours investigating, trying and writing and documenting code building this framework.
|
||||
Hope you think the idea is great and useful.
|
||||
|
||||
Thank you!
|
||||
FC
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!DOCTYPE html>
|
||||
<meta charset="utf-8">
|
||||
<title>Redirecting to https://flightcontrol-master.github.io/MOOSE_DOCS/</title>
|
||||
<title>Redirecting to //flightcontrol-master.github.io/MOOSE_DOCS/</title>
|
||||
<meta http-equiv="refresh" content="0; URL=https://flightcontrol-master.github.io/MOOSE_DOCS/">
|
||||
<link rel="canonical" href="https://flightcontrol-master.github.io/MOOSE/">
|
||||
Loading…
x
Reference in New Issue
Block a user