mirror of
https://github.com/acemod/ACE3.git
synced 2024-08-30 18:23:18 +00:00
proper heading numeration
This commit is contained in:
bux578
parent
08ada80baa
commit
a5d74f4bfd
@ -6,7 +6,7 @@ parent: wiki
|
||||
order: 2
|
||||
---
|
||||
|
||||
### CfgVehicles
|
||||
## 1. CfgVehicles
|
||||
|
||||
```c++
|
||||
ace_nightvision_grain
|
||||
@ -23,7 +23,7 @@ ace_offset
|
||||
```
|
||||
|
||||
|
||||
### CfgWeapons
|
||||
## 2. CfgWeapons
|
||||
|
||||
```c++
|
||||
ace_recoil_shakemultiplier
|
||||
@ -60,7 +60,7 @@ ace_modedescription
|
||||
```
|
||||
|
||||
|
||||
### CfgAmmo
|
||||
## 3. CfgAmmo
|
||||
|
||||
```c++
|
||||
ace_recoil_shakemultiplier
|
||||
@ -88,7 +88,7 @@ ace_barrellengths
|
||||
```
|
||||
|
||||
|
||||
### CfgGlasses
|
||||
## 4. CfgGlasses
|
||||
|
||||
```c++
|
||||
ace_color
|
||||
@ -102,7 +102,7 @@ ace_dustpath
|
||||
```
|
||||
|
||||
|
||||
### CfgMagazines
|
||||
## 5. CfgMagazines
|
||||
|
||||
```c++
|
||||
ace_isbelt
|
||||
|
||||
@ -6,7 +6,7 @@ parent: wiki
|
||||
order: 3
|
||||
---
|
||||
|
||||
## Event Handlers
|
||||
## 1. Event Handlers
|
||||
|
||||
Event handlers in ACE3 are implemented through our event system. They should be used to trigger or allow triggering of specific functionality.
|
||||
|
||||
@ -23,12 +23,14 @@ Events can be removed or cleared with the following commands.
|
||||
* `[eventName, eventHandlerId] call ace_common_fnc_removeEventHandler` <br/> 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` <br/> will remove all event handlers for that type of event.
|
||||
|
||||
### Synchronized Events
|
||||
### 1.1 Synchronized Events
|
||||
|
||||
* `[eventName, eventCodeBlock, ttlNumberOrCodeBlock] call ace_common_fnc_addSyncedEventHandler` <br/> adds a globally synchronized event handler which will expire events after the provided TTL, or the code returns true.
|
||||
* `[eventName] call ace_common_fnc_removeSyncedEventHandler` <br/> will remove a specific event handler of the event name, using the ID returned from `ace_common_fnc_addSyncedEventHandler`.
|
||||
* * `[eventName, args, ttlNumberOrCodeBlock] call ace_common_fnc_syncedEvent` <br/> calls a global synchronized event, which will also be run on JIP players unless it has expired; event will expire after the provided TTL, or the code returns true.
|
||||
|
||||
### Pattern:
|
||||
### 1.2 Pattern:
|
||||
|
||||
```c++
|
||||
// tapper machine
|
||||
["tapShoulder", [_target], [otherArguments]] call EFUNC(common,targetEvent);
|
||||
@ -38,7 +40,8 @@ PREP(onTapShoulder);
|
||||
["tapShoulder", FUNC(onTapShoulder) ] call EFUNC(common,addEventHandler);
|
||||
```
|
||||
|
||||
### Listenable Event List:
|
||||
### 1.3 Listenable Event List:
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
@ -191,7 +194,8 @@ PREP(onTapShoulder);
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Callable Event List:
|
||||
### 1.4 Callable Event List:
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
|
||||
@ -6,25 +6,25 @@ parent: wiki
|
||||
order: 8
|
||||
---
|
||||
|
||||
## Terminology
|
||||
## 1. Terminology
|
||||
|
||||
#### Frame
|
||||
### 1.1 Frame
|
||||
A single rendered frame of Arma 3.
|
||||
|
||||
#### Scheduled Space
|
||||
### 1.2 Scheduled Space
|
||||
|
||||
This refers to execution would is ruled by the Arma 3 default script scheduling engine. This would include:
|
||||
* spawn
|
||||
* execVM
|
||||
|
||||
#### Unscheduled Space
|
||||
### 1.3 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?
|
||||
## 2. What is the scheduler and why do I care?
|
||||
|
||||
BIKI Article: https://community.bistudio.com/wiki/Biki2.0:Performance_Considerations
|
||||
|
||||
@ -36,7 +36,7 @@ What does this all mean? It means we need to live outside of the spawn execution
|
||||
|
||||
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
|
||||
## 3 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.
|
||||
|
||||
@ -47,7 +47,7 @@ Rules of thumb for component design:
|
||||
* If you have to wait, use a PFH delay/diag_tickTime check.
|
||||
|
||||
|
||||
### PFH-Design Pattern
|
||||
### 3.1 PFH-Design Pattern
|
||||
|
||||
Line Notes:
|
||||
|
||||
@ -55,7 +55,7 @@ Line Notes:
|
||||
|
||||
|
||||
|
||||
### ACE3 General Rules
|
||||
### 3.2 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. *
|
||||
@ -63,9 +63,9 @@ Line Notes:
|
||||
* 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
|
||||
### 3.3 Code Examples
|
||||
|
||||
##### Generic PFH functions
|
||||
#### 3.3.1 Generic PFH functions
|
||||
See: https://dev.withsix.com/docs/cba/files/common/fnc_addPerFrameHandler-sqf.html for more details.
|
||||
|
||||
```c++
|
||||
@ -73,7 +73,7 @@ See: https://dev.withsix.com/docs/cba/files/common/fnc_addPerFrameHandler-sqf.ht
|
||||
```
|
||||
|
||||
|
||||
##### PFH Wait
|
||||
#### 3.3.2 PFH Wait
|
||||
|
||||
```c++
|
||||
DFUNC(myDelayedFunction) = {
|
||||
|
||||
@ -6,17 +6,8 @@ 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
|
||||
## 1. Indentation
|
||||
|
||||
4 spaces for indentation.
|
||||
|
||||
@ -28,12 +19,12 @@ class Something: Or {
|
||||
};
|
||||
```
|
||||
|
||||
#### Reasoning
|
||||
### 1.1 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
|
||||
## 2. Braces
|
||||
|
||||
- opening brace on the same line as keyword
|
||||
- closing brace in own line, same level of indentation as keyword
|
||||
@ -88,12 +79,12 @@ class Two {foo = 2;};
|
||||
class Three {foo = 3;};
|
||||
```
|
||||
|
||||
#### Reasoning
|
||||
### 2.1 Reasoning
|
||||
|
||||
Putting the opening brace in it's own line wastes a lot of space, and keeping the closing brace on the same level as the keyword makes it easier to recognize what exactly the brace closes.
|
||||
|
||||
|
||||
## How to create a new module
|
||||
## 3. 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)
|
||||
@ -101,7 +92,7 @@ Putting the opening brace in it's own line wastes a lot of space, and keeping th
|
||||
1. The module is now prepared for development
|
||||
|
||||
|
||||
### Function Definitions
|
||||
### 3.1 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!**
|
||||
|
||||
@ -127,9 +118,9 @@ Every function should have a header of the following format:
|
||||
```
|
||||
|
||||
|
||||
## Macro Usage
|
||||
## 4. Macro Usage
|
||||
|
||||
### Module/PBO specific Macro Usage
|
||||
### 4.1 Module/PBO specific Macro Usage
|
||||
The family of `GVAR` macro's define global variable strings or constants for use within a module. Please use these to make sure we follow naming conventions across all modules and also prevent duplicate/overwriting between variables in different modules. The macro family expands as follows, for the example of the module 'balls'
|
||||
|
||||
* `GVAR(face)` is `ace_balls_face`
|
||||
@ -152,7 +143,7 @@ The `FUNC` and `EFUNC` macros should NOT be used inside `QUOTE` macros if the in
|
||||
|
||||
Using `FUNC` or `EFUNC` inside a `QUOTE` macro is fine if the intention is for it to be executed as a function.
|
||||
|
||||
#### FUNC Macros, Call Tracing, and Non-ACE/Anonymous Functions
|
||||
#### 4.1.1 FUNC Macros, Call Tracing, and Non-ACE/Anonymous Functions
|
||||
|
||||
ACE implements a basic call tracing system that can dump the call stack on errors or wherever you want. To do this the `FUNC` macros in debug mode will expand out to include metadata about the call including line numbers and files. This functionality is automatic with the use of calls via `FUNC` and `EFUNC`, but any calls to other functions need to use the following macros:
|
||||
|
||||
@ -161,13 +152,13 @@ ACE implements a basic call tracing system that can dump the call stack on error
|
||||
|
||||
These macros will call these functions with the appropriate wrappers and enable call logging into them (but to no further calls inside obviously).
|
||||
|
||||
### General Purpose Macros
|
||||
### 4.2 General Purpose Macros
|
||||
|
||||
[CBA script_macros_common.hpp](https://gist.github.com/commy2/9ed6cc73fbe6a2b3f4e1)
|
||||
|
||||
* `QUOTE()` is utilized within configuration files for bypassing the quote issues in configuration macros. So, all code segments inside a given config should utilize wrapping in the QUOTE() macro instead of direct strings. This allows us to use our macros inside the string segments, such as `QUOTE(_this call FUNC(balls))`
|
||||
|
||||
#### setVariable, getVariable family macros
|
||||
#### 4.2.1 setVariable, getVariable family macros
|
||||
|
||||
* `GETVAR(player,MyVarName,false)`
|
||||
`player getVariable ["MyVarName", false]`
|
||||
@ -185,7 +176,7 @@ These macros will call these functions with the appropriate wrappers and enable
|
||||
`uiNamespace setVariable ["MyVarName", _control]`
|
||||
|
||||
|
||||
## Event Handlers
|
||||
## 5. Event Handlers
|
||||
|
||||
Event handlers in ACE are implemented through our event system. They should be used to trigger or allow triggering of specific functionality.
|
||||
|
||||
@ -204,7 +195,7 @@ Events can be removed or cleared with the following commands.
|
||||
|
||||
More information on the [ACE Events System](https://github.com/KoffeinFlummi/ACE3/wiki/ACE-Events-System) page.
|
||||
|
||||
## Hashes
|
||||
## 6. Hashes
|
||||
|
||||
Hashes are a variable type that store key value pairs. They are not implemented natively in SQF, so there are a number of macros and functions for their usage in ACE. If you are unfamiliar with the idea, they are similar in function to `setVariable`/`getVariable` but do not require an object to use.
|
||||
|
||||
@ -230,7 +221,7 @@ A description of the above macros is below.
|
||||
* `HASH_HASKEY(hash, key)` will return true/false if that key exists in the hash.
|
||||
* `HASH_REM(hash, key)` will remove that hash key.
|
||||
|
||||
### Hashlists
|
||||
### 6.1 Hashlists
|
||||
|
||||
A hashlist is an extension of a hash. It is a list of hashes! The reason for having this special type of storage container rather than using a normal array is that an array of normal hashes that are are similar will duplicate a large amount of data in their storage of keys. A hashlist on the other hand uses a common list of keys and an array of unique value containers. The following will demonstrate it's usage.
|
||||
|
||||
@ -269,6 +260,6 @@ As you can see above working with hashlists are fairly simple, a more in depth e
|
||||
* `HASHLIST_SELECT(hashlist, index)` returns the hash at that index in the list.
|
||||
* `HASHLIST_SET(hashlist, index, hash)` sets a specific index to that hash.
|
||||
|
||||
#### A note on pass by reference and hashes
|
||||
#### 6.1.1 A note on pass by reference and hashes
|
||||
|
||||
Hashes and hashlists are implemented with SQF arrays, and as such they are passed by reference to other functions. Remember to make copies (using the + operator) if you intend for the hash or hashlist to be modified with out the need for changing the original value.
|
||||
|
||||
@ -6,27 +6,27 @@ parent: wiki
|
||||
order: 9
|
||||
---
|
||||
|
||||
## Basics
|
||||
## 1. Basics
|
||||
|
||||
### Requirements
|
||||
### 1.1 Requirements
|
||||
|
||||
- A compiler (VS/GCC/Clang)
|
||||
- If starting with Visual Studio, you need to make sure to use the Visual studio command prompt
|
||||
- cmake 3.0 or later in your path
|
||||
|
||||
### Cross-Platform Guidelines
|
||||
### 1.2 Cross-Platform Guidelines
|
||||
|
||||
### C++ basic style and naming guide
|
||||
### 1.3 C++ basic style and naming guide
|
||||
|
||||
### ace_common cpp library
|
||||
### 1.4 ace_common cpp library
|
||||
|
||||
---
|
||||
|
||||
## Building Extensions on Windows
|
||||
## 2 Building Extensions on Windows
|
||||
|
||||
### Compiling
|
||||
### 2.1 Compiling
|
||||
|
||||
#### Windows - Creating a Visual Studio Project
|
||||
#### 2.1.1 Windows - Creating a Visual Studio Project
|
||||
1. Open your compiling command prompt (which has cmake and your compiler)
|
||||
2. From this directory, you need to use cmake to build the appropriate build files. Change the -G property appropriately. run cmake --help to get a list of the options.
|
||||
|
||||
@ -37,7 +37,7 @@ cmake .. -G "Visual Studio 2014"
|
||||
|
||||
A Visual studio project file will now be generated in your build directory.
|
||||
|
||||
#### Windows - Visual Studio - Compile only (nmake)
|
||||
#### 2.1.2 Windows - Visual Studio - Compile only (nmake)
|
||||
1. Open your compiling command prompt (which has cmake and your compiler)
|
||||
2. From this directory, you need to use cmake to build the appropriate build files. Change the -G property appropriately. run cmake --help to get a list of the options.
|
||||
|
||||
@ -56,4 +56,4 @@ extensions\
|
||||
somethingElse\ace_somethingElse.dll
|
||||
```
|
||||
|
||||
### Creating a New Extension
|
||||
### 2.2 Creating a New Extension
|
||||
|
||||
@ -9,20 +9,7 @@ order: 0
|
||||
This page describes how you can setup your development environment for ACE3, allowing you to properly build ACE and utilize file patching.
|
||||
|
||||
|
||||
## Table Of Contents
|
||||
- [Requirements](#requirements)
|
||||
- [Why so complicated?](#why-so-complicated)
|
||||
- [Getting ACE](#getting-ace)
|
||||
- [Initial Setup](#initial-setup)
|
||||
- [Manual Setup](#manual-setup)
|
||||
- [Creating a Test Build](#creating-a-test-build)
|
||||
- [Creating a Release Build](#creating-a-release-build)
|
||||
- [File Patching](#file-patching)
|
||||
- [Enabling File Patching](#enabling-file-patching)
|
||||
- [Restrictions of File Patching](#restrictions-of-file-patching)
|
||||
|
||||
|
||||
## Requirements
|
||||
## 1. Requirements
|
||||
|
||||
- Arma 3 (duh)
|
||||
- A proper installation of the Arma 3 Tools (available on Steam)
|
||||
@ -32,25 +19,25 @@ This page describes how you can setup your development environment for ACE3, all
|
||||
- A properly setup PATH variable (containing Python and the Mikero tools)
|
||||
|
||||
|
||||
## Why so complicated?
|
||||
## 2. Why so complicated?
|
||||
|
||||
If you have contributed to AGM you might be used to an easier build process, where there was even an .exe you could use for building. ACE3, however, makes use of CBA macros to simplify things and give the developer access to a better debug process, which requires a stricter build environment. Additionally, Mikero's tools are stricter and report more errors than AddonBuilder does. The structure of this development environment also allows for [file patching](#file-patching), which is very useful for debugging.
|
||||
|
||||
Not offering .exes for the Python scripts we use allows us to make easy changes without the hassle of compiling self-extracting exes all the time.
|
||||
|
||||
|
||||
## Getting ACE
|
||||
## 3. Getting ACE
|
||||
|
||||
To actually get the ACE source code on your machine, it is recommended that you use Git. Tutorials for this are all around the web, and it allows you to track your changes and easily update your local copy.
|
||||
|
||||
If you just want to create a quick and dirty build, you can also directly download the source code using the "Download ZIP" button on the front page of the GitHub repo.
|
||||
|
||||
|
||||
## Initial Setup
|
||||
## 4. Initial Setup
|
||||
|
||||
After ensuring that you have installed all requirements, execute the `setup.py` script found in the `tools` folder. This will do most of the heavy lifting for you, create the links you need and copy the required CBA code to the proper place. Please note that these links are tied to the location of your ACE3 source code, so make sure that the project folder is where you want it to be. We recommend that you store the ACE3 project on your P-drive.
|
||||
|
||||
#### Manual Setup
|
||||
### 4.1 Manual Setup
|
||||
|
||||
Should the script fail, here is how you create the required links manually:
|
||||
|
||||
@ -73,7 +60,7 @@ mklink /D "P:\z\ace" "[location of the ACE3 project]"
|
||||
Then, copy the `cba` folder from the `tools` folder to `P:\x\cba`. Create the `x` folder if needed. That folder contains the parts of the CBA source code that are required for the macros to work.
|
||||
|
||||
|
||||
## Creating a Test Build
|
||||
## 5. Creating a Test Build
|
||||
|
||||
To create a development build of ACE to test changes or to debug something, run the `build.py` file in the `tools` folder. This will populate the `addons` folder with binarized PBOs. These PBOs still point to the source files in their respective folders however, which allows you to use [file patching](#file-patching).
|
||||
|
||||
@ -86,16 +73,16 @@ To start the game using this build, you can use the following modline:
|
||||
```
|
||||
|
||||
|
||||
## Creating a Release Build
|
||||
## 6. Creating a Release Build
|
||||
|
||||
To create a complete build of ACE that you can use without the source files, run the `make.py` file in the `tools` folder. This will populate the `release` folder with binarized PBOs that you can redistribute. These handle like those of any other mod.
|
||||
|
||||
|
||||
## File Patching
|
||||
## 7. File Patching
|
||||
|
||||
File Patching allows you to change the files in an addon while the game is running, requiring only a restart of the mission. This makes it great for debugging, as it cuts down the time required between tests. Note that this only works with PBOs created using MakePBO, as outlined in [Creating a Test Build](#creating-a-test-build).
|
||||
|
||||
#### Enabling File Patching
|
||||
### 7.1 Enabling File Patching
|
||||
|
||||
There are two ways to enable file patching:
|
||||
- Load cba_cache_disable.pbo (included in CBA's optional folder)
|
||||
@ -113,7 +100,7 @@ class CfgSettings {
|
||||
};
|
||||
```
|
||||
|
||||
#### Restrictions of File Patching
|
||||
### 7.2 Restrictions of File Patching
|
||||
|
||||
Files must exist in the built PBOs for filepatching to work. If you create a new file you must rebuild the PBO or Arma will not find it in your file paths.
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ The four main elements that basic medical introduces are:
|
||||
All interactions in the medical system are done with the interaction menu. Non-medics can - by default - not perform all actions, and their actions take more time as when performed by trained medics. These actions are using epinephrine and blood IVs.
|
||||
|
||||
|
||||
### How it works
|
||||
### 2.1 How it works
|
||||
|
||||
When hit, units start to lose blood depending on the severity of their wounds. Once the level of blood falls below a certain threshold, the unit will fall unconscious and eventually die. Units will also fall unconscious when sustaining large amounts of damage at once.
|
||||
|
||||
@ -45,17 +45,17 @@ Besides the 4 elements introduced by basic medical, advanced introduces the foll
|
||||
* Various treatment methods such as CPR, different kinds of IVs and tourniquets
|
||||
* A basic medication simulation
|
||||
|
||||
### How it works
|
||||
### 3.1 How it works
|
||||
|
||||
Same as with basic, when hit an injury is sustained. Different though is that the type of injury and the severity of it are based upon how the damage was done and what caused it. This affects both blood loss and immediate consequences, such as being knocked out or being killed right away. When a player has sustained an injury, this will be indicated by flashing red of the screen; this means the player is bleeding.
|
||||
|
||||
##### Stopping bleeding
|
||||
#### 3.1.1 Stopping bleeding
|
||||
In order to stop the bleeding, all injuries on every bodypart requires treatment. This is done by either applying a tourniquet to legs or arms as a temporarly solution, or by using bandages to stop the bleeding as a more permament fix.
|
||||
|
||||
##### Vitals
|
||||
#### 3.1.2 Vitals
|
||||
While a unit is bleeding however, the blood volume decreases which will result in a change of vitals. Depending on the factors such as current blood volume, the blood loss rate, medication used, the blood pressure will start to drop. To counter this drop, also based upon the previously mentioned factors and others, the heart rate will adjust accordingly to attempt to keep blood pressure at safe levels. This means that for any patient it is required to keep an eye on the vitals. This is done through the interaction system by selecting check pulse or blood pressure on either the arms or head.
|
||||
|
||||
##### Medication
|
||||
#### 3.1.3 Medication
|
||||
To stabalize the vitals and to counter for example pain, a player/medic can use medication. Advanced medical has 3 different medications available:
|
||||
* Atropine
|
||||
* Morphine
|
||||
|
||||
@ -6,7 +6,7 @@ order: 5
|
||||
parent: wiki
|
||||
---
|
||||
|
||||
# 1. Overview
|
||||
## 1. Overview
|
||||
|
||||
The ACE Advanced Missile Guidance Framework provides a setup of configuration settings, functions and a execution framework for addon makers to integrate with the missile guidance and targeting mechanisms of ACE. It also provides for mod makers to create their own custom guidance methods within the framework.
|
||||
|
||||
@ -18,23 +18,23 @@ ACE3 provides a full suite of base concepts and guidance for the majority of mod
|
||||
|
||||
Finally, flight profiles and mechanics for realistic missile simulations are also implemented; allowing for lock-steering bump guidance flight such as with the M47 Dragon or GBU steering fins, or finely tuned direct flight guidance which is currently avialable with other missile types.
|
||||
|
||||
# 2. Details
|
||||
## 2. Details
|
||||
|
||||
The framework is broken up into 3 major components: Locking Types, Seeker Types and Attack Profiles. In combination, these components build out the entire process of launching, locking and going terminal flight against targets.
|
||||
|
||||
### Components
|
||||
### 2.1 Components
|
||||
|
||||
##### 1. Locking Types
|
||||
#### 2.1.1 Locking Types
|
||||
Locking types provide the basic functionality of targeting which will be based to a seeker type, providing target aquisition for seekers. This provides the basic functionality for providing pre-determined targets for a seeker, or allowing the seeker to perform its own target aquisition and locking. Additionally, the seeker may reference back into the locking type in order to re-perform target aquisition.
|
||||
|
||||
##### 2. Seeker Types
|
||||
#### 2.1.2 Seeker Types
|
||||
Each seeker is generally assumed to be the logic for the seeker head unit within any given munition. Seekers within this framework provide the basic targeting functionality for the entire framework. The locking type will provide a generic target to the seeker, or the seeker may aquire a target on its own. The seeker then provides a target, either an object or a ASL position, which is then passed further into the framework. This target (or position) should be the actual current target position for the missiles flight. Seekers are required to perform all limitations and checks within their systems, although various limitations have been provided in this framework such as LOS FOV, laser guidance, etc.
|
||||
|
||||
##### 3. Attack Profiles
|
||||
#### 2.1.3 Attack Profiles
|
||||
|
||||
An attack profile adjusts the current target flight location to create the actual flight path of the missile. The attack profile is provided with all parameters of the system, including the returned target of the seeker. Using this information, the attack profile then will adjust the *direct flight target position* to specifically direct where and how the missile shall flight.
|
||||
|
||||
## How it all ties together
|
||||
## 3. How it all ties together
|
||||
|
||||
The system is executed in a linear series of calls to each step of the process, and feeding back the return from that step to the next step. Execution is conducted using Locking->Seeker->Profile, iteratively every frame of execution. Flight times are adjusted to accTime values and FPS lag, giving consistent flight.
|
||||
|
||||
@ -42,9 +42,9 @@ On each step of execution, a target specification array [targetObj, targetPos] i
|
||||
|
||||
In the simplest sense, the entire system provides the flight trajectory of the missile homing directly on the "adjusted attack position"; thus, an attack profile would ajust this position to direct the missile. For example, Top down attacks return the adjusted attack position high above the target, until entering their terminal stages, which then changes the position to be directly ontop of the target - thus "walking the missile" along its flight path and to the kill.
|
||||
|
||||
# 2. Adding AMG to a missile
|
||||
## 4. Adding AMG to a missile
|
||||
|
||||
## Enabling guidance on Ammo Types
|
||||
### 4.1 Enabling guidance on Ammo Types
|
||||
```
|
||||
class CfgAmmo {
|
||||
class MissileBase;
|
||||
@ -81,9 +81,9 @@ class CfgAmmo {
|
||||
};
|
||||
```
|
||||
|
||||
# 2. Creating your own custom seekers and attack profiles
|
||||
## 5. Creating your own custom seekers and attack profiles
|
||||
|
||||
## Adding seeker types and attack profiles
|
||||
### 5.1 Adding seeker types and attack profiles
|
||||
|
||||
```
|
||||
class ace_missileguidance_attackProfiles{
|
||||
@ -104,4 +104,4 @@ class ace_missileguidance_seekerTypes {
|
||||
functionName = "my_fnc_doSeekerType";
|
||||
};
|
||||
};
|
||||
```
|
||||
```
|
||||
|
||||
@ -6,7 +6,7 @@ order: 5
|
||||
parent: wiki
|
||||
---
|
||||
|
||||
# 1. Config Values
|
||||
## 1. Config Values
|
||||
|
||||
```
|
||||
class CfgVehicles {
|
||||
|
||||
@ -88,17 +88,17 @@ You can make a whitelist of addons that don't have to be on the server. If you w
|
||||
The list must be in the following format: `["ADDON1","ADDON2",...]` where the addons are CfgPatches references to all PBOs of the optional mod. To figure these out, you can use the scripting command `activatedAddons` in the editor while those mods are enabled.
|
||||
|
||||
Example 1: @Blastcore-A3:<br>
|
||||
```js
|
||||
```
|
||||
["warfxpe","blastcore_vep"]
|
||||
```
|
||||
|
||||
Example 2: @JSRS:<br>
|
||||
```js
|
||||
```
|
||||
[TBD]
|
||||
```
|
||||
|
||||
Example 3: @JSRS + @Blastcore-A3:<br>
|
||||
```js
|
||||
```
|
||||
[TBD, "warfxpe","blastcore_vep"]
|
||||
```
|
||||
|
||||
@ -405,7 +405,7 @@ Keep unit status synced. Recommended on.<br>
|
||||
|
||||
### 2.2 Advanced Medical Settings
|
||||
|
||||
This module allows you to change the default Advanced Medical Settings, when [2.1 Medical Settings](#2-1MedicalSettings) is set to "Advanced".
|
||||
This module allows you to change the default Advanced Medical Settings, when [2.1 Medical Settings](#2.1-medical-settings) is set to "Advanced".
|
||||
|
||||
**Settings:**
|
||||
|
||||
|
||||
@ -13,10 +13,8 @@ parent: wiki
|
||||
|
||||
Downloaded ACE3 and have no idea where to start? This page serves as a document to help new players get started with things like the medical system, or how to adjust your scope.
|
||||
|
||||
### Table of contents
|
||||
1. [Vector 21](#vector-21)
|
||||
|
||||
### Vector 21
|
||||
### 1. Vector 21
|
||||
*Part of: ace_vector*
|
||||
|
||||
ACE3 adds a realistic depiction of the Vector 21 rangefinder to the game. Unlike other rangefinders, it doesn't just magically show you the range to your target, but in exchange allows you to do alot of things with it that the other choices in Arma do not offer. The Vector's functions include, but are not limited to:
|
||||
|
||||
@ -8,17 +8,17 @@ parent: wiki
|
||||
|
||||
You are hereby granted to use the ACE3 logos and imagery for promotional purposes. You are NOT allowed to use it commercially.
|
||||
|
||||
## Colors
|
||||
## 1. Colors
|
||||
|
||||
* <i class="icon icon-color icon-color-white"></i> White: `#ffffff, rgb(255, 255, 255)`
|
||||
* <i class="icon icon-color icon-color-black"></i> Black: `#000000, rgb(0, 0, 0)`
|
||||
* <i class="icon icon-color icon-color-red"></i> Red: `#ba2619, rgb(186, 38, 25)`
|
||||
|
||||
|
||||
## Logo
|
||||
## 2. Logo
|
||||
When using the ACE3 logo please do not stretch or skew it.
|
||||
|
||||
### Black
|
||||
### 2.1 Black
|
||||
|
||||
<img src="{{ site.baseurl }}/img/ace3-logo-black-small.png" height="30" />
|
||||
|
||||
@ -26,7 +26,7 @@ When using the ACE3 logo please do not stretch or skew it.
|
||||
* [PNG (transparent background)](https://github.com/KoffeinFlummi/ACE3/blob/master/extras/assets/logo/black/ACE3-Logo.png)
|
||||
* [EPS (vector file)](https://github.com/KoffeinFlummi/ACE3/blob/master/extras/assets/logo/black/ACE3-Logo.eps)
|
||||
|
||||
### White
|
||||
### 2.2 White
|
||||
|
||||
<img src="{{ site.baseurl }}/img/ace3-logo-white-small.png" height="30" style="background-color: black; padding: 2px;" />
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user