MOOSE - Mission Object Oriented Scripting Framework

[X_Man]

OMG! My 1st test

 

Spawn_Plane_Limited_RepeatOnEngineShutDown = SPAWN:New( "US CAP Senaki AB" ):InitLimit( 2, 2 ):SpawnScheduled( 600, 0.5 ):InitRepeatOnEngineShutDown():Spawn()

 

I have AI taking off from each airbase, then landing, cutting engines and re spawning!!! The next goal is to have them patrol there own airbase (ZONE) with a 50NM radius.

 

Sven you rock hard my friend!!!!!

[Delta99]

How great is that X_Man? Setting up Zones for patrolling etc is a piece of cake too.

 

Then you can throw in random zones, random units etc etc. :)

[David OC]

Just started playing around with MOOSE myself. Nice one Sven!

 

Anyone else have trouble getting the Eclipse workspace and local MOOSE directory on the same drive letter?

 

Or is this install normal? I did notice in the video and pic, the GitHub drive was D: and that works for me on one of my other drives. Perhaps for others this may need a notation on the website.

 

Workspace

C:\Users\xxxxxx\

 

MOOSE directory

D:\Users\xxxxxx\Documents\GitHub\MOOSE

[FlightControl]

Just started playing around with MOOSE myself. Nice one Sven!

 

Anyone else have trouble getting the Eclipse workspace and local MOOSE directory on the same drive letter?

 

Or is this install normal? I did notice in the video and pic, the GitHub drive was D: and that works for me on one of my other drives. Perhaps for others this may need a notation on the website.

 

Workspace

C:\Users\xxxxxx\

 

MOOSE directory

D:\Users\xxxxxx\Documents\GitHub\MOOSE

 

Ehhh... Your workspace does not have to be on the same drive letter. In the video I advise you to store the workspace on your user profile.

 

Hope that helps.

[FlightControl]

Just out of curiosity, is there a version of GCI/CAP script for Moose? The 476th NTTR map loads both Moose AND mist and I'm meeting with resistance when I load the GCI /CAP Script. (Frame Rates plummet)

 

Sierra99

 

Tell me, what are you missing out after watching this video:

 

 

 

 

Fc

[David OC]

Ehhh... Your workspace does not have to be on the same drive letter. In the video I advise you to store the workspace on your user profile.

 

Hope that helps.

 

Thanks for the quick reply,

 

Just pointing out that Eclipse will not let you have the workspace and local MOOSE directory on the same drive letter/user as this is what I was trying to do when following along watching the videos.

 

Workspace

C:\Users\xxxxxx\

MOOSE directory

C:\Users\xxxxxx\Documents\GitHub\MOOSE

 

This wont work as they are both on C: and Eclipse will not let you continue to the next page in the sequence when setting up.

 

Perhaps they would work together on C: (user?) if I had selected a different Workspace, such as C:\Workspace ?

 

Thanks again for all the hard work setting MOOSE up! :thumbup:

Edited January 30, 2017 by David OC

[FlightControl]

Thanks for the quick reply,

 

Just pointing out that Eclipse will not let you have the workspace and local MOOSE directory on the same drive letter/user as this is what I was trying to do when following along watching the videos.

 

Workspace

C:\Users\xxxxxx\

MOOSE directory

C:\Users\xxxxxx\Documents\GitHub\MOOSE

 

This wont work as they are both on C: and Eclipse will not let you continue to the next page in the sequence when setting up.

 

Perhaps they would work together on C: (user?) if I had selected a different Workspace, such as C:\Workspace ?

 

Thanks again for all the hard work setting MOOSE up! :thumbup:

 

Thanks for communicating this. didn't know. If you have more questions, just ask

[FlightControl]

OMG! My 1st test

 

Spawn_Plane_Limited_RepeatOnEngineShutDown = SPAWN:New( "US CAP Senaki AB" ):InitLimit( 2, 2 ):SpawnScheduled( 600, 0.5 ):InitRepeatOnEngineShutDown():Spawn()

 

I have AI taking off from each airbase, then landing, cutting engines and re spawning!!! The next goal is to have them patrol there own airbase (ZONE) with a 50NM radius.

 

Sven you rock hard my friend!!!!!

 

Hehe. Have fun guys! Happy you enjoy.

[Stonehouse]

Hi Sven,

