MOOSE - Mission Object Oriented Scripting Framework

All,

I've created a doodle link for those who would like to participate. Please click on the link to register you participation. If you cannot join on the available timeslots, please let me know, and we'll see what we can do.

http://doodle.com/poll/u5qfv89mpwymiy34

After participation, please send me your email address as a PM so that i can register you on our chat channels concerning the moose classes. There is already a considerable audience there...

I think of the following agenda:

1. Concepts of MOOSE and Q&A.

2. Overview of the MOOSE CLASSES.

3. Future developments and pipeline.

4. Open issues and how to approach the fixes.

5. Testing and quality assurance, and joint development.

6. Q&A with the audience.

For those interested in such a workshop, may I ask you:

1. What subject would you be most interested in?

2. And do you have questions in advance to ask that can be clarified in the workshop?

3. What timezone are you in?

Hope you can join and talk to you next week.

FC

Very sorry for this, but there were not a lot of candidates that have time to join the workshop, although I received other timing proposals of the people who were interested. Guess the planning was a bit too short and also in the holiday seaons.

For this reason, I am not planning for a workshop next week, but will send a new post and a new doodle link for a workshop in september, during a weekend.

For those who have placed and subscribed for a time slot on Doodle, i am happy to setup a one to one on skype or any other communication software and have a session next week.

I can walk you though the MOOSE framework, and also show you a little demo on what the capabilities are using MOOSE, while sharing my screen...

I have time this week for this.

If you are interested, send me a friend request on skype to FlightControl_Skype or send me a PM on the forum with your email address where i can reach you.

Kind regards,

Sven

Completely missed this post about doodle :(

ED forum is so full of postings that it is almost impossible to get everything. You should try to post on FB, Twitter, Google+ etc.... much better response to stuff there.

Hehehe,

For those who are interested, i have planned a session on Thursday 21 July at 21:00 CET (EUROPE), 15:00 EST (USA).

http://go.teamviewer.com/v11/m94484889

Meeting-ID: m94-484-889

Password:*MOOSE*

For practical reasons, download teamviewer here,

https://www.teamviewer.com/en/

and pls test your audo settings before joining :-)

Sven

Noted and registered in calendar. Hope to be there.

Happily registered and will join :D

I'm looking forward to participate aswell!

Anyways i am currently working on my first Mission with moose while wtaching carefully the Turtorial videos.

Sadly i got a problem with a function not being called and i can't find the mistake.

I would be very grateful if anybody can take a look at it.

Cheers

Moose_Mission_First.miz

FirstMission.lua

I'm looking forward to participate aswell!

 

 

 

Anyways i am currently working on my first Mission with moose while wtaching carefully the Turtorial videos.

 

 

 

Sadly i got a problem with a function not being called and i can't find the mistake.

 

I would be very grateful if anybody can take a look at it.

 

 

 

Cheers

Ping me as a friend on skype : FlightControl_Skype.

We'll see what the problem is.

Sent from mTalk on Windows 10 mobile

Release Notes MOOSE July 2016

Hello all,

For those not yet using the MOOSE framework, a lot of functionality has been added into the framework the past weeks. Therefore, thought of publishing a release notes update.

You can view the details on GITHUB.

See the first post in this threat for details and links.

