Removed training files
@ -1 +0,0 @@
|
|||||||
luadocumentor --d "Documentation" --s "%1\Moose Training\Stylesheet\stylesheet.css" "%1\Moose Development\Moose" "%1\Moose Development\dcs"
|
|
||||||
@ -1,80 +0,0 @@
|
|||||||
# Context
|
|
||||||
|
|
||||||
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 is currently still in alpha version, but will evolve over time. Right now, it has been updated to work with DCS world 1.5. and 2.0.
|
|
||||||
|
|
||||||
You can find the source of MOOSE here on GITHUB. It is free for download:
|
|
||||||
https://github.com/FlightControl-Master/MOOSE/
|
|
||||||
|
|
||||||
Note: MOOSE is complementary to [MIST](https://github.com/mrSkortch/MissionScriptingTools/releases), so if you use MIST in parallel with MOOSE objects, this should work.
|
|
||||||
|
|
||||||
# Goals
|
|
||||||
|
|
||||||
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. We can expect that MOOSE will evolve over time, as more missions will be designed within the framework.
|
|
||||||
|
|
||||||
# Mission Design with Moose
|
|
||||||
|
|
||||||
In order to create a mission using MOOSE, you'll have to include a file named **Moose.lua**:
|
|
||||||
|
|
||||||
1. Create a new mission in the DCS World Mission Editor.
|
|
||||||
2. In the mission editor, create a new trigger.
|
|
||||||
3. Name the trigger Moose Load and let it execute only at MISSION START.
|
|
||||||
4. Add an action DO SCRIPT FILE (without a condition, so the middle column must be empty).
|
|
||||||
5. In the action, browse to the **[Moose.lua](https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Mission%20Setup)** file in the **Moose Mission Setup** directory, and include this file within your mission.
|
|
||||||
6. Make sure that the "Moose Load" trigger is completely at the top of your mission.
|
|
||||||
|
|
||||||
Voila, MOOSE is now included in your mission. During the execution of this mission, all MOOSE classes will be loaded, and all MOOSE initializations will be exectuted before any other mission action is executed.
|
|
||||||
|
|
||||||
IMPORTANT NOTE: When a new version of MOOSE is released, you'll have to UPDATE the Moose.lua file in EACH OF YOUR MISSION.
|
|
||||||
This can be a tedious task, and for this purpose, a tool has been developed that will update the Moose.lua files automatically within your missions.
|
|
||||||
Refer to the tool at [Moose Mission Setup\Moose Mission Update](https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Mission%20Setup/Moose%20Mission%20Update) directory for further information included in the [READ.ME]() file.
|
|
||||||
|
|
||||||
|
|
||||||
# MOOSE LUA Classes
|
|
||||||
|
|
||||||
The following classes are currently embedded within MOOSE and can be included within your mission scripts:
|
|
||||||
|
|
||||||
* [BASE](Moose Training/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).
|
|
||||||
|
|
||||||
* [GROUP](Moose Training/Documentation/Group.html): This class wraps a DCS Group object within the simulator. It provides a more extensive API set, as well takes an abstraction of the complexity to give tasks, commands and set various options to DCS Groups. Additionally, the GROUP class provides a much richer API to identify various properties of the DCS Group. For each DCS Group created object within a running mission, a GROUP object will be created automatically, that is managed within the DATABASE, under the _DATABASE object.
|
|
||||||
|
|
||||||
* [UNIT](Moose Training/Documentation/Unit.html): This class wraps a DCS Unit object within the simulator. It provides a more extensive API set, as well takes an abstraction of the complexity to give commands and set various options to DCS Units. Additionally, the UNIT class provides a much richer API to identify various properties of the DCS Unit. For each DCS Unit object created within a running mission, a UNIT object will be created automatically, that is stored within the DATABASE, under the _DATABASE object.
|
|
||||||
|
|
||||||
* [CLIENT](Moose Training/Documentation/Client.html): This class wraps a DCS Unit object within the simulator, which has a skill Client or Player. The CLIENT class derives from the UNIT class, thus contains the complete UNIT API set, and additionally, the CLIENT class provides an API set to manage players joining or leaving clients, sending messages to players, and manage the state of units joined by players. For each DCS Unit object created within a running mission that can be joined by a player, a CLIENT object will be created automatically, that is stored within the DATABASE, under the _DATABASE object.
|
|
||||||
|
|
||||||
* [DATABASE](Moose Training/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.
|
|
||||||
|
|
||||||
* [SPAWN](Moose Training/Documentation/Spawn.html): Spawn new groups (and units) during mission execution.
|
|
||||||
|
|
||||||
* [ESCORT](Moose Training/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](Moose Training/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.
|
|
||||||
|
|
||||||
|
|
||||||
# MOOSE Tutorials and Examples
|
|
||||||
|
|
||||||
You can download [test missions](https://github.com/FlightControl-Master/MOOSE/tree/master/Test%20Missions) to have examples and learn the syntax and usage of the MOOSE classes.
|
|
||||||
|
|
||||||
There are [Video Tutorials](https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg) on my YOUTUBE channel on which you can learn some coding aspects with mission execution demos, as well as some of the tooling and internal mechanisms within MOOSE.
|
|
||||||
|
|
||||||
|
|
||||||
In the triggers section, there is a flag (9999) that will decide how MOOSE will be loaded. When flag 9999 is set, MOOSE will be dynamically loaded. When flag 9999 is off, MOOSE will be loaded embedded. Note that when loaded embedded, **your mission must include the last Moose_Embedded.lua file**. So, ensure that the last file is included in the DO SCRIPT section when MOOSE got an update!
|
|
||||||
|
|
||||||
# Credits
|
|
||||||
|
|
||||||
Note that the framework is based on code i've written myself, but some of it is also based on code that i've seen as great scripting code and ideas, and which i've revised. 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): Grimes, Prof_Hilactic, xcom, the 476 virtual squadron team, ...
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
2. Prof_hilactic & others:
|
|
||||||
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
|
|
||||||
|
|
||||||
3. xcom
|
|
||||||
His contribution is related to the eStatHandler. 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
|
|
||||||
|
|
||||||
4. The rest of the framework functions and class definitions were my own developments. Trust i've spent hours and hours investigating, trying and writing and documenting code building this framework.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Hope you think the idea is great and useful.
|
|
||||||
|
Before Width: | Height: | Size: 182 KiB |
|
Before Width: | Height: | Size: 150 KiB |
|
Before Width: | Height: | Size: 220 KiB |
|
Before Width: | Height: | Size: 232 KiB |
|
Before Width: | Height: | Size: 225 KiB |
|
Before Width: | Height: | Size: 172 KiB |
|
Before Width: | Height: | Size: 174 KiB |
|
Before Width: | Height: | Size: 462 KiB |
@ -1,224 +0,0 @@
|
|||||||
|
|
||||||
Hi everyone,
|
|
||||||
|
|
||||||
It's FlightControl here ... It is been quite a ride ... But here it is, the release of the MOOSE framework for DCS World is a fact. This release is adding the following functionality to MOOSE, on top of the pre-release version:
|
|
||||||
|
|
||||||
[list]
|
|
||||||
[*] Task orchestration: CommandCenters, Missions, Tasks, Task Actions ...
|
|
||||||
[*] AI balancing and AI bahaviour. AIBalancer, Patrol Zones, ...
|
|
||||||
[*] Cargo handling: Board, Unboard, Transfer cargo of different types.
|
|
||||||
[*] Dynamic detection and task assignment through FACs.
|
|
||||||
[*] Additional functions in existing classes.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
Preparing this release was a large work ... I hope you like using it.
|
|
||||||
|
|
||||||
There are various test missions created to demonstrate the framework. It is worth to have a close look to the lua files for each test mission. You can find in each directory to lua file that is embedded in the test mission.
|
|
||||||
The documentation is not yet up-to-date, but that will improve next year. On top, I plan to create training videos for you to demonstrate the capabilities of the introduced new concepts. These things take time and a good preparation, so pls be patient.
|
|
||||||
|
|
||||||
[size=24][b][u]API Changes![/u][/b][/size]
|
|
||||||
|
|
||||||
The [color=blue]good[/color] and [color=red]bad [/color]news is that there are a couple of API changes that I had to push through. The reason why these API changes appear in the release is, I made some bad design decisions in the past, and I've made the interface more consistent. I would like you to review and update your missions to adapt and incorporate these API changes. Implementing these API changes can be quickly done I believe ... The changes are minor.
|
|
||||||
|
|
||||||
In a nuttshell:
|
|
||||||
- I changed the name of the SPAWN initialization functions, adding [color=blue]Init[/color] to the name. I wanted to make sure that the difference between Initialization and Spawning in the SPAWN methods were clear, because many people had questions and were confused! Please refer to the SPA-1xx for a demonstration on these new Init functions (they are the same, only the name changed).
|
|
||||||
- Spawning of new units can be done now from a Unit location, a Static location, a PointVec2 location, a PointVec3 location and a Zone location. In order to make the interface consistent over all these functions, I added a new function called [color=blue]InitRandomizeUnits( RandomizeUnits, OuterRadius, InnerRadius )[/color] and added, revised the APIs of the Spawning functions. Please refer to the test missions SPA-3xx for demo scripts to use these functions.
|
|
||||||
- Zones can now also be randomized during Spawning using the method [color=blue]InitRandomizeZones( SpawnZones )[/color]. Please refer to the test mission SPA-220 for a demonstration to use this function.
|
|
||||||
|
|
||||||
Here are the changes:
|
|
||||||
|
|
||||||
[list]
|
|
||||||
[*][b]BASE[/b]
|
|
||||||
|
|
||||||
[list]
|
|
||||||
[*]DCS Event handling functions have been added to the base class. These functions start with the [color=blue]OnEvent...[/color] prefix. These functions now allow you to DCS events in a class like when a birth of a unit happens, or when a crash happens etc.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[*][b]SPAWN[/b]
|
|
||||||
|
|
||||||
[list]
|
|
||||||
[*][color=blue]OnSpawnGroup[/color]( SpawnCallBackFunction, ... ) replaces [color=red]SpawnFunction[/color]( SpawnCallBackFunction, ... )
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[list]
|
|
||||||
[*][b]SpawnInZone[/b]( Zone, [color=blue]RandomizeGroup[/color], SpawnIndex ) replaces SpawnInZone( Zone, [color=red]RandomizeUnits, OuterRadius, InnerRadius,[/color] SpawnIndex )
|
|
||||||
[*][b]SpawnFromVec3[/b]( Vec3, SpawnIndex ) replaces SpawnFromVec3( Vec3, [color=red]RandomizeUnits, OuterRadius, InnerRadius,[/color] SpawnIndex )
|
|
||||||
[*][b]SpawnFromVec2[/b]( Vec2, SpawnIndex ) replaces SpawnFromVec2( Vec2, [color=red]RandomizeUnits, OuterRadius, InnerRadius,[/color] SpawnIndex )
|
|
||||||
[*][b]SpawnFromUnit[/b]( SpawnUnit, SpawnIndex ) replaces SpawnFromUnit( SpawnUnit, [color=red]RandomizeUnits, OuterRadius, InnerRadius,[/color] SpawnIndex )
|
|
||||||
[*][b]SpawnFromStatic[/b]( SpawnUnit, SpawnIndex ) replaces SpawnFromStatic( SpawnStatic, [color=red]RandomizeUnits, OuterRadius, InnerRadius,[/color] SpawnIndex )
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
|
|
||||||
[list]
|
|
||||||
[*][color=blue][b]InitRandomizeUnits[/b]( RandomizeUnits, OuterRadius, InnerRadius )[/color] added.
|
|
||||||
[*][color=blue][b]InitLimit[/b][/color]( SpawnMaxUnitsAlive, SpawnMaxGroups ) replaces [color=red]Limit[/color]( SpawnMaxUnitsAlive, SpawnMaxGroups )
|
|
||||||
[*][color=blue][b]InitArray[/b][/color]( SpawnAngle, SpawnWidth, SpawnDeltaX, SpawnDeltaY ) replaces [color=red]Array[/color]( SpawnAngle, SpawnWidth, SpawnDeltaX, SpawnDeltaY )
|
|
||||||
[*][color=blue][b]InitRandomizeRoute[/b][/color]( SpawnStartPoint, SpawnEndPoint, SpawnRadius, SpawnHeight ) replaces [color=red]RandomizeRoute[/color]( SpawnStartPoint, SpawnEndPoint, SpawnRadius, SpawnHeight )
|
|
||||||
[*][color=blue][b]InitRandomizeTemplate[/b][/color]( SpawnTemplatePrefixTable ) replaces [color=red]RandomizeTemplate[/color]( SpawnTemplatePrefixTable )
|
|
||||||
[*][color=blue][b]InitUnControlled[/b][/color]() replaces [color=red]UnControlled[/color]()
|
|
||||||
[*][color=blue][b]InitCleanUp[/b][/color]( SpawnCleanUpInterval ) replaces [color=red]CleanUp[/color]( SpawnCleanUpInterval )
|
|
||||||
[*][color=blue][b]InitRandomizeZones[/b]( SpawnZones )[/color] added
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
|
|
||||||
[*][b]AIBALANCER[/b]
|
|
||||||
[list]
|
|
||||||
[*]Has been completely reworked. I don't think anybody has been using this class beside hijack.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
|
|
||||||
[*][b]PATROLZONE[/b]:
|
|
||||||
[list]
|
|
||||||
[*]Has been completely reworked. I don't think anybody has been using this class beside hijack.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
|
|
||||||
[*][b]POINT_VEC3[/b] and references in other classes methods to POINT_VEC3 objects:
|
|
||||||
[list]
|
|
||||||
[*][color=blue]Translate( Distance, Angle )[/color]added.
|
|
||||||
[*]Replaced methods ending with [color=red]Point_Vec3[/color]() to [color=blue]Vec3[/color]() where the code manages a Vec3. Replaced all references to the method.
|
|
||||||
[*]Replaced method [color=red]Point_Vec2()[/color] to [color=blue]Vec2[/color]() where the code manages a Vec2. Replaced all references to the method.
|
|
||||||
[*]Replaced method [color=red]Random_Point_Vec3()[/color] to [color=blue]RandomVec3[/color]() where the code manages a Vec3. Replaced all references to the method.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
|
|
||||||
[*][b]SCHEDULER[/b] has been reworked, see below.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[size=24][b][u]What's new![/u][/b][/size]
|
|
||||||
|
|
||||||
Find below a comprehensive summary of the MOOSE new features in this release:
|
|
||||||
|
|
||||||
[size=22][b][u]1. Task Orchestration[/u][/b][/size]
|
|
||||||
|
|
||||||
[size=18][b][u]1.1. Comand Centers[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]COMMANDCENTER[/b]: Governs the communication and existence of Missions, Tasks and Actions for a Coalition.
|
|
||||||
[list=1]
|
|
||||||
[*]Create a new CommandCenter. Multiple CommandCenters can be defined within one Mission.
|
|
||||||
[*]Maintain Missions. Add, Remove and CleanUp Missions, and undelying Tasks and Actions.
|
|
||||||
[*]Provide a navigation menu to orchestrate for different groups the Tasking.[*]Send Reports to players of the Tasks within all Missions of a CommandCenter.
|
|
||||||
[*]Send Messages to all players alive within all Missions of a CommandCenter.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[size=18][b][u]1.2. Missions[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]MISSION[/b]: Governs the process flow of the Mission, Tasks and Actions for a CommandCenter for a Coalition.[list=1]
|
|
||||||
[*]Create a new Mission for a CommandCenter.
|
|
||||||
[*]Provide Mission status flow, implemented through a Finite State Machine.
|
|
||||||
[*]Expose Mission event- and state functions to influence the Mission orchestration.
|
|
||||||
[*]Maintain Tasks: Add, Remove and CleanUp Tasks and underlying Actions.
|
|
||||||
[*]Send Reports to players of the Tasks within the Mission.
|
|
||||||
[*]Send Messages to all players within the Mission.
|
|
||||||
[*]Attach a Scoring and event log implemented through the SCORING class.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[size=18][b][u]1.3. Tasks[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]TASK[/b]: Governs the process flow of the Task state and the execution of the Taskprocess and hierarchical processes by players.
|
|
||||||
[list=1]
|
|
||||||
[*]Create a new Task for a Mission governed by a CommandCenter.
|
|
||||||
[*]Provide Task status flow, implemented through a Finite State Machine.
|
|
||||||
[*]Expose Task event- and state functions to influence the Task orchestration.
|
|
||||||
[*]Create a Task Actions, implemented through a Finite State Machine Process, that the players will need to follow when the Task is Assigned to a Player (Unit).
|
|
||||||
[*]Maintain Tasks: Add, Remove and CleanUp Task Actions and hierarchical Actions.
|
|
||||||
[*]Expose Mission event- and state functions to influence the Task state.
|
|
||||||
|
|
||||||
- Flag a Task as Planned.
|
|
||||||
- Flag a Task as Assigned.
|
|
||||||
- Flag a Task as Successful.
|
|
||||||
- Flag a Task as Failed.
|
|
||||||
- Flag a Task as Aborted.
|
|
||||||
- Flag a Task as Cancelled.
|
|
||||||
[*]Send Reports of the Task to the players.
|
|
||||||
[*]Send Messages to the player executing and assigned to the Task.
|
|
||||||
[*]Create a Task Action workbook.
|
|
||||||
[*]Provide a mechanism to assign players to the Task.
|
|
||||||
[*]Provide a mechanism to abort players from the Task.
|
|
||||||
[*]Each assigned player to the Task, will have a Task Action flow executing, governed by the TASK object.
|
|
||||||
[*]Provide a mechanism to attach a Scoring scheme when certain states are reached in the Task and in the Task Action flow.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[size=18][b][u]1.4. Task Actions[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]ACT_ASSIGN[/b], [b]ACT_ROUTE[/b], [b]ACT_ACCOUNT[/b], [b]ACT_SMOKE[/b]: Governs Task Action Subroutines that can be embedded within a Task Action flow. These ACT_ classes will be further enhanced and expanded now the baseline of MOOSE is there. This will result in mission designed being able to quickly combine these actions to implement different Task flows.
|
|
||||||
[list=1]
|
|
||||||
[*]Create a new Task Action Subroutine for a Task Action flow, governed by a Task.
|
|
||||||
[*]ACT_ASSIGN: Base class to assign a player to a Task. If the player is in a Group that is already assigned to the Task, the Player will be assigned automatically.
|
|
||||||
[*]ACT_ASSIGN_ACCEPT: Assign a player to a Task, and automatically Accept the Task.
|
|
||||||
[*]ACT_ASSIGN_MENU_ACCEPT: Assign a player to a Task, and let the Player Accept or Reject the Task within 30 seconds.
|
|
||||||
[*]ACT_ROUTE: Base class to route a player.
|
|
||||||
[*]ACT_ROUTE_ZONE: Route a player to a zone.
|
|
||||||
[*]ACT_ACCOUNT: Base class to "account" events or things within a running mission.
|
|
||||||
[*]ACT_ACCOUNT_DEADS: Account if certain DCS Units are dead.
|
|
||||||
[*]ACT_ASSIST: Base class to assist players with certain actions through the menu.
|
|
||||||
[*]ACT_ASSIST_SMOKE: Assist players with smoking target areas while in flight through the menu.
|
|
||||||
[*]ACT_...: Expect in the future more ACT classes to be created and added to the MOOSE framework. It is upon our creativity to identify good functions to be added.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[size=22][b][u]2. Finite State Machines[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]FSM[/b], [b]FSM_CONTROLLABLE[/b], [b]FSM_ACTION[/b], [b]FSM_TASK[/b], [b]FSM_SET[/b]: Finite State Machine base classes that implement the necessary functionality to realise a workflow following various state transitions triggered through events being fired externally or internally within the FSM implementation.
|
|
||||||
[list=1]
|
|
||||||
[*]FSM: The Finitite State Machine base class. It provides functions to create a fsm workflow, adding state transitions schemes and adding sub processes.
|
|
||||||
[*]FSM_CONTROLLABLE: An fsm governing the workflow for a Controllable object within DCS, which can be a UNIT or a GROUP.
|
|
||||||
[*]FSM_PROCESS: An fsm governing a workflow for a Controllable object within DCS for a Task. Note that all ACT_... classes are derived classes from FSM_PROCESS, implementing an fsm to govern the Player unit for the Task given.
|
|
||||||
[*]FSM_TASK: An fsm governing a workflow for a Task. Note that the TASK class is derived from FSM_TASK.
|
|
||||||
[*]FSM_SET: An fsm governing a workflow for a Set.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[size=22][b][u]3. Balance and Control AI[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]AIBALANCER[/b]: Balances AI within a Mission. It is up to the mission designer to capture the different AIBalancer events, and attach different AI processes to accomodate AI behaviour.
|
|
||||||
[list=1]
|
|
||||||
[*]Spawn new AI as there aren't players in the Mission. In other words, spawn as many AI required to simulate player behaviour.
|
|
||||||
[*]Attach various AI processes to let the AI execute certain tasks.
|
|
||||||
[*]Implements an fsm to accomodate a workflow to let the mission designer attach various AI workflows for AI implementation behaviour.
|
|
||||||
[*]PATROLZONE:
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[b]PATROLZONE[/b]: Is an AI behaviour class, governing AI to patrol a zone, used by the AI balancer.
|
|
||||||
[list=1]
|
|
||||||
[*]Provide an fsm process, implementing AI patrol behaviour so that AI is patrolling a zone for a defined time.
|
|
||||||
[*]Expose various event functions to influence the AI patrol behaviour.
|
|
||||||
[*]The PATROLZONE class can be used in AIBALANCER to simulate players.
|
|
||||||
[/list]
|
|
||||||
|
|
||||||
[size=22][b][u]4. Cargo Handling[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]CARGO[/b]: Cargo Handling of CONTROLLABLE object, thus UNITs and GROUPs. CARGO provides a dynamic way to Load, Unload, Board, UnBoard and Transfer Cargo between Carriers. [u]The cargo handling of units is animated, that means, you'll see the units moving towards or from the carriers ...
|
|
||||||
[/u][list=1]
|
|
||||||
[*]Board Cargo to a Carrier.
|
|
||||||
[*]Unboard Cargo from a Carrier to a point.
|
|
||||||
[*]Transfer Cargo from a Carrier to another Carrier.
|
|
||||||
[*]CARGO is the base class implementing the cargo workflow.
|
|
||||||
[*]CARGO_GROUP: Implements the Cargo handling for a GROUP.
|
|
||||||
[*]CARGO_UNIT: Implements the Cargo handling for one UNIT.
|
|
||||||
[*]CARGO_GROUPED: Implements the Cargo handling for multiple GROUPs.
|
|
||||||
[*]CARGO_PACKAGE: Under construction. This would simulate a package being carried by a carrier.
|
|
||||||
[/list]
|
|
||||||
Note: There are various Task Actions (ACT_) classes planned that would allow to deploy and pickup cargo in a battle field.
|
|
||||||
Note: There are various AI_ classes planned that would allow to deploy and pickup cargo in a battlefield.[/td]
|
|
||||||
|
|
||||||
[size=22][b][u]5. Scheduling[/u][/b][/size]
|
|
||||||
|
|
||||||
[b]SCHEDULER[/b]: The scheduling of methods has been intensively reworked. In the previous version of MOOSE, each SCHEDULER object controlled the scheduling of the method provided. However, with the new SCHEDULER implementation, the actually scheduling is now done by a SCHEDULEDISPATCHER class, which has one instance within the MOOSE framework, under _SCHEDULEDISPATCHER... SCHEDULER has some minor changes to the API. One of them is that SCHEDULER now allows to schedule more than one repeated schedule. When the method SCHEDULE.Schedule() is called, a ScheduleID is returned. This ScheduleID can then be used to Stop or (Re-)Start the schedule using the SCHEDULER object and the ScheduleID. The actual object controlling all the schedules is _SCHEDULEDISPATCHER.
|
|
||||||
|
|
||||||
|
|
||||||
[size=24][b][u]Other comments ...[/u][/b][/size]
|
|
||||||
|
|
||||||
There are many more changes done within the framework, but these are very technical and hidden from the API set that the users will use. Some of the work that was done includes: rework scheduling, adding a scheduler dispatcher.
|
|
||||||
|
|
||||||
There is still some work to be done on the [b]TASK_DISPATCHER[/b], but that will be done the coming weeks, so don't spend too much time on that for the moment ...
|
|
||||||
|
|
||||||
Also, this release builds the foundation of many many other classes to come. Now that we have state machines and the object model is now more or less stable, other functions can be built upon this framework. It would be great that a community would see the benefits of this development and endorse it, like many have already done.
|
|
||||||
|
|
||||||
The documentation is not completely up-to-date, but that will come and flatten out the next weeks.
|
|
||||||
Also, demonstration videos will be published on my youtube channel next year to demo some of the new functions, and I'll rework a few of the older versions.
|
|
||||||
|
|
||||||
If you have problems using this release and somehow feel blocked, you can use the previous commit on the master branch. Just click in GITHUB on the previous commit, sync and you'll be fine.
|
|
||||||
|
|
||||||
I hope you will have the same pleasure using this framework as the creators had making it.
|
|
||||||
|
|
||||||
Thanks all;
|
|
||||||
FC
|
|
||||||