My answer is only in the context of the three videos you link to (of which patrolling and CAP are really relevant) and I imagine you likely have other MOOSE components that may address the differences I comment on. Additionally GCICAP has it's own warts of course and be aware a lot of my comments are from memory at a distance of about 12 months or so and might be not quite right.

 

However for what it is worth:

 

The major difference between GCICAP and what is described in Patrolling and CAP classes is that the aircraft is handling the intercept in MOOSE whereas in GCICAP the aircraft on station at the CAP zones or launched as interception flights will be assigned to targets that are detected by an EWR network. IE the aircraft are not autonomous but are controlled by an "air defence command" with the detection net being the EWRs. Particularly important for scenarios up to about mid 1970s (particularly I believe the Soviet air defence networks were primarily GCI even up to much later periods) and pretty much a requirement for WW2 air defence setups. A fair bit of effort is put in to avoid the groups actually heading off on their own. RTB flights should only engage in a limited fashion in self defence and not be available for intercepts nor initiate combat.

 

Additionally when a CAP group is assigned to an intercept another replacement CAP group will take off and head to their zone to replace them up to the limits of the allowed CAP groups. If all CAP groups are enroute to the CAP zone or already assigned to an intercept or RTB and more intercepts are detected then GCI flights will scramble - up to the limit of allowed GCI groups - to intercept the additional targets. If active GCI and CAP groups are at the limit and still more intruders are detected then the air defences for the coalition are swamped and the intruders will be not be intercepted until one of the already tasked GCI or CAP flights become free by way of their intercept target being destroyed or no longer being detected (assuming the defending group is not badly damaged or bingo fuel) or a GCI or CAP flight lands thereby reducing the active defence flights below the limit allowed and so allowing another to launch. In the current version I believe there is no turn around time for refuel/rearm. Once a flight lands, shuts down and despawns another can take off unless at the allowed max for groups. Initial assignment to CAP zones was on a random basis that tried to spread the groups out evenly but made the mission unpredictable. ie sometimes a zone was not patrolled making for an easier mission and vice versa. Also had a choice to start with CAPs on station or airborne and enroute or on the runway or on the ramp for a cold start and taxi.

 

Additionally there is the whole cold war idea where even though detected by EWR GCI and CAP groups will only be assigned to intercept should the enemy enter the defending coalition territory. The borders can be dynamically switched off (or on) by way of a global variable value from within the mission. Theoretically in a cold war set up when the intruder crosses back into their own airspace the interceptors should break off at some point. Unfortunately this is an example of a bug in GCICAP that never got fixed and usually meant that careful placement of CAP zones and EWR was required to control the rate a cold war went hot.

 

Airbases changing coalition are automatically detected by the script and will launch CAPs and GCIs for the capturing side. If a side has no bases then no CAPs or GCIs are launched. Again current version has no delay to represent transferring aircraft or repairs to the base. This is mostly useful for a hot war situation. EWRs can be told to move forward using mission triggers etc at the appropriate time should a base be captured in order to keep the detection net deployed forward.

 

In the original version pre lukrop I had also introduced logistics where the number of aircraft losses were tracked and GCIs and CAPs ceased launching as supplies were reduced. Supply levels were also dynamically modifiable by global variable. Theoretically this allowed the designer to add triggered resupply missions (transfer flights, naval resupply etc and obviously these were interceptable) to add airframes to a coalition according to designed events. lukrop never implemented working logistics in his version that I am aware of.

 

If you look (I'm happy to do it if I can get some spare time to search the thread but you will probably get them quicker than I will as it may take me a while to get to it) in the GCICAP thread around the time lukrop took over you'll see several posts from me passing on large lists of planned enhancements. Unfortunately I don't believe these ever made it into the versions he made available or had WIP.

 

Cheers,

Stonehouse

 

<edit include old posts detailing planned enhancements>

 

https://forums.eagle.ru/showpost.php?p=2723458&postcount=776 Note that the 2 or 3 response posts by 71st_AH_Rob that follow are relevant

https://forums.eagle.ru/showthread.php?p=2603751&highlight=lukrop#post2603751

 

 

 

Tell me, what are you missing out after watching this video:

 

 

 

 

Fc

Edited February 3, 2017 by Stonehouse

[FlightControl]

Hi Scott,

 

First of all thanks for your efforts and very detailed answer.

This is a long post, so suggest to comment on quoted fragments and then make a summary at the end.

If I say something that is not correct, pls react.

 

=Stonehouse;]

