MOOSE - Mission Object Oriented Scripting Framework

for BASE class, BASE:TraceOnOff(TraceOnOff) under "usage" it states:

-- Switch the tracing On
BASE:TraceOn( true )
-- Switch the tracing Off 
BASE:TraceOn( false )

Should have figured out anyway, hope it works now! :)

 

Okay, will fix that and it will be populated with the next release.

Maybe as a feedback let the community know how you experience the tracing functions usage.

Fc

Hi!

Just started looking into MOOSE and read a bit through the Spawn class, but is there a way to dynamically create groups without defining templates beforehand for them?

Hi!

 

Just started looking into MOOSE and read a bit through the Spawn class, but is there a way to dynamically create groups without defining templates beforehand for them?

No, you need to create templates. What's your thinking? Why this question?

No, you need to create templates. What's your thinking? Why this question?

I think it would more dynamic and it would be possible to create more random missions.

Creating groups in code would be easier for me than to create a few templates and than randomly choose one of them, instead I would write me a function that creates me random groups that I could spawn.

I think this is possible in terms of the dcs framework or?

I'm quite aware that it is cumbersome to create groups/units from code, but with a few helper functions/classes it gets manageable.

Further you could define such group templates with functions snippets and carry them to other functions(via doscriptfile) instead to recreate/copy the editor templates. I have done something similar in my pydcs(https://github.com/pydcs/dcs) framework.

I think it would more dynamic and it would be possible to create more random missions.

Creating groups in code would be easier for me than to create a few templates and than randomly choose one of them, instead I would write me a function that creates me random groups that I could spawn.

 

I think this is possible in terms of the dcs framework or?

 

I'm quite aware that it is cumbersome to create groups/units from code, but with a few helper functions/classes it gets manageable.

 

Further you could define such group templates with functions snippets and carry them to other functions(via doscriptfile) instead to recreate/copy the editor templates. I have done something similar in my pydcs(https://github.com/pydcs/dcs) framework.

Yup. This is an idea, but how to realize it properly is another question. It should be designed in such a way that it is transparent and if ED adds or deletes unit types to the DCS product, that it does not require modifications in the MOOSE framework...

I think a function or two would not hurt making new groups, but then again, ... need to assess the impact on the code for such design. For the moment we can put it on the todo list in github. Right now the framework is tackling some other ideas and problems with higher urgency. Want to get that release out first ...

Thanks for the feedback.

kind regards,

FC

There's quite a lot of info that's needed to create a flight, on paper, it's a longish array, check the mist documentation to see that in action. A template is easier in practice, you want to write minimal code, literally 5 lines gets you enormous potenital in MOOSE as it stands. But what I think you are asking for is something that makes randomised flights, picks between the templates, in which case a complete module design from Moose might fit your needs. And i'm not sure how to implement such randomness either and in what type of framewrk it should exist, ie trainign scenarios, random mission generation or something. There's nothing quite like that yet, although with some thought about how you want it I'm sure FC would think about it (in the new year once the release is out of course).

Hi everyone,

It is been quite a ride, rather bumpy in fact ... But here it is, the next 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:

• 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.
  

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 that explains the script.

The documentation of these test missions 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.

API Changes!

The good and bad 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 Init 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 InitRandomizeUnits( RandomizeUnits, OuterRadius, InnerRadius ) 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 InitRandomizeZones( SpawnZones ). Please refer to the test mission SPA-220 for a demonstration to use this function.

Here are the changes:

• BASE
  
  • DCS Event handling functions have been added to the base class. These functions start with the OnEvent... 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.
    

   

  [*]SPAWN

  • OnSpawnGroup( SpawnCallBackFunction, ... ) replaces SpawnFunction( SpawnCallBackFunction, ... )
    

   

   

  • SpawnInZone( Zone, RandomizeGroup, SpawnIndex ) replaces SpawnInZone( Zone, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex )
    
  • SpawnFromVec3( Vec3, SpawnIndex ) replaces SpawnFromVec3( Vec3, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex )
    
  • SpawnFromVec2( Vec2, SpawnIndex ) replaces SpawnFromVec2( Vec2, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex )
    
  • SpawnFromUnit( SpawnUnit, SpawnIndex ) replaces SpawnFromUnit( SpawnUnit, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex )
    
  • SpawnFromStatic( SpawnUnit, SpawnIndex ) replaces SpawnFromStatic( SpawnStatic, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex )
    

   

   

  • InitRandomizeUnits( RandomizeUnits, OuterRadius, InnerRadius ) added.
    
  • InitLimit( SpawnMaxUnitsAlive, SpawnMaxGroups ) replaces Limit( SpawnMaxUnitsAlive, SpawnMaxGroups )
    
  • InitArray( SpawnAngle, SpawnWidth, SpawnDeltaX, SpawnDeltaY ) replaces Array( SpawnAngle, SpawnWidth, SpawnDeltaX, SpawnDeltaY )
    
  • InitRandomizeRoute( SpawnStartPoint, SpawnEndPoint, SpawnRadius, SpawnHeight ) replaces RandomizeRoute( SpawnStartPoint, SpawnEndPoint, SpawnRadius, SpawnHeight )
    
  • InitRandomizeTemplate( SpawnTemplatePrefixTable ) replaces RandomizeTemplate( SpawnTemplatePrefixTable )
    
  • InitUnControlled() replaces UnControlled()
    
  • InitCleanUp( SpawnCleanUpInterval ) replaces CleanUp( SpawnCleanUpInterval )
    
  • InitRandomizeZones( SpawnZones ) added
    

   

  [*]AIBALANCER

  • Has been completely reworked. I don't think anybody has been using this class beside hijack.
    

   

  [*]PATROLZONE:

  • Has been completely reworked. I don't think anybody has been using this class beside hijack.
    

   

  [*]POINT_VEC3 and references in other classes methods to POINT_VEC3 objects:

  • Translate( Distance, Angle )added.
    
  • Replaced methods ending with Point_Vec3() to Vec3() where the code manages a Vec3. Replaced all references to the method.
    
  • Replaced method Point_Vec2() to Vec2() where the code manages a Vec2. Replaced all references to the method.
    
  • Replaced method Random_Point_Vec3() to RandomVec3() where the code manages a Vec3. Replaced all references to the method.
    

   

  [*]SCHEDULER has been reworked, see below.

What's new!

Find below a comprehensive summary of the MOOSE new features in this release:

1. Task Orchestration

1.1. Comand Centers

COMMANDCENTER: Governs the communication and existence of Missions, Tasks and Actions for a Coalition.

1. Create a new CommandCenter. Multiple CommandCenters can be defined within one Mission.
   
2. Maintain Missions. Add, Remove and CleanUp Missions, and undelying Tasks and Actions.
   
3. Provide a navigation menu to orchestrate for different groups the Tasking.
   
4. Send Reports to players of the Tasks within all Missions of a CommandCenter.
   
5. Send Messages to all players alive within all Missions of a CommandCenter.
   

1.2. Missions

MISSION: Governs the process flow of the Mission, Tasks and Actions for a CommandCenter for a Coalition.

1. Create a new Mission for a CommandCenter.
   
2. Provide Mission status flow, implemented through a Finite State Machine.
   
3. Expose Mission event- and state functions to influence the Mission orchestration.
   
4. Maintain Tasks: Add, Remove and CleanUp Tasks and underlying Actions.
   
5. Send Reports to players of the Tasks within the Mission.
   
6. Send Messages to all players within the Mission.
   
7. Attach a Scoring and event log implemented through the SCORING class.
   

1.3. Tasks

TASK: Governs the process flow of the Task state and the execution of the Taskprocess and hierarchical processes by players.

1. Create a new Task for a Mission governed by a CommandCenter.
   
2. Provide Task status flow, implemented through a Finite State Machine.
   
3. Expose Task event- and state functions to influence the Task orchestration.
   
4. 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).
   
5. Maintain Tasks: Add, Remove and CleanUp Task Actions and hierarchical Actions.
   
6. 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.
   
7. Send Reports of the Task to the players.
   
8. Send Messages to the player executing and assigned to the Task.
   
9. Create a Task Action workbook.
   
10. Provide a mechanism to assign players to the Task.
    
11. Provide a mechanism to abort players from the Task.
    
12. Each assigned player to the Task, will have a Task Action flow executing, governed by the TASK object.
    
13. Provide a mechanism to attach a Scoring scheme when certain states are reached in the Task and in the Task Action flow.
    

1.4. Task Actions

ACT_ASSIGN, ACT_ROUTE, ACT_ACCOUNT, ACT_SMOKE: 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.

1. Create a new Task Action Subroutine for a Task Action flow, governed by a Task.
   
2. 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.
   
3. ACT_ASSIGN_ACCEPT: Assign a player to a Task, and automatically Accept the Task.
   
4. ACT_ASSIGN_MENU_ACCEPT: Assign a player to a Task, and let the Player Accept or Reject the Task within 30 seconds.
   
5. ACT_ROUTE: Base class to route a player.
   
6. ACT_ROUTE_ZONE: Route a player to a zone.
   
7. ACT_ACCOUNT: Base class to "account" events or things within a running mission.
   
8. ACT_ACCOUNT_DEADS: Account if certain DCS Units are dead.
   
9. ACT_ASSIST: Base class to assist players with certain actions through the menu.
   
10. ACT_ASSIST_SMOKE: Assist players with smoking target areas while in flight through the menu.
    
11. 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.
    

2. Finite State Machines

FSM, FSM_CONTROLLABLE, FSM_ACTION, FSM_TASK, FSM_SET: 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.

1. FSM: The Finitite State Machine base class. It provides functions to create a fsm workflow, adding state transitions schemes and adding sub processes.
   
2. FSM_CONTROLLABLE: An fsm governing the workflow for a Controllable object within DCS, which can be a UNIT or a GROUP.
   
3. 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.
   
4. FSM_TASK: An fsm governing a workflow for a Task. Note that the TASK class is derived from FSM_TASK.
   
5. FSM_SET: An fsm governing a workflow for a Set.
   

3. Balance and Control AI

AI_BALANCER: 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.

1. Spawn new AI as there aren't players in the Mission. In other words, spawn as many AI required to simulate player behaviour.
   
2. Attach various AI processes to let the AI execute certain tasks.
   
3. Implements an fsm to accomodate a workflow to let the mission designer attach various AI workflows for AI implementation behaviour.
   
4. PATROLZONE:
   

AI_PATROLZONE: Is an AI behaviour class, governing AI to patrol a zone, used by the AI balancer.

1. Provide an fsm process, implementing AI patrol behaviour so that AI is patrolling a zone for a defined time.
   
2. Expose various event functions to influence the AI patrol behaviour.
   
3. The PATROLZONE class can be used in AIBALANCER to simulate players.
   

4. Cargo Handling

AI_CARGO: Cargo Handling of CONTROLLABLE object, thus UNITs and GROUPs. CARGO provides a dynamic way to Load, Unload, Board, UnBoard and Transfer Cargo between Carriers. The cargo handling of units is animated, that means, you'll see the units moving towards or from the carriers ...

1. Board Cargo to a Carrier.
   
2. Unboard Cargo from a Carrier to a point.
   
3. Transfer Cargo from a Carrier to another Carrier.
   
4. CARGO is the base class implementing the cargo workflow.
   
5. CARGO_GROUP: Implements the Cargo handling for a GROUP.
   
6. CARGO_UNIT: Implements the Cargo handling for one UNIT.
   
7. CARGO_GROUPED: Implements the Cargo handling for multiple GROUPs.
   
8. CARGO_PACKAGE: Under construction. This would simulate a package being carried by a carrier.
   

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]