2016-07-23
   
   - Fixed problem in MISSILETRAINER 
       - For some weapontypes, there is no target known when launched. 
       - Workaround: Missiles get destroyed immediately after launch for those missile types.
       - Known missiles that have these problem are mavericks and missiles launched by Tunguskas.
   
   - Added more tracing in the EVENT class, appearing in DCS.log
   
   - Added MENU_MISSION classes
       -- Added class MENU_MISSION
       -- Added class MENU_MISSION_COMMAND
       -- Revised documentation of Menu
       -- Fixed bug in SCORING class to set the scoring menu
       
   - Added functions in SPAWN class
       -- Added SPAWN:SpawnFromVec3()
       -- Added SPAWN:SpawnFromVec2()
       -- Revised SPAWN:SpawnFromUnit()
       -- Revised SPAWN:SpawnFromZone()
       
   - Added test missions for SPAWN class
       - Moose_Test_SPAWN_SpawnFromVec3.miz
       - Moose_Test_SPAWN_SpawnFromVec2.miz
       - Moose_Test_SPAWN_SpawnFromUnit.miz
       - Moose_Test_SPAWN_SpawnFromZone.miz
       
   - Added functions in POINT_VEC3 class
       -- Added POINT_VEC3:GetVec2()
       -- Added POINT_VEC3:GetRandomVec2InRadius()
   
   - Added functions in POINT_VEC2 class
       -- Added POINT_VEC2:NewFromVec2()
       
   - Revised the STATIC class working with POSITIONABLE
   - Revised ZONE_RADIUS:GetPointVec3()
   - Revised the documentation.
   
   - Revised the SCHEDULER class
       -- Added SCHEDULER:Schedule()
       -- Reworked SCHEDULER:New()
       
2016-07-21

   - Added methods in CONTROLLABLE class
       - CONTROLLABLE:GetMessage( Message, Duration )
       - CONTROLLABLE:MessageToAll( Message, Duration )
       - CONTROLLABLE:MessageToRed( Message, Duration )
       - CONTROLLABLE:MessageToBlue( Message, Duration )
       - CONTROLLABLE:MessageToClient( Message, Duration, Client )
       - CONTROLLABLE:MessageToGroup( Message, Duration, MessageGroup )
       - CONTROLLABLE:Message( Message, Duration )
       
   - Added methods in DETECTION_AREAS class
       - DETECTION_AREAS:NearestFAC( DetectedArea )
   
   - Removed Message methods from GROUP
   
   - Replaced TASK_CAS and TASK_BAI with TASK_A2G
   
   - Added PROCESS_JTAC (which fits into TASK_A2G)
   
   - Added methods in POINT_VEC3 class:
       - POINT_VEC3:NewFromVec3( Vec3 )
   
   - Added methods in SET_UNIT class
       - SET_UNIT:GetUnitTypesText()
       - SET_UNIT:GetUnitThreatLevels()
   
   - Added methods in UNIT class
       - UNIT:GetCallsign()
       
   - Fixed bug in ZONE_GROUP
   - Fixed bug in SCHEDULER