My answer is only in the context of the three videos you link to (of which patrolling and CAP are really relevant) and I imagine you likely have other MOOSE components that may address the differences I comment on. Additionally GCICAP has it's own warts of course and be aware a lot of my comments are from memory at a distance of about 12 months or so and might be not quite right.

 

Yes, the concept of the moose framework is to provide components that allow you to exercise the basic process, but provide flexibility to extend the process with own mission specific steps within that process. And that with a standard interface and API.

So other moose components may tailor the process to a more complex one.

 

 

The major difference between GCICAP and what is described in Patrolling and CAP classes is that the aircraft is handling the intercept in MOOSE whereas in GCICAP the aircraft on station at the CAP zones or launched as interception flights will be assigned to targets that are detected by an EWR network. IE the aircraft are not autonomous but are controlled by an "air defence command" with the detection net being the EWRs. A fair bit of effort is put in to avoid the groups actually heading off on their own. RTB flights should only engage in a limited fashion in self defence and not be available for intercepts nor initiate combat.

 

You are right, the current implementation of the detection handling of AI_PATROL and CAP will is for each plane separate. That being said, GCICAP was neither written on one day, completely bug free containing all the functions. So, the EWR network consisting out of AWACS and ground radar stations is not yet implemented in moose.

But... There are a lot of components already in that can be extended and applied to enrich the patrolling and cap process... Thinking of an interface where an EWR network would become a separate component derived from the existing detection class, that takes a set of units that form the network and filters targets based on detection parameters (altitude, speed, distance, type). This EWR component can then by applied by the mission designer by creating an object from it. The object can then be "attached" on the different patrol and cap objects to receive it's detection source.

The COMMANDCENTER component in moose can be used to extend it's functionality to governing the target assigning by creating maybe an EWRCC class.

Details of the design to be further distilled.

 

 

Additionally when a CAP group is assigned to an intercept another replacement CAP group will take off and head to their zone to replace them up to the limits of the allowed CAP groups.

 

This kind of functionality is already implemented through AI_BALANCER in combination with AI_PATROL/CAP.

 

If all CAP groups are enroute to the CAP zone or already assigned to an intercept or RTB and more intercepts are detected then GCI flights will scramble - up to the limit of allowed GCI groups - to intercept the additional targets.

 

so, you mean, additional caps will spawn, right? Ok.

 

If active GCI and CAP groups are at the limit and still more intruders are detected then the air defences for the coalition are swamped and the intruders will be not be intercepted until one of the already tasked GCI or CAP flights become free by way of their intercept target being destroyed or no longer being detected (assuming the defending group is not badly damaged or bingo fuel) or a GCI or CAP flight lands thereby reducing the active defence flights below the limit allowed and so allowing another to launch.

 

Yup. And a logic is needed which plane goes RTB, based on damage, fuel, arms state.

 

In the current version I believe there is no turn around time for refuel/rearm. Once a flight lands, shuts down and despawns another can take off unless at the allowed max for groups.

 

Various parameters exist to set the moment when to rtb, when to respawn.

 

Initial assignment to CAP zones was on a random basis that tried to spread the groups out evenly but made the mission unpredictable. ie sometimes a zone was not patrolled making for an easier mission and vice versa.

 

It is up to the mission designer if he wants to randomize between does asked how to do it for the moment...

 

 

Also had a choice to start with CAPs on station or airborne and enroute or on the runway or on the ramp for a cold start and taxi.

 

Point taken.

 

Additionally there is the whole cold war idea where even though detected by EWR GCI and CAP groups will only be assigned to intercept should the enemy enter the defending coalition territory. The borders can be dynamically switched off (or on) by way of a global variable value from within the mission. Theoretically in a cold war set up when the intruder crosses back into their own airspace the interceptors should break off at some point. Unfortunately this is an example of a bug in GCICAP that never got fixed and usually meant that careful placement of CAP zones and EWR was required to control the rate a cold war went hot.

 

In moose, you have the ZONE classes, with model does out various types with various behaviour. Polygon, circle, moving circle. Other side type implementations can he added. On what you describe above, a couple of switches could he implemented in the ZONE be class, that allow to "switch on", "switch off" a zone.

 

