MOOSE - Mission Object Oriented Scripting Framework

[FlightControl]

Do you mean edit the main Moose.lua? Or call the _SETTINGS global in my mission script?

 

Use the _SETTINGS global in your script!

It is available!

[FlightControl]

Edit2: Or is it 4 groups and not units??

When setting it to 4 i had 8 planes spawning. Aww i cant get my head around this.

 

Hi Rivvern,

 

I had indeed a small glitch with the resource management (but only the last 4 or so).

But I fixed it now. Under certain circumstances, the DISPATCHER would

spawn more planes than there were at the airport. And that is when

there is a GCI needed, and only a small amount of planes left, for example one, but like 4 attackers coming and to be defended.

In the previous case like 4 planes would be spawned, but fixed it now so that only one plane will be spawned for GCI for defenses from the airbase.

 

I will do a fix in a few moments.

 

I also noticed that when your planes are taking off at the runway,

that the resource manager of the DISPATCHER has some difficulties.

The reason for this is that when a lot of planes need to depart at the runway,

only 2 planes can depart at the same time from the runway. The others are

"queued" by DCS. This is an issue ...

So if like 4 planes would be spawned to depart from the runway at the same

airbase, then only 2 planes will takeoff at the same time...

So the next moment you'll see 2 planes taking off, from the runway, but 2 are "queued" to be taking off... And the next moment, when the DISPATCHER

does a next detection and plans GCI, it sees 4 intruders, so 4 defenders are needed from the airbase, but it only counts like 2 alive defending, so it spawns 2 new airplanes. ... which are queued, and aren't alive (yet).

So the next moment you'll see 2 planes taking off, from the runway, but 4 are "queued" to be taking off... And the next moment, when the DISPATCHER

does a next detection and plans GCI, it sees 4 intruders, so 4 defenders are needed from the airbase, but it only counts like 2 alive defending, so it spawns 2 new airplanes. ... which are queued, and aren't alive (yet).

So the next moment you'll see 2 planes taking off, from the runway, but 6 are "queued" to be taking off... And the next moment, when the DISPATCHER

does a next detection and plans GCI, it sees 4 intruders, so 4 defenders are needed from the airbase, but it only counts like 2 alive defending, so it spawns 2 new airplanes. ... which are queued, and aren't alive (yet).

So the next moment you'll see 2 planes taking off, from the runway, but 8 are "queued" to be taking off... And the next moment, when the DISPATCHER

does a next detection and plans GCI, it sees 4 intruders, so 4 defenders are needed from the airbase, but it only counts like 2 alive defending, so it spawns 2 new airplanes. ... which are queued, and aren't alive (yet).

So the next moment you'll see 2 planes taking off, from the runway, but 10 are "queued" to be taking off... And the next moment, when the DISPATCHER

does a next detection and plans GCI, it sees 4 intruders, so 4 defenders are needed from the airbase, but it only counts like 2 alive defending, so it spawns 2 new airplanes. ... which are queued, and aren't alive (yet).

 

....

 