2016-07-19

   - Updated presentation Moose Training/Presentations/DCS World - MOOSE - Detection - Part 1 - Explanation.pptx

   - Fixed bug in AIBALANCER
   
   - Added function BASE:IsTrace()
   
   - Renamed functions GetPointVec2() to GetVec2() to prepare new naming convension...
       - Still pending is the rename of GetPointVec3 to GetVec3()..
       
   - Added DETECTION_AREAS class to manage detection in areas.
   - Added DETECTION_BASE class
   
   - Added DETECTION_MANAGER class
   - Added DETECTION_DISPATCHER class to dispatch tasks to players.
   - Added DETECTION_REPORTING class
   
   - Added in EVENT class the RemoveEvent functions
   
   - Removed FAC.lua file
   
   - Added MENU classes to manager the menus.
       - MENU_COALITION class
       - MENU_COALITION_COMMAND class
       - MENU_CLIENT class
       - MENU_CLIENT_COMMAND class
       - MENU-GROUP class
       - MENU_GROUP_COMMAND class
   
   - Added new TASK_BASE classes
       - Added TASK_BAI
       - Added TASK_CAS
       - Added TASK_SEAD
   
   - Added new PROCESS classes
       - Added PROCESS_ASSIGN class
       - Added PROCESS_DESTROY class
       - Added PROCESS_ROUTE class
       - Added PROCESS_SMOKE class
   
   - Added POINT_VEC3 methods
       - POINT_VEC3:GetVec3()
       - POINT_VEC3:GetX()
       - POINT_VEC3:GetY()
       - POINT_VEC3:GetZ()
       - POINT_VEC3:GetDirectionVec3( TargetPointVec3 )
       - POINT_VEC3:GetNorthCorrectionRadians()
       - POINT_VEC3:GetDirectionRadians( DirectionVec3 )
       - POINT_VEC3:Get2DDistance( TargetPointVec3 )
       - POINT_VEC3:Get3DDistance( TargetPointVec3 )
       - POINT_VEC3:ToStringBR( AngleRadians, Distance )
       - POINT_VEC3:ToStringLL( acc, DMS )
       - POINT_VEC3:GetAltitudeText()
       - POINT_VEC3:GetBRText( TargetPointVec3 )
       - POINT_VEC3:SetMetric( Metric )
       - POINT_VEC3:IsMetric()
   
   - Added POINT_VEC2 methods
       - POINT_VEC2:GetAltitudeText()
       
   - Added POSITIONABLE method
       - POSITIONABLE:GetRandomPointVec3( Radius )
       - POSITIONABLE:GetVelocityKMH()
       
   - Cleaned up Routines.lua file
   
   - Fixed bug in handling CSV files in SCORING class
   
   - Added lists to SET_ classes in Set.lua file
   
   - Added STATEMACHINE classes
   
   - Added UNIT methods
       - UNIT:Destroy()
       - UNIT:HasSensors( ... )
       - UNIT:HasSEAD()
       - UNIT:GetThreatLevel()
       - UNIT:IsGround()
       - UNIT:IsFriendly( FriendlyCoalition )
       - UNIT:IsShip()
   
   - Created Utils.lua file with many utility functions.
   
   - Added method in ZONE_BASE
       - ZONE_BASE:GetVec2()
   
   - Added method in ZONE_UNIT
       - ZONE_UNIT:GetPointVec3( Height )
   
   - Reworked ZONE_UNIT so that it always will provide a position.
   
   - Optimized the ray casting algorithm in ZONE_POLYGON_BASE:IsPointVec2InZone( PointVec2 )     
 
2016-07-12

   - Fixed bug in SPAWN, related to DEAD events.
   
   - Added test mission Moose_Test_SPAWN_Limit_Scheduled

2016-07-08

   - Fixed bug with velocity in AIRBASEPOLICE class

   - Release in cooperation with dutch-baron the AIRBASEPOLIC_NAVADA class.

   - Removed messages menu from CLIENT class

   - Removed Moose_Test_DETECTION_Laser mission
   
2016-07-06

   - Bugfixes in CONTROLLABLE and GROUP
   
2016-07-05

   - Added country in DCScountry.lua
   
   - Added DATABASE:GetGroupTemplate( GroupName )
   
   - Added methods in GROUP class
       - GROUP:Respawn( Template )
       - GROUP:SetTemplateControlled( Template, Controlled )
       - GROUP:SetTemplateCountry( Template, CountryID )
       - GROUP:SetTemplateCoalition( Template, CoalitionID )
   
   - Added ZONE_GROUP class
   
2016-07-04

   - Fixed bug in SPAWN class restarting GROUPS after landing.

2016-07-03

   - Added method in ZONE_UNIT
       - ZONE_UNIT:GetRandomVec2()

2016-06-28
   
   - Release of rework of MOOSE wrapper object model
       - Added IDENTIFIABLE class
       - Added POSITIONABLE class
       - Added OBJECT class
       - Added CONTROLLABLE class

2016-06-26

   - Reworked scheduler implementations

2016-06-22 

   - Added AIBALANCER class
   - Added PATROLZONE class
   - Added POINT_VEC3 and POINT_VEC2 classes

Sven, so far I have never been sufficiently motivated to try to self-teach myself lua scripting, but what you have done here is impressive. I love the documentation and the step-by-step videos. Thank you. I am going to apply myself now, finally, after all these years.