Airbases changing coalition are automatically detected by the script and will launch CAPs and GCIs for the capturing side.

 

This would he detected by the command center, right?

 

If a side has no bases then no CAPs or GCIs are launched. Again current version has no delay to represent transferring aircraft or repairs to the base. This is mostly useful for a hot war situation. EWRs can be told to move forward using mission triggers etc at the appropriate time should a base be captured in order to keep the detection net deployed forward.

 

Thre moose "moving zones" will moose the AWACS flying in it.

 

In the original version pre lukrop I had also introduced logistics where the number of aircraft losses were tracked and GCIs and CAPs ceased launching as supplies were reduced.

 

Ok.

 

So, to wrap up, components are to be added within moose to:

 

1. Govern target detection through ask EWR network.

2. Govern target assignment through a well thought algorithm, represented by a command center.

3. Deal with Airport captures.

4. Various "hot" scramble and RTB scenarios.

5. Resourcing.

 

1 and 2 seem to me the most useful to he implemented in the short term. The components to implement 1 is already in moose, but needs to be tailored to EWR.

The implementation of two will be more effort.

 

Let us contact each other on the MOOSE slack channels to discuss the details, or we can use this thread too.

 

Overall this seems to me a fun thing to look into (this year), maybe something beautiful will come out with added value/functions.

 

Sven

[Chicki]

So, we need two hard drives to set this up?! As per David OC's post?

[FlightControl]

So, we need two hard drives to set this up?! As per David OC's post?

 

Dunno. Suggest you try it. I would be really surprised if this was the case.

[Zooker]

I'm running into difficulty following along with videos on youtube, specifically https://www.youtube.com/watch?v=7bhsLYHLVP4. At approximately 3:45 into the video, there is astep I am unable to complete. Is there a workaround I am missing? Do we need two harddrives?

[FlightControl]

I'm running into difficulty following along with videos on youtube, specifically https://www.youtube.com/watch?v=7bhsLYHLVP4. At approximately 3:45 into the video, there is astep I am unable to complete. Is there a workaround I am missing? Do we need two harddrives?

 

You need to press the next button down below. If that does not help,

 

Do a screenshot of the dialogue box and put as a reply.

[FlightControl]

Guys, about the 2 hard drives... This comes to me as a total surprise and I can't test it at the moment. Is the anybody who has LDT installed on C:, workspace on C: and moose integrated on C:?

 

Who can help with this?

 

Sven

[FlightControl]

I'm running into difficulty following along with videos on youtube, specifically https://www.youtube.com/watch?v=7bhsLYHLVP4. At approximately 3:45 into the video, there is astep I am unable to complete. Is there a workaround I am missing? Do we need two harddrives?

 

Ahhh. I think I understand the problem ...

When I did the video, the LDT project files were does on my PC already...

Try to configure a new project then. See how that goes.

 

Ill look into this issue when I get back home.

 

Fc

[David OC]

It was confusing me a little as to why? as I have not used the Eclipse software before.

 

I have only had a quick play with Eclipse, I have tried to switch back to C:user/xxxx and cannot get it to work? Here are some screen shots Sven

so you can see what's going on.

 

 

 

 

 

 

[FlightControl]

It was confusing me a little as to why? as I have not used the Eclipse software before.

 

I have only had a quick play with Eclipse, I have tried to switch back to C:user/xxxx and cannot get it to work? Here are some screen shots Sven

so you can see what's going

 

Thanks David,

 

These pics were really helpful. The devil is always in the details, isn't it...

I think I know what the problem is.

 

The video explained you to create a workspace under your user.

Something like C:\users\user_name

 

But, that seems to conflict with the moose project data, which is normally stored in

C:\users\user_name\documents\github\moose

 

Now the problem is, I think, that when you create a workspace in C:\users\user_name, it will think your whole user directory is a workspace.

Maybe it is better to create the workspace under C:\users\user_name\LDTworkspace

 

I think then your problem will be solved.

 

Fc

[David OC]

That seems to be working Sven, didn't think it would be much of a problem, and only a problem for those

trying to install to the one C: hard drive and not knowing to create the folder ( LDTworkspace ) inside their C:\users\user_name\

 

C:\users\user_name\LDTworkspace

 

[Zooker]

Thanks for clearing that up guys! Much appreciated!