5. Scheduling

SCHEDULER: 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.

Other comments ...

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 TASK_DISPATCHER, 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

All,

New video is created explaining the first concepts of Finite State Machines to use in your mission design. It is not yet a full blown explanation, but more like an introduction of it.

FC

Thx FC, glad to see you getting back into it.

Sent from my iPhone using Tapatalk

All,

 

New video is created explaining the first concepts of Finite State Machines to use in your mission design. It is not yet a full blown explanation, but more like an introduction of it.

 

.

 

FC

Fantastic news FC.

The documentation also is great and comprehensive. Is there any possibility to have such a document offline in pdf format to be printable?

Awesome work man! Really Awesome! I just starting using this and already see a huge potential. The ability to do so much with such little effort is amazing! This is going to make mission building not only easier but I feel like it will change how missions are made, allow them to be more interactive and less linear.

Really great job, looking forward to getting some really innovative missions off the ground with this!

Fantastic news FC.

 

The documentation also is great and comprehensive. Is there any possibility to have such a document offline in pdf format to be printable?

I generate the documentation from the lua source code using luadocumentor.

I have been looking in the past if this documentation tool can also generate LaTeX, but it doesn't. It would be good to have. Maybe I'll post a request on the LDT forums for this.

Concerning the documentation quality, it varies a bit.