Question: Is MOOSE able to write group data to a file, which can be read later by another mission (in a campaign for example)? For instance, I want to log the locations of active ground units and record that data someplace, and then use that data to spawn units in the same locations in a subsequent mission. I heard that there are some servers that are doing this now.

Sven, so far I have never been sufficiently motivated to try to self-teach myself lua scripting, but what you have done here is impressive. I love the documentation and the step-by-step videos. Thank you. I am going to apply myself now, finally, after all these years..

Thank you. May I advise you drop me an email or a post at skype, with your email, so I can add you on our fast growing moose framework community chat channels on slack.com. I enjoy helping and teaching others. You won't regret if you join. In hope you sit in your chair when you join... Quite some people interested and using it...

Question: Is MOOSE able to write group data to a file, which can be read later by another mission (in a campaign for example)? For instance, I want to log the locations of active ground units and record that data someplace, and then use that data to spawn units in the same locations in a subsequent mission. I heard that there are some servers that are doing this now.

No, but this is a good idea to be added. Should be easy to do since moose is object oriented. But moose is not about imitating others work. It is about unleashing your creativity by utilising lua and scripting. So that you can design your own missions and achieve things not possible with the editor alone, and easier than with other frameworks... That being said, it is a good idea to be added. But right now we are working on something really compelling that will come soon...

Sent from mTalk on Windows 10 mobile

Hi, very interesting topic. I think I should give MOOSE a try :)

Sven, this is really impressive work, I'm blown away by your detailed tutorials and presentations. I wish I had some serious time to put into understanding and using MOOSE. I hope you keep developing this toward a truly dynamic theater with artificial intelligence!

How did I miss this initial release?

No, but this is a good idea to be added. Should be easy to do since moose is object oriented.

This would be very interesting, a big step toward 'saving progress' from one mission to the next. Even if only a certain limited number of ground objects can be catalogued and their locations saved and read by a following mission, this would be a really big step forward for campaign builders.

Alternatively we could save flags. This is really what I was hoping ED would implement eventually (my own wishful thinking only), something similar to what they did years back in another sim that Matt Wagner produced. If a mission file, inside a campaign, could save a list of flags activated when a mission ends, then any average mission builder could call those up in the subsequent mission and use that to place units, etc.

As I write this, I thought of a third alternative -- can we save zones from mission to mission? Meaning we have a dozen blue zones and a dozen red zones, spread along a FLOT -- when a mission ends, catalogue the coordinates of those zones, based on mission outcome, and then call that data up in a subsequent mission. Then we could use scripts to spawn units within all those zones. I think this 'spawn within zone' functionality already exists, does it not?

Whatever the case I need to learn the basics first, so this is just interesting theoretical discussion at this point.

But moose is not about imitating others work. It is about unleashing your creativity by utilising lua and scripting.

Just kidding -- to me all these how-to examples are like taking music lessons, like learning little guitar riffs and techniques. Just because you learn a 'hammer-on' technique and use it is a song, it does not mean you are trying emulate Mr. Van Halen. Or if you like another example, it is like learning a cooking technique, a little twist which can be modified and incorporated into your own dish. Maybe that is a better analogy?

Seriously, this statement at first offended me when I read it, although I am sure that was not your intent. I think we can all agree Read/writing unit locations is not some amazing groundbreaking idea that nobody ever thought of before. I believe it has been discussed here on these forums for years. The fact is that I did not think it was possible. So it piqued my curiosity when Hijack or somebody in another thread pointed out that it is being done and in fact somebody is hosting these missions on a server somewhere. If we can use moose to figure out a better way, then that is what we should do!

But again, I need to learn to crawl first, then walk. After we can begin to run!

Hi Ripcord,

So i would like to thank you for your thorough answer, and point taken. I should be more careful what I write ...

offending you was not my intent at all :-). From a general basis, i don't want or intend to offend anybody on this forum. Such activity is a waste of time and i have better things to do, like making a MOOSE framework that others can use :-)

However, sometimes I find this forum sometimes like an open book, people spamming mails on the fly, without carefully considering what was written and try to evaluate a good answer or just ask a question on why this post was made ...