[David OC]

Thanks for the Sticky BIGNEWY

Much appreciated.

 

 

Zooker,

 

Below is the video of loading the different scripts inside DCS.

 

Sven, You may have to replace this video below for the DCS / MOOSE setup when you are able to, then perhaps add this final DCS setup to the installation playlist on YouTube.

 

This would finish off keeping us lua / Eclipse newbie's happy, only trying to help here Sven, so others here can get involved in Moose. I too would like to see it takeoff and be built out, I'll leave that to the lua pro's tho.:smartass:

 

Start the video below at around the 14 minute mark. Parts of this video show the MOOSE Framework at an older state with a different folder structure.

To make it easier to work with the DCS editor and use Eclipse on one monitor, reduce the Resolution way down and untick full Screen in the DCS options.

 

Edit: Have played around a bit and having some fun with the air patrols, still a little lost as to how to setup the Moose_Dynamic_Loader in the new MOOSE DCS mission templates, because as you know the DCS editor compiles the mission with all the scripts into the saved mission file when saving in DCS.

 

7TQc9_dGSnU

 

https://youtu.be/7TQc9_dGSnU?t=836

Edited February 4, 2017 by David OC

[FlightControl]

THANK YOU!

 

BIGNEWY,

 

Thanks for making this thread a sticky on the eagle dynamics forums.

To the forum moderators, thanks for supporting this.

 

It has been quite a ride, a bumpy one but we're still driving!

 

One day got into this crazy idea to start making an object oriented framework.

I had been experimenting with the OO capabilities in lua, and was sold.

A good OO model I thought would be an ideal way to simplify things for mission designers, who want to express their creativity designing missions in a more advanced way than what the off-the-shelf mission designer functionality can provide.

 

The framework is now about 1,5 to 2 years in development.

The main challenges were to get a small motivated user base and extend the framework while it was being used... Slack.com has proven to be an enormous asset achieving this.

Right now, there are about 59 people on Slack, of which (I think) 30 "active" users.

On top, various social media like YouTube, the ed forums etc have helped to grow the user base. There are right now 128 subscribers to the moose channel on YouTube.

 

So, as you can see, the development of this framework was in multiple fases.

Right now, one can say that the FOUNDATION of the framework has been developed. On top of the FOUNDATION we're BUILDING all kinds of appliances.

That building process may take easily another year or two. There is sooo much that can be built ... AI orchestration, TASK orchestration, FUNCTIONAL mechanisms etc.

 

So, the framework today, is there, and more will be added into it in the future.

And not only by myself, but also by some motivated users who know how to code lua and who are TODAY looking into adding their ideas into the framework. We've had fun discussing ideas, requirements, designs while providing support.

 

In other words, if we are patient, work together, and carefully plan the added developments, I am sure this framework will become an important asset for DCS mission designers. You who are on slack know what this means by now :-)

 

I would like to say my thanks to: Pikey, Delta99, whisper, entropy (132nd), looney (132nd), dooom, gunterlund, stone house, wingthor, afinegan, gromit190, Dutch baron, dwpenny, hijack, mechanist, quax, ripcord, stuka and many other virtual squadron members and individuals! Some know 2016 has been a hard year for me due to medical reasons, but 2017 is looking good!

 

Before I end this email, would like to express a special thanks to Grimes for his continuous support and patience. If he wouldn't have documented every API and DCS feature with the quality that he does, the development of this framework would not have been possible. I hope that one day we may join forces somehow...

 

Thank you!

Fc

Edited February 4, 2017 by FlightControl

[Pikey]

Thanks for the mention, I'd like to think that I supplied the "coffee" yet again, the real men are those that are now successfully running with your code and inputting to GitHub now, which was kindda special to get that kind of momentum.

 

There's almost an impossible amount left to do but it's like a massive ship, doesn't really turn fast or accelerate, but once it starts, it's impossible to stop.

[BIGNEWY]

No problem guys,

 

It is good to see MOOSE develop over time, FlightControl has put a lot of work into MOOSE and it has helped many in the community.

 

Thanks

[Drexx]

Thanks for the mention FlightControl (I am afinegan), Dynamic Caucasus wouldn't be possible in the fashion it is today without MOOSE, It constantly pushes me to write better/more optimized code. It's definitely enabled me to make some of the best missions possible in DCS (IMO)