The new modules introduced (see previous mails) lack a bit on the documentation quality, but this will be fixed within a couple of weeks. Because the documentation is online generated (here), with each deployment improvement, the documentation will get fixed eventually also for the new modules. It is a lot of work to document all.

Don't know how far you are in coding lua, but if you can read code, I suggest you look at the example missions for the moment, and check the code in the framework.

The earlier people are using these new capabilities, the faster the child deseases will get out, and will become more fun for others to use.

kind regards,

FC

Awesome work man! Really Awesome! I just starting using this and already see a huge potential. The ability to do so much with such little effort is amazing! This is going to make mission building not only easier but I feel like it will change how missions are made, allow them to be more interactive and less linear.

 

Really great job, looking forward to getting some really innovative missions off the ground with this!

Thanks for your kind words and appreciation :).

I hope you will enjoy the framework building missions as I have building it.

FC

New youtube video created explaining the concepts behind the Tasking framework.

Forgive my non-native English.

Also, this stuff is not so easy to explain, so pls be patient.

Maybe during the couple of days I can make a quick demo how to set a CommandCenter, Mission, Task and Task Process.

Ping when you have questions or comments (skype, forum, slack).

FC

Hi FlightControl,

As per your pointer on YT I am checking in here! Thanks for creating MOOSE and even better; making such an effort to properly explain and document its features.