There was one post that i did in the past (ohh my god if i think about it), that cause sooo many reactions, people posting replies without even thoroughly considering what was written. And they killed completely the initiative, because they were not up-to-date on the reason why i wrote that post, and were not at the same level ... It was a waste of time, and the end result was zero of that post, although I really wanted to proactively help and not offend people, I actually asked their help ... That is why i try to limit these kind of posts from now on the forum (this one is an exception)...

Let us discuss further the concept of saving and retrieving object states on or MOOSE chat channels, because although it seems like an easy concept, the implementation of it is another feat. People will understand different things behind this requirement or concept and it needs to be cleared out how to utilize it. Let's pick this one up in the MOOSE community as a design discussion.

Sven

I have said it elsewhere and I will say it here

I think MOOSE is one of the most exciting things currently happening in DCS, I think this has the potential to take mission building to places we have only dreamed of before now.

I have started learning LUA and I have read all the media you have put out, cant wait to start using this in my missions

Keep up the good work!

Sven listen I am not offended now -- only slightly when I first read the post, but I realized that maybe I didn't understand what you meant to say. Forums are sometimes not the most clear and efficient way to communicate our ideas, so this happens.

Again, I am still learning to crawl. When I make my first basic script I will report in. No need to waste time on me until I learn the basics at least.

Your tutorials are awesome though. I am working with your first one now about how to load the lua scripts into the missions.

Let us discuss further the concept of saving and retrieving object states on our MOOSE chat channels, because although it seems like an easy concept, the implementation of it is another feat. People will understand different things behind this requirement or concept and it needs to be cleared out how to utilize it, to meet expectations. Let's pick this one up in the MOOSE community as a joint design discussion.

Sent from mTalk on Windows 10 mobile

Sven, simple question.

Can a MIST user also run a mission that has MOOSE scripts embedded in it? Or vice versa?

Do the MIST/MOOSE lua files have to be distributed along with missions when shared, or do all the scripts really and truly get fully embedded in the mission file itself (eg, with no need for additional files to distribute)?

Sven, simple question.

 

 

 

Can a MIST user also run a mission that has MOOSE scripts embedded in it? Or vice versa?

 

 

 

Do the MIST/MOOSE lua files have to be distributed along with missions when shared, or do all the scripts really and truly get fully embedded in the mission file itself (eg, with no need for additional files to distribute)?

Good question :-) I know this is a hot potato for many... It is the ever lasting paradigm of the choice between the object oriented approach or the procedural approach. Some people like to develop using objects, some like more the procedural approach... I leave this up to the community and each individual. Some like to script a couple of things and it works and they are happy. Some like to with with objects, script a couple of things and be happy... You can use missions with MIST in it mixed with MOOSE objects.... However, The MOOSE framework has the strategy to make things easier for users, so that it takes an abstraction of the more low level DCS calls, and provide a more comprehensive API with more functionality embedded in each API. Classes in MOOSE are and will operate at different levels... I think in general, classes can be categorized as follows:

- Wrapper classes. These are classes that Wraps a shield around existing dcs objects, and provide more functions around that... examples are GROUP, STATIC, AIRBASE, UNIT, CLIENT...

- Utility classes: These are classes that you can use to implement advanced technical functionality, like POINT_VEC3, POINT_VEC2,

- Abstract classes: These classes provide a base of functions for other classes to be derived from... Examples are BASE, DETECTION_BASE...

- Task and Process classes: These classes implement a "long lasting" business processes or tasks, using a state machine implementation.

- Technical classes: These implement technical "building blocks" to do advanced technical things... Like SCHEDULER, MENU, EVENT...

- Functional classes: These are classes that implement a defined functionality... Like AIBALANCER, AIRBASEPOLICE, SPAWN, DETECTION_DISPATCHER, DETECTION....