Until 4 planes are airborne, then this logic will stop, but in the meantime about 10 planes get airborne :-(

 

LOL...

 

Not such an easy fix... I will break my head around this one. So just know that taking off from airbases directly from the runway is a bit tricky.

 

The other methods don't have this issue, because planes are directly at the airbase "alive". Both for spawn from ramp, spawn from hotspot and spawn in the air.... but spawning from a runway has some quirky different behaviour.

 

I will fix this too. At least now I understand the root cause of this issue.

 

FC

[Rivvern]

Wonderful! Haha. Will comment back soon.

[Rivvern]

Bug/Problem:

CAP flights based on a carrier almost immediatly rtb after take-off. Some flights make it to the designated capzone.

 

Fix/Workaround:

If you set an initial waypoint for the template aircraft the issue is gone.

 

BLUE_A2A_GCICAP:SetSquadron( "vfa94", "cvn70", { "vfa94_template" }, 20 )
BLUE_A2A_GCICAP:SetSquadronCap( "vfa94", ZONE_POLYGON:New( "vfa94_capzone", GROUP:FindByName( "vfa94_capzone" ) ), 4000, 10000, 700, 900, 800, 1100 )
BLUE_A2A_GCICAP:SetSquadronCapInterval( "vfa94", 2, 30, 60, 1 )
BLUE_A2A_GCICAP:SetSquadronOverhead( "vfa94", 1.5 )
BLUE_A2A_GCICAP:SetSquadronGrouping( "vfa94", 2 )
BLUE_A2A_GCICAP:SetSquadronTakeoffInAir( "vfa94" )
BLUE_A2A_GCICAP:SetSquadronLandingAtEngineShutdown("vfa94")

counterstrike_v9.miz

counterstrike_v9nowaypoint.miz

[Stonehouse]

.

.

Not such an easy fix... I will break my head around this one. So just know that taking off from airbases directly from the runway is a bit tricky.

 

The other methods don't have this issue, because planes are directly at the airbase "alive". Both for spawn from ramp, spawn from hotspot and spawn in the air.... but spawning from a runway has some quirky different behaviour.

 

I will fix this too. At least now I understand the root cause of this issue.

 

FC

 

Couldn't you just have a table with entries indexed by coalition and airbase and perhaps squadron with the data item being the number of queued aircraft? The dispatcher just adds this value to the ones physically in the game to decide whether to launch more? The actual spawn event of an aircraft would decrement the number in the table representing that a queued aircraft had been spawned. You could use this approach for all take off methods really I think just the ramp and airborne spawns would tend to always have a zero or low queued number as the aircraft tend to spawn without delay.

 

 

eg red, beslan, 4 to represent 4 queued aircraft at beslan. May want also to include the sqd id as an index too I guess.

 

 

A bit of pipe dreaming and you might be able to hook this into logistics and also a base level of efficiency for launching and turning around aircraft that land. So the germ of an idea is the queued table would become a coalition/base and perhaps squadron level system something like below. Assuming in mission time is about 091500 hrs and the aircraft rearming have just landed.

 

 

coalition, base, sqd id, status, time, number of aircraft

red, beslan, A, available, 0, 14

red, beslan, A, queued, 0, 2

red, beslan, A, rearm, 100000, 2

red, beslan, A, repair, 151500, 4

etc

 

 

Don't know how accurate time needs to be but presumably at the second would suffice. Beslan might have a repair rating of +6 hrs or some formula based on % damage times a number for example, a rearm/refuel rating of 45 mins. Could even have an ATC rating that makes queued aircraft be delayed slightly so flights take longer to launch and in which case the queued entry would have a non zero time.

 

 

If the enemy damaged Beslan then these ratings might be degraded to represent lose of command and control.

Elapsed time and events are used to move aircraft between buckets and remove/reset table entries. I guess for it to work you'd have a single available and multiple repair, rearm and perhaps queued table entries if an ATC delay was part of it. So when you need to spawn aircraft you reduce available, create/update a queued entry. When the spawn event occurs update/reset the queued entry. Dispatcher looks at available and queued plus active in game aircraft to decide whether it can (are there enough airframes available?) and should launch more aircraft (queued plus active < number required for intercept). Landing aircraft go to the rearm or repair bucket as per your logic looking at % health along with a time stamp for when they will be moved to available.

 

 

Potentially by having it at coalition level and allowing both red and blue squadrons to be assigned to Beslan and using the controlling coalition to choose which is used for tracking you have the basis of base capture.

 

 

Don't know if the above is of any use or not. I'm not really keeping up with MOOSE news at the moment as real life is not behaving well so you may already have something similar or better in which case apologies for taking up people's time. Was just a passing thought. Probably full of holes big enough to drive a truck through.

Edited September 22, 2017 by Stonehouse

[FlightControl]

Bug/Problem:

CAP flights based on a carrier almost immediatly rtb after take-off. Some flights make it to the designated capzone.

 

Fix/Workaround:

If you set an initial waypoint for the template aircraft the issue is gone.

 

BLUE_A2A_GCICAP:SetSquadron( "vfa94", "cvn70", { "vfa94_template" }, 20 )
BLUE_A2A_GCICAP:SetSquadronCap( "vfa94", ZONE_POLYGON:New( "vfa94_capzone", GROUP:FindByName( "vfa94_capzone" ) ), 4000, 10000, 700, 900, 800, 1100 )
BLUE_A2A_GCICAP:SetSquadronCapInterval( "vfa94", 2, 30, 60, 1 )
BLUE_A2A_GCICAP:SetSquadronOverhead( "vfa94", 1.5 )
BLUE_A2A_GCICAP:SetSquadronGrouping( "vfa94", 2 )
BLUE_A2A_GCICAP:SetSquadronTakeoffInAir( "vfa94" )
BLUE_A2A_GCICAP:SetSquadronLandingAtEngineShutdown("vfa94")

 

 

Can you retry with this version, sorry mate but indeed there were some hot undiscovered hot potatoes that had to be fixed.

 

This are the fixes:

 

* AI_A2A_DISPATCHER and AI_A2A_GCICAP: Fixed problem with TakeoffFromRunway... When spawned GCI groups were queued for takeoff at the airbase, they weren't spawned at the airbase. And the dispatcher wasn't aware and thinking that there weren't enough GCI spawned so it spawned again and again. Resulting in a queue of spawnings. Now it is nicely solved by awaiting takeoff... So only after each takeoff of a spawned group the dispatcher will activate the finite state machine GCI logic. This results in a consistent TakeoffFromRunway defense system! It also solves the delays of helicopters taking off from FARPs (when there isn't enough place, sometimes takeoff is queued, even at hot or cold starts.

* AI_A2A_DISPATCHER and AI_A2A_GCICAP: Under certain circumstances, the DISPATCHER would

spawn more planes than there were at the airport. And that is when

there is a GCI needed, and only a small amount of planes left, for example one, but like 4 attackers coming and to be defended. In the previous case like 4 planes would be spawned, but fixed it now so that only one plane will be spawned for GCI for defenses from the airbase.

* AI_A2A_DISPATCHER and AI_A2A_GCICAP: As a result of all these issues, planes taking off for GCI sometimes immediately returned home... This should be much better now too!

 

* SCORING: Messages now also implement the SETTINGS formatting and display time selection. Especially for "Hit" messages are now of type "Update" message, now it is possible to "disable" those because Update messages can be switched off.

 

 

So planes taking off from the runway should be better now.

Planes should not immediately return to base.

 

Can you retry with this new release?

 

https://github.com/FlightControl-Master/MOOSE/releases/tag/2.2.0.pre

 

Download moose.lua from the Downloads header below (after the long list).

[FlightControl]

Fixed a lot again in AI_A2A_DISPATCHER. Some pending issues which were some real brainbreakers ... I am going to spare you the story ...

 

These are the fixes implemented:

 

 

• AI_A2A_DISPATCHER and AI_A2A_GCICAP: Fixed problem with TakeoffFromRunway... When spawned GCI groups were queued for takeoff at the airbase, they weren't spawned at the airbase. And the dispatcher wasn't aware and thinking that there weren't enough GCI spawned so it spawned again and again. Resulting in a queue of spawnings. Now it is nicely solved by awaiting takeoff... So only after each takeoff of a spawned group the dispatcher will activate the finite state machine GCI logic. This results in a consistent TakeoffFromRunway defense system! It also solves the delays of helicopters taking off from FARPs (when there isn't enough place, sometimes takeoff is queued, even at hot or cold starts.
  
• AI_A2A_DISPATCHER and AI_A2A_GCICAP: Under certain circumstances, the DISPATCHER would
  spawn more planes than there were at the airport. And that is when
  there is a GCI needed, and only a small amount of planes left, for example one, but like 4 attackers coming and to be defended. In the previous case like 4 planes would be spawned, but fixed it now so that only one plane will be spawned for GCI for defenses from the airbase.
  
• AI_A2A_DISPATCHER and AI_A2A_GCICAP: As a result of all these issues, planes taking off for GCI sometimes immediately returned home... This should be much better now too!
  

There is also a new functionality implemented:

 

 

 

• SCORING: Messages now also implement the SETTINGS formatting and display time selection. Especially for "Hit" messages are now of type "Update" message, now it is possible to "disable" those because Update messages can be switched off.
  

 

 

Please ensure you have the latest version of moose.lua downloaded and installed in your missions from this release page:

 

 

https://github.com/FlightControl-Master/MOOSE/releases/tag/2.2.0.pre

 

 

success!

FC

[FlightControl]

Bug/Problem:

CAP flights based on a carrier almost immediatly rtb after take-off. Some flights make it to the designated capzone.

 

Fix/Workaround:

If you set an initial waypoint for the template aircraft the issue is gone.

 

BLUE_A2A_GCICAP:SetSquadron( "vfa94", "cvn70", { "vfa94_template" }, 20 )
BLUE_A2A_GCICAP:SetSquadronCap( "vfa94", ZONE_POLYGON:New( "vfa94_capzone", GROUP:FindByName( "vfa94_capzone" ) ), 4000, 10000, 700, 900, 800, 1100 )
BLUE_A2A_GCICAP:SetSquadronCapInterval( "vfa94", 2, 30, 60, 1 )
BLUE_A2A_GCICAP:SetSquadronOverhead( "vfa94", 1.5 )
BLUE_A2A_GCICAP:SetSquadronGrouping( "vfa94", 2 )
BLUE_A2A_GCICAP:SetSquadronTakeoffInAir( "vfa94" )
BLUE_A2A_GCICAP:SetSquadronLandingAtEngineShutdown("vfa94")

 

 

Check if this is resolved with the latest update. It should.

[Rivvern]

Nope. Its better, but it still messes up. Especially when there are more aircraft spawning from the same.

 

A waypoint for the template aircraft still fixes things.

[FlightControl]

Nope. Its better, but it still messes up. Especially when there are more aircraft spawning from the same.

 

A waypoint for the template aircraft still fixes things.

 

 

OK. I'll check now using your mission.

What is meant with the expression, messes up?

You mean the carrier, will check it now.

[FlightControl]

@Rivvern after how long waiting does the problem occur. I run your mission (the nowaypoints version) and it seems to run fine ...

[FlightControl]

@Rivvern, can you run this mission and check if this also has the same issues as you reported?

It is a simple mission where the AI_A2A_DISPATCHER has the Kuznetsov at sea, and is spawning airplanes at the runway. Intruders are spawned from a distance.

Pls run and observe. One plane more is not so much an issue, but 10 unwanted planes is, and this is what I don't see running this.

 

What can happen is that planes are spawned, queued, and are too late launched by the carrier with the target gone.

In that case, the plane might RTB, yes. GCI goes RTB in that case.

AID-061 - AI_A2A - Takeoff From Ship Runway Test.miz

AID-061 - AI_A2A - Takeoff From Ship Runway Test.lua

Edited September 22, 2017 by FlightControl

[mwd2]

Is there a way to put a ships on patrol, like with MiST and mist.ground.patrol() for land units?

[Pikey]

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/Release/GRP%20-%20Group%20Commands/GRP-503%20-%20NTTR%20Route%20at%20waypoint%20to%20random%20point

It's more complex as it does more, with the randomisation between the zones, but you can change it how you like.

 

Group movement can be a bit complex though... :)