I am wondering wether people would benefit from taking a general LUA scripting course (for example the book the original engineer of the language has written) or if that would be too much overkill? In other words; are you expecting people to not have any experience with the language as you document MOOSE's features?

Will it be a one-stop-shop so to speak catering for all mission creation and scripting needs from novice to advanced?

I have followed your setup videos yesterday and I can confirm that my editing environment has been setup and it working!

Anyway, I am excited to see you have *just* put up a new video. I'll be sure to watch that one later today!

Hope you are recovering well and let me apologise in advance for the quite possible *many* noob questions fired at you from my side. :)

Cheers!

Hi FlightControl,

 

As per your pointer on YT I am checking in here! Thanks for creating MOOSE and even better; making such an effort to properly explain and document its features.

I am wondering wether people would benefit from taking a general LUA scripting course (for example the book the original engineer of the language has written) or if that would be too much overkill? In other words; are you expecting people to not have any experience with the language as you document MOOSE's features?

Will it be a one-stop-shop so to speak catering for all mission creation and scripting needs from novice to advanced?

 

I have followed your setup videos yesterday and I can confirm that my editing environment has been setup and it working!

 

Anyway, I am excited to see you have *just* put up a new video. I'll be sure to watch that one later today!

 

Hope you are recovering well and let me apologise in advance for the quite possible *many* noob questions fired at you from my side. :)

 

Cheers!

Dutch baron and myself discussed the topic this evening during a beer. He advised to make a couple of "lua for dummies" videos to expand the reach of the possible audience. This is a good idea and will create some... Next year though...

@all, Wish you all some peaceful days the coming weeks.

Be with the ones who are near to you.

Wonderful! Have a great time Sven

Hey FlightControl.

I have watched your vids etc and they are excellent and really informative, but as the subject material is a little abstract and quite hard to get to grips with for a newbie (especially if they have no previous coding experience)

a "LUA coding for dummies" guide sounds like a great idea.

I really appreciate all the hard work you are putting into this endevour.

In the meantime take it easy and Have a great Christmas and a happy new year.

All the best

SD

Thanks FlightControl! I am looking forward to digging into the new release in the new year!

Quote:

Originally Posted by RAF_Raven

Hey FlightControl, first I want to thank you for all the hard work you have done on MOOSE!

I have a quick question. Is it possible to SpawnScheduled or ReSpawn patrol groups using AI_PATROLZONE?

Thanks. I hope you like the concepts in the framework. The foundation has now been made, and more classes will be built on top... Next year.

 

To answer your question, it's a bit difficult because I don't know the context. But if I understand correctly. You want to spawn on a scheduled basis new groups and you want to let them patrol automatically, right?

 

You can do that with the method SpawnFunction.

 

An example could be:

local PatrolZones = {}

local SpawnObject = SPAWN:New( "Object" ):InitSchedule( 100, .1 )

SpawnObject:SpawnFunction(
--- @param Functional.Spawn#SPAWN SpawnObject
. function( SpawnGroup )
. PatrolZones[#PatrolZones+1] = AI_PATROLZONE:New( ... )
. PatrolZones[#PatrolZones]:SetControllable( SpawnGroup )
. end
)

This code will spawn a new group every 100 second with 20 second variation.

When the new group is spawned, it will call the function given as a parameter to the method SpawnFunction. That function receives the group just spawned. Use that group to create a new patrolzone and attach the group to the zone.

 

Send me your email address so I can invite you to our chat channels on slack.com.

 

I am currently on holidays but can provide some support through mobile.

 

 

Ps. Can you repost this question on the moose thread pls?

Kind regards,

Sven

_____________

Thanks for the help FlightControl!

Templates_RED = { "Template1", "Template2", "Template3", "Template4" }
PatZone = ZONE:New( "Patrol" )


Spawn_RED = SPAWN:New('RED')
:InitLimit( 4, 0 )
:InitCleanUp( 120 )
:InitRandomizeTemplate( Templates_RED )
:OnSpawnGroup( 
       function (SpawnGroup)
           SpawnGroup.PatrolZone = AI_PATROLZONE:New( PatZone, 1000, 3000, 220, 300 )
           SpawnGroup.PatrolZone:SetControllable( SpawnGroup )
    SpawnGroup.PatrolZone:__Start( 5 )
       end
   )
:SpawnScheduled( 60, 0.1 )

Wow, this looks amazing. Can't wait to mess around with it when I find some time for mission editing.

AI_BALANCER demo videos

Created today a couple of new videos explaining how to code and use the AI_BALANCER class. For those who don't know, the AI_BALANCER allows to automatically balance multiplayer missions with AI to compensate for a lack of players and tailor the behavior ...

It can be viewed here on YouTube in this playlist on my MOOSE channel.

Some other videos will follow shortly demonstrating even more complex stuff... :music_whistling:

FC

Dynamic Ground Operations using SPAWN -> Demo Videos

Find attached a new playlist on my youtube channel, how to create ground operations using the SPAWN class using the MOOSE framework, using lua scripting.

More videos will follow. For some the first videos may be a repetition, but be aware that the SPAWN API has been seriously extended, so don't miss out on those added functions ...

FC

Thank you so much for this Sven!!! you created for me so much interest and motivation to learn the mission editor and lua script!

thanks for the videos!! will watch when I get off work :)