I will have to structure this a bit in the documentation and was one of the points on my agenda to do, as the MOOSE framework is expanding and people won't see the wood between the trees, at least people picking things up from scratch...

So, my short answer is, yes you can use mist with moose, but I leave it to the used of both frameworks how you want to design your code. MOOSE isn't finished yet in a couple of areas, so if people want to use other frameworks also, that is perfectly understandable... However, in a year time the MOOSE framework will be further evolved... Hope this answer is not opening Pandora's box ! I want to say that this framework would not have started if Grimes and ED would not have documented the DCS api and developed mist. So a lot of credits go to Grimes and ED! Want to make this very clear!

Sven

Hmmm, OK I get it, sorta.

The second question is perhaps more important then -- for the consumer of the end result, the player, do they require anything to run the mission, other than just the mission itself? Do they have to install any lua files or add-ons to play the mission? Or is it all nice and self-contained in the mission?

This is important for me to understand.

As designers we can use whatever kitchen equipment we want while we are doing the cooking. We can bake, we can shake, we can roast or toast or us a blender. But when it is ready to consume, we should be able to put it on a plate and serve it. The consumer should not have to choose between one set of utensils or another in order to eat it.

Is MOOSE (or MIST) a scripting tool that we use while we are still in the kitchen only? Or does the consumer/player need to have it as well, in order to eat the meal?

Hmmm, OK I get it, sorta.

 

 

 

The second question is perhaps more important then -- for the consumer of the end result, the player, do they require anything to run the mission, other than just the mission itself? Do they have to install any lua files or add-ons to play the mission? Or is it all nice and self-contained in the mission?

 

This is important for me to understand.

 

As designers we can use whatever kitchen equipment we want while we are doing the cooking. We can bake, we can shake, we can roast or toast or us a blender. But when it is ready to consume, we should be able to put it on a plate and serve it. The consumer should not have to choose between one set of utensils or another in order to eat it.

 

Is MOOSE (or MIST) a scripting tool that we use while we are still in the kitchen only? Or does the consumer/player need to have it as well, in order to eat the meal?

No, look at MOOSE as a set of ingredients... You can use those to create missions... The player does not need it. You need to embed a file ( moose.lua ) in your missions to use it as a mission designer, not as a player.

Sent from mTalk on Windows 10 mobile

I will have to structure this a bit in the documentation and was one of the points on my agenda to do, as the MOOSE framework is expanding and people won't see the wood between the trees, at least people picking things up from scratch...

I think this is very true. It's difficult to understand the scope of MOOSE and how one would implement it in place of the normal use of the mission editor. What really stood out to me in your first tutorial as the function of MOOSE was to keep scripts in one place, rather than confusingly distributed to waypoints, etc. In reality, it seems MOOSE is more than that, especially with the growing Functional classes. For those of us without extensive experience creating script-heavy missions in DCS, some of the utility is lost on us, even if we have extensive experience with DCS.

It would help to see a video of a simple mission designed using MOOSE from start to finish. I think I speak for many of us "weekend programmers" who learn best by seeing examples in action, but lack technical knowledge of programming theory and technique. I had to look up "State Machines" just now, for example, only to find that I understood this innately but did not have a name for it. :)

I think this is very true. It's difficult to understand the scope of MOOSE and how one would implement it in place of the normal use of the mission editor. What really stood out to me in your first tutorial as the function of MOOSE was to keep scripts in one place, rather than confusingly distributed to waypoints, etc. In reality, it seems MOOSE is more than that, especially with the growing Functional classes. For those of us without extensive experience creating script-heavy missions in DCS, some of the utility is lost on us, even if we have extensive experience with DCS.

OK. A few things ...

First, the framework is a growing library of classes written in lua, that provide an additional level of functionality to mission designers. As I explained before, there are "types" or "kind" of classes. Depending on the functionality the classes are providing, we can summarize we have Wrapper Classes, Utility classes, Abstract classes, Task and Process classes, Technical classes, Functional classes ... What i am trying to say here is that you'll need to invest time to learn the class libarary. I know that the class library is not fully documented yet (but a lot is already documented), but these things will get in place as the framework moves on. It is not a one day exercise ...

Second, The purpose of the framework is not to replace the mission editor, but to augment its strengths with a library of lua functions, but in an Object Oriented fashion, which provides you a different lua coding manner like other frameworks do. In this way, it is mandatory that you'll invest a little bit to learn lua, and to learn how to code, and understand OO principles. There is not a lot to learn however, just a couple of basic principles and understand the terms Class, Object, Variables, Local / Global variables and functions, functions passing as parameters, callback functions and the standard lua syntax, and you'll get already a long way...

It would help to see a video of a simple mission designed using MOOSE from start to finish. I think I speak for many of us "weekend programmers" who learn best by seeing examples in action, but lack technical knowledge of programming theory and technique. I had to look up "State Machines" just now, for example, only to find that I understood this innately but did not have a name for it. :)

Hehehe ... I've done a lot of weekend programming myself during my IT career (long weekends, like till early in the morning, trying to find that one piece of code that just did not work as i wanted it to work ..., and when i wake up the next morning i had found the culprit in less than one hour ...)

But I guess your expression of weekend programmer means something else, right? That you don't have a lot of time, but would like to learn quickly the framework, cut-paste some code, and get something working ... Well, i understand your requirement and your limited time you have. An other community member (gunterlund) advised me to do exactly the same thing ...

The secret is however, that:

1. I am currently on holiday and have a very small laptop with me (no videos for August).

2. When I get back, i want to finish a couple of projects that are waiting to be finished: DETECTION_DISPATCHER, state machines, documentation, processes, ....

3. There are test missions, with a lot of examples embedded, that you can review and test yourself. In this way, you'll get very fast already a long way. I really question, have you looked at those test missions already? I think you should and while reading the documentation, you'll understand what these classes do, how they interface, and how they are put into context.

4. On a regular basis we'll organize workshops, these are online meetings where we can share code, and share knowledge... We organized our first workshop a few weeks ago... It was a nice meeting, and people were interested, other community members who are already using the MOOSE framework, were augmenting with examples and inside knowledge...

It is hard to present such a large scope on a silver plate, providing all the ingredients and show you how to make quickly a mission. I really think you'll need to invest a little bit of time, just like you did while learning the mission editor, while learning other frameworks. You start small, learn, and improve with other functions you use from the framework.

But let me give you some comfort, learning MOOSE will be simple, with the condition that you know lua and know a little bit how to code... It will take a bit of time for you to use it, and learn it, but once you get the hang of it, you'll be making missions in no time. I see that with other community members, who have made missions that made me fall off my chair. One person called me from out of the blue in Skype saying he had a question. And he showed me a complete end-to-end mission, designed on his own, following the documentation and the videos ... Of course, this person is a seasoned programmer, but still, did not know lua, and was finding his way on his own ...

I leave it up to the community members to augment on that one ...

But the point is well taken about the video, i think i'll make a few, one when the pending projects are finished and the classes are well documented. Actually, I already planned for it to do that, but right now, i really want to get that DETECTION stuff released ...

What I suggest you do, is join the community (which you did because you send me your email address). Join our community on slack, and you'll be able to ask question in a near real-time fashion and get answers from myself or other members.

Sven

It has been quiet around the moose framework during the holiday season. But silently in the background, work has been done ...

Find the following change log with work in progress, it is not released yet, but will around september after our second workshop:

2016-08-21

- Made a new STATEMACHINE_CONTROLLABLE object, which models a base state machine class to be inherited by AI controllable classes.

-- Created the class as such that intherited AI classes become "finite state machines".

-- Each STATEMACHINE_CONTROLLABLE class contains a Controllable object, which is one Unit, Client or Group object.

-- Added state transition functions that are called before and after the state transition.

-- Event functions are automatically added to the class, based on the FSMT.

-- Added immediate and delayed event processing as part of the STATEMACHINE_CONTROLLABLE class.

--- Events that start with __Event are processed with a delay. The delay is given in seconds as a parameter.

- Created a new AI_PATROLZONE class, which inherites STATEMACHINE_CONTROLLABLE.

-- This class implements a complete new revamped patrol zone AI pattern.

-- Created a new test directory: Moose_Test_AI_PATROLZONE with test missions.

2016-08-15

- Removed the old classes and moved into an "Old" folder in the Moose/Development folder.

-- Cleaned Moose.lua + Documented class types

-- Cleaned Create_Moose.bat + Documented class types

- Extend the ZONE_BASE class with a probability randomization factor, that can be used for zone randomization purposes.

- Documented the Zone module classes.

- Changed and removed the POINT_VEC3 SmokeColor and FlareColor structure. Replaced with SMOKECOLOR and FLARECOLOR types.

-- Replaced also code in test missions with SMOKECOLOR and FLARECOLOR references.

- Added change logs of API changes in MOOSE documentation.

- Added ZONE_BASE:GetName() method.

- Added ZONE_BASE:GetZoneProbability() method.

- Added ZONE_BASE:SetZoneProbability() method.

- Added ZONE_BASE:GetZoneMaybe() method.

- Added SPAWN:InitRandomizeZones() method.

- Renamed SPAWN:CleanUp() method to SPAWN:InitCleanUp() method.

- Reviewed documentation of the PatrolZone module and PATROLZONE class.

2016-08-14

- Changed Spawn APIs to express Group position and Unit position randomization.

- Changed the API protocol of SpawnInZone() method.

-- Removed OuterRadius and InnerRadius parameters !!!

- Changed the API protocol of SpawnFromUnit() method.

-- Removed OuterRadius and InnerRadius parameters !!!

- Added InitRandomizeUnits() method, taking 3 parameters:

-- RandomizeUnits given the value true, will randomize the units upon spawning, false (default) will not randomize the untis.

-- OuterRadius is the outer radius of the band where the units will be spawned, if RandomizeUnits is true.

-- InnerRadius is the inner radius of the band where the units will not be spawned, if RandomizeUnits is true.

- Removed SpawnFunction() method.

- Added OnSpawnGroup() method as the new official CallBack function method to catch when a new function will be called.

-- Documented OnSpawnGroup() method.

- Renamed Limit() method to InitLimit() method.

- Renamed Array() method to InitArray() method.

- Renamed RandomizeRoute() method to InitRandomizeRoute() method.

- Renamed RandomizeTemplate() method to InitRandomizeTemplate() method.

- Renamed UnControlled() method to InitUnControlled method.

- Reviewed all test missions for the changes executed and made adaptions where necessary + re-tests.

2016-08-12

- Temporary release of the new cargo handling.

-- Released available functionality to handle one CARGO_UNIT loading, boarding, unloading.

-- Created CARGO_UNIT test missions.

- Added Translate() method in POINT_VEC3, translating a 3D point over the horizontal plane with a Distance and Angle coordinate.

2016-08-08

- Added briefing to method ESCORT:New()

-- If no EscortBriefing is given, the New() method will show the default briefing.

2016-08-06

- Made PointVec3 and Vec3, PointVec2 and Vec2 terminology used in the code consistent.

-- Replaced method PointVec3() to Vec3() where the code manages a Vec3. Replaced all references to the method.

-- Replaced method PointVec2() to Vec2() where the code manages a Vec2. Replaced all references to the method.

-- Replaced method RandomPointVec3() to RandomVec3() where the code manages a Vec3. Replaced all references to the method.

2016-08-03

- Fixed error at SPAWN:RandomizeTemplate()

-- Units started in wrong x, y position (at the template, instead of at the master template of the SPAWN).

-- Adjusted x, y and alt to the start position of the first unit of the master template.

-- Added a test mission Moose_Test_SPAWN_RandomizeTemplate.

-- Regenerated MOOSE.lua