Is there a way to put a ships on patrol, like with MiST and mist.ground.patrol() for land units?

[FlightControl]

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/Release/GRP%20-%20Group%20Commands/GRP-503%20-%20NTTR%20Route%20at%20waypoint%20to%20random%20point

It's more complex as it does more, with the randomisation between the zones, but you can change it how you like.

 

Group movement can be a bit complex though... :)

 

@mwd2 I will add a very easy function this weekend. Yes it can do patrols,with one call.

Will come back to this. But you can do a lot and a lot more, as Pikey said.

[Rivvern]

Ok i have run the mission. It works ok! I even tried to overload it by adding flights taking off from the carrier.

--

But something is wrong with the latest version of Moose. (Moose 2.2.0.pre-20170922_1614). GCICAP keeps spawning more and more cap flights. All going to their destination. They are set to have 2 groups in the capzone, but now there are atleast 8 groups and more are spawning. GCI not used. They seem to ignore the CapInterval and spawn all available resources.

 

Made a version for you where you can see the problem. Mission attached.

Squadrons CAP is set to 1 and resources set to 6.

--

Question 1: What does the following command do? "BASE:TraceOnOff( true )

BASE:TraceClass( "AI_A2A_DISPATCHER" )"

 

Question 2: For an existing squadron. Is it possible to add another capzone without creating a new squadron?

 

Question 3: Is it possible to remove or cancel a capzone (or squadron)?

counterstrike_v15.miz

[TracerFacer]

Hi, there, my first post in this thread. I'm new to moose and I'm trying to do something that I thought would be simple.

 

I have 6 targets (static objects) that I would like to add to an a2g tasking mission. Do static objects work with the tasking system? I don't want to use dynamic tasking. These are are the main mission objectives.

 

I can add them to the scoring system, but I'm unclear how to get them (the static objects) added to a predefined a2g mission within moose. If that makes sense?

 

Having lots of fun learning this and appreciate all the docs/vids that have been made. Thx for reading.

 

-tf

[Pikey]

I could only use proper units when I tried, since it's linked to "detection" but I discussed this a lot with FC as a "GENERIC" task that wasn't linked to detection would be useful for weird other stuff like scenery, statics or groups of targets that are seperated, or many different use cases like zones, triggers, whatever condition you like.

 

Right now you can use the units from the "Fortification" set that ED has in the ME, so roadblocks, a couple of buildings. If you think this is worth adding then add a request to this github https://github.com/FlightControl-Master/MOOSE/issues/667

 

Hi, there, my first post in this thread. I'm new to moose and I'm trying to do something that I thought would be simple.

 

I have 6 targets (static objects) that I would like to add to an a2g tasking mission. Do static objects work with the tasking system? I don't want to use dynamic tasking. These are are the main mission objectives.

 

I can add them to the scoring system, but I'm unclear how to get them (the static objects) added to a predefined a2g mission within moose. If that makes sense?

 

Having lots of fun learning this and appreciate all the docs/vids that have been made. Thx for reading.

 

-tf

[Pikey]

Question 3:

I want this. Ability to "kill" a squadron with a bit of logic, a bit like we can do with a spawn.

I think it's worth a feature request or a question on a solution.

Ok i have run the mission. It works ok! I even tried to overload it by adding flights taking off from the carrier.

--

But something is wrong with the latest version of Moose. (Moose 2.2.0.pre-20170922_1614). GCICAP keeps spawning more and more cap flights. All going to their destination. They are set to have 2 groups in the capzone, but now there are atleast 8 groups and more are spawning. GCI not used. They seem to ignore the CapInterval and spawn all available resources.

 

Made a version for you where you can see the problem. Mission attached.

Squadrons CAP is set to 1 and resources set to 6.

--

Question 1: What does the following command do? "BASE:TraceOnOff( true )

BASE:TraceClass( "AI_A2A_DISPATCHER" )"

 

Question 2: For an existing squadron. Is it possible to add another capzone without creating a new squadron?

 

Question 3: Is it possible to remove or cancel a capzone (or squadron)?

[Pikey]

Just to let you know, I use that function in a recent mission and it works great until .... COMBAT. It seems ground AI get this overridden and they will stop. I pushed the function at 5 minute iuntervals to keep them going, but it's an ugly workaround to the DCS limitation.

@mwd2 I will add a very easy function this weekend. Yes it can do patrols,with one call.

Will come back to this. But you can do a lot and a lot more, as Pikey said.

[mwd2]

Thanks, for the start, i just want to bring the RU aircraft carrier on patrol in front of the coast - in the next step, as no carrier is alone on the sea, the carrier will need an escort from other ships.

[FlightControl]

Thanks, for the start, i just want to bring the RU aircraft carrier on patrol in front of the coast - in the next step, as no carrier is alone on the sea, the carrier will need an escort from other ships.

 

 

I guess, when you want these ships to "partrol", you wanna let it move in a zone, right? to random places? Or follow a predefined path?

 

There are a couple of options to design this, maybe i'll implement all, so you have a choice:

 

 

• Patrol following a predefined path set with waypoint nodes. At the last node, the group will repeat from the first.
  
• Patrol using a predefined path set with waypoint nodes. The group will select a random point of the path and go there. Upon arrival, it will select another and repeat this process.
  
• Patrol in a zone. Using a polygon zone, or a normal trigger zone, the group will select a random point within the zone and go there. Upon arrival, it will select another and repeat this process.
  
• Patrol in a set of zones. Most likely normal trigger zones, but can also be any other type of zone. The group will select a random point in one of the zones, and go there. Upon arrival, it will repeat the process.
  

Your choice.

 

 

The method(s) will be implemented on CONTROLLABLE level. So that UNITS (planes) and GROUPS can be controlled executing this process.

Will revert when I have examples.

 

 

I also guess you may wanna start/stop this process at a certain point in time? So like start patrol and then stop patrol?

 

Can you create a new requirement on GITHUB here please:

https://github.com/FlightControl-Master/MOOSE/issues

 

Just click new issue, and cut-paste the above text written into the issue.

Then i know this is from you :-) It helps my memory.

 

 

 

 

FC

[FlightControl]

Thanks, for the start, i just want to bring the RU aircraft carrier on patrol in front of the coast - in the next step, as no carrier is alone on the sea, the carrier will need an escort from other ships.

 

Removed the content because of a fix, see a post later on this.

 

https://forums.eagle.ru/showpost.php?p=3252255&postcount=786

Edited September 25, 2017 by FlightControl

[FlightControl]

Ok i have run the mission. It works ok! I even tried to overload it by adding flights taking off from the carrier.

--

But something is wrong with the latest version of Moose. (Moose 2.2.0.pre-20170922_1614). GCICAP keeps spawning more and more cap flights. All going to their destination. They are set to have 2 groups in the capzone, but now there are atleast 8 groups and more are spawning. GCI not used. They seem to ignore the CapInterval and spawn all available resources.

 

Made a version for you where you can see the problem. Mission attached.

Squadrons CAP is set to 1 and resources set to 6.

--

Question 1: What does the following command do? "BASE:TraceOnOff( true )

BASE:TraceClass( "AI_A2A_DISPATCHER" )"

 

Question 2: For an existing squadron. Is it possible to add another capzone without creating a new squadron?

 

Question 3: Is it possible to remove or cancel a capzone (or squadron)?

 

Thanks for the feedback Rivvern!

 

On the error reported related to CAP, I will verify this thoroughly.

Not seen this error yet.

 

My answers:

 

Q1: These statements are for filtering the output of logging in the dcs.log.

I generate logging because I need to understand that is happening when developing.

But when released, these statements aren't producing any output by default.

So you can use the Trace, T, E, F methods of BASE class to activate and add trace...

Check the BASE class documentation here:

http://flightcontrol-master.github.io/MOOSE/Documentation/Base.html#BASE

 

Q2: This is a good suggestion and I will look into this.

Actually, was already planning to do such.

A nice additional feature for CAP is to set the zone selection probability for each zone. Imagine you hand zone1 and zone2 for CAP, but you wanna have zone1 40% and zone2 60% probability given to let planes CAP in a zone...

Another function would be to let CAP planes "switch zones" or "reselect" zones. This could be triggered over time or with a specific API. The zone probabilities could be modified during mission execution to ensure that the zones with the highest threat expected to be guarded are CAPped.

 

Q3: Also a good one and an important one... When we think about this, it could be implemented by adding a method SquadronStop and SquadronStart... When stopped, the airplanes airborne would then need to return home immediately... The SquadronStop could be made conditional, only to be executed when the squadron is not active in combat.

SquadronStop could also be used when an airbase with squadrons allocated is captured... In that case, further actions may be required to be done, but that depends on the mission designer.

Methods like SquadronTransferAirbase or SquadronTransferCoalition or SquadronDestroy are possible actions. In terms of resource management, it would be nice to have squadrons resupplied, that is, planes flying into the scene and landing add the base. Once landed, the plane could be added to the squadron.

 

There are a lot of things that can be added.that is what I mean with "flexible" and "expandable".

AWACS guarding, TANKER guarding, Squadron splitting, Squadron escorting, Squadron sweeping an area are all additional functions to be done.

 

The exciting thing will be when I start to make the AI_A2A_DISPATCHER interact with the TASK_A2A_DISPATCHER... So players (pilots) can get a view on what the AI defences are doing as part of the A2A dynamic tasking framework (which works today)...

 

These are the reasons why I started to develop the GCICAP replacement.

 

Sven

[Pikey]

1 question, 1 observation

Question: Ground routes: I know ships can be "different" Will these patrols work for ships and ground groups without additional concern?

 

Observation: SquadronStart/stop would be great. I am recoridng the event death of a runway, which the game uses, I can stop the spawn and the airbase going nuts and wasted cpu cycles, or stop it when a certain event happens. It adds a lot to the variation.