FlightControl

You can spawn cargo...

Run this test demo mission. https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/Release/TAD%20-%20Task%20Dispatching/TAD-105%20-%20A2G%20Task%20Dispatching%20DETECTION_AREAS It is a simple demo... But you can modify it / extend it easily. Hardly any waypoints are set. You don't need to set any actually. In the mission editor: So you can add targets (blue). You can add AI forward air controllers, as long as the group name starts with FAC. You can add client PLAYER slots, as long as the group name of the client slots start with Attack. Use the radio menu. Note that the FAC must first detect targets. Once detected, you'll see a mission in the command Center menu appearing. Under the mission, you see a briefing, task reports, and a Assign Task menu... When you select join task, you will see the detected targets, listed by type: CAS, BAI, SEAD... Select further.... You can then select the marker on the map, or join the task... when you join the task, you'll get directions from the hq. You can get coordinates displayed in BR, LLHMS, LLDDM, MGRS, BULLS..., by going into the player settings menu and select the preferred A2G coordinate format .... You can also select the A2A format; the measurement system (miles/meters) and display times of messages. A missile trainer is activated that will destroy missiles before they hit you, which are fired at you and it will notify you of the missile trajectory and distance. Wanna know more, just ask. Enjoy, Sven

JOKERACTS, I understand you may have seen some improvements on a certain area. The issue at play here has nothing to do with hardware at all. Nothing. The performance issue is the gaming engine logic which is not optimal. This is not about graphics, This is not about physics. This is about running the sim on one core and the current version has issues doing this in an optimal way. I would take the explanation of skatezilla for granted. Sorry to disappoint you maybe, but thanks for your research. Interesting pictures by the way! If you can find a way to discover how well the CPU is utilized... That would really help... But for that we should profile the logic and process per CPU cycle. Sven

It already exists

Can you get this improved? https://forums.eagle.ru/showpost.php?p=3250308&postcount=162

Just done a test on beta 1.5.7.9891. I ran the Gori Valley mission i posted earlier in the thread. Exact same version. There is improvement... But still stutter, but not like it was in the original post in the threat. But still, stutter ... The stuttering increases as units are added, indeed. Watch the video: wi9FqijIW3k I bet that if you run this on a server, (thus clients connecting to it), that you won't see a lot of warping and that it may bring already improvements. Because again, let me repeat, there is a huuuge confusion in this community about server and client. If the server is CPU overloaded, or if there is a block in the mission run on the server for whatever reason, you'll notice warping on the connected clients. How to measure CPU performance of your server: measure the CPU in a CPU monitor, and measure the fps with disabled graphics. When the value becomes below 15 fps, you'll see warping. If it stays above that, it won't likely warp clients. But "warping" can also be due to network connection quality or any other network issue, and therefore "warping" is not a good measurement to understand server performance. FC

Haven't seen this. I will try it! Thanks for telling Sith! Hopefully this fixes the performance issues.

the Gori Valley mission has 1300 units on the battle scene, 60 ground units running simulaneously, it runs 8 logical missions using automatic detection and dynamic A2G and A2A tasking and it ran incredibly smooth. It has several airborne AI units, helicopters, planes and has ongoing A2A battles. As is demonstrated on a couple of videos on DCS version 1.5.6. In DCS version 1.5.7, this mission runs terribly. It was the mission that I used to demonstrate the reported stuttering thread. Now we are a couple of versions and a new beta further and where are the fixes? Then i suggested to do a roll-back to 1.5.6, and run 1.5.7 in BETA till ALL urgent problems are fixed that are reported. But that suggestion got rejected. OKAY. But how long can ED still motivate this going on like this? When do we get our simulator back? I moved to DCS 2.1 developing a new mission. But helas, unfortunately, the stuttering and performance decrease is also much noticeable now since the last updates on 2.1 So my question is... Can we please consider to rollback to 1.5.6, and move 1.5.7 to BETA until this performance problem is fixed? FC

the Gori Valley mission has 1300 units on the battle scene, 60 ground units running simulaneously, it runs 8 logical missions using automatic detection and dynamic A2G and A2A tasking and it ran incredibly smooth. It has several airborne AI units, helicopters, planes and has ongoing A2A battles. As is demonstrated on a couple of videos on DCS version 1.5.6. In DCS version 1.5.7, this mission runs terribly. It was the mission that I used to demonstrate the reported stuttering thread. Now we are a couple of versions and a new beta further and where are the fixes? Then i suggested to do a roll-back to 1.5.6, and run 1.5.7 in BETA till ALL urgent problems are fixed that are reported. But that suggestion got rejected. OKAY. But how long can ED still motivate this going on like this? When do we get our simulator back? I moved to DCS 2.1 developing a new mission. But helas, unfortunately, the stuttering and performance decrease is also much noticeable now since the last updates on 2.1 So my question is... Can we please consider to rollback to 1.5.6, and move 1.5.7 to BETA until this performance problem is fixed? FC

@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

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

OK. I'll check now using your mission. What is meant with the expression, messes up? You mean the carrier, will check it now.

Try this... Note I fixed some stuff. Reload moose.lua and embed in your mission again from here: https://github.com/FlightControl-Master/MOOSE/releases/tag/2.2.0.pre Find demo mission attached. --- -- Name: AID-100 - AI_A2A - Demonstration -- Author: FlightControl -- Date Created: 30 May 2017 -- Define a SET_GROUP object that builds a collection of groups that define the EWR network. -- Here we build the network with all the groups that have a name starting with DF CCCP AWACS and DF CCCP EWR. DetectionSetGroup = SET_GROUP:New() DetectionSetGroup:FilterPrefixes( { "DF CCCP AWACS", "DF CCCP EWR" } ) DetectionSetGroup:FilterStart() Detection = DETECTION_AREAS:New( DetectionSetGroup, 30000 ) -- Setup the A2A dispatcher, and initialize it. A2ADispatcher = AI_A2A_DISPATCHER:New( Detection ) -- Enable the tactical display panel. A2ADispatcher:SetTacticalDisplay( true ) -- Initialize the dispatcher, setting up a border zone. This is a polygon, -- which takes the waypoints of a late activated group with the name CCCP Border as the boundaries of the border area. -- Any enemy crossing this border will be engaged. CCCPBorderZone = ZONE_POLYGON:New( "CCCP Border", GROUP:FindByName( "CCCP Border" ) ) A2ADispatcher:SetBorderZone( CCCPBorderZone ) -- Initialize the dispatcher, setting up a radius of 100km where any airborne friendly -- without an assignment within 100km radius from a detected target, will engage that target. A2ADispatcher:SetEngageRadius( 80000 ) -- Setup the squadrons. A2ADispatcher:SetSquadron( "Mineralnye", AIRBASE.Caucasus.Mineralnye_Vody, { "SQ CCCP SU-27" }, 20 ) A2ADispatcher:SetSquadron( "Maykop", AIRBASE.Caucasus.Maykop_Khanskaya, { "SQ CCCP MIG-31" }, 20 ) A2ADispatcher:SetSquadron( "Mozdok", AIRBASE.Caucasus.Mozdok, { "SQ CCCP MIG-31" }, 20 ) A2ADispatcher:SetSquadron( "Sochi", AIRBASE.Caucasus.Sochi_Adler, { "SQ CCCP SU-27" }, 20 ) A2ADispatcher:SetSquadron( "Novo", AIRBASE.Caucasus.Novorossiysk, { "SQ CCCP SU-27" }, 20 ) -- Setup the overhead A2ADispatcher:SetSquadronOverhead( "Mineralnye", 1.2 ) A2ADispatcher:SetSquadronOverhead( "Maykop", 1 ) A2ADispatcher:SetSquadronOverhead( "Mozdok", 1 ) A2ADispatcher:SetSquadronOverhead( "Sochi", 1 ) A2ADispatcher:SetSquadronOverhead( "Novo", 1.5 ) -- Setup the Grouping A2ADispatcher:SetSquadronGrouping( "Mineralnye", 1 ) A2ADispatcher:SetSquadronGrouping( "Sochi", 2 ) A2ADispatcher:SetSquadronGrouping( "Novo", 3 ) -- Setup the Takeoff methods A2ADispatcher:SetSquadronTakeoff( "Mineralnye", AI_A2A_DISPATCHER.Takeoff.Air ) A2ADispatcher:SetSquadronTakeoffInAir( "Sochi" ) A2ADispatcher:SetSquadronTakeoffFromRunway( "Mozdok" ) A2ADispatcher:SetSquadronTakeoffFromParkingCold( "Maykop" ) A2ADispatcher:SetSquadronTakeoffFromParkingHot( "Novo" ) -- Setup the Landing methods A2ADispatcher:SetSquadronLandingAtRunway( "Mineralnye" ) A2ADispatcher:SetSquadronLandingNearAirbase( "Sochi" ) A2ADispatcher:SetSquadronLandingAtEngineShutdown( "Mozdok" ) A2ADispatcher:SetSquadronLandingNearAirbase( "Maykop" ) A2ADispatcher:SetSquadronLanding( "Novo", AI_A2A_DISPATCHER.Landing.AtRunway ) -- CAP Squadron execution. CAPZoneEast = ZONE_POLYGON:New( "CAP Zone East", GROUP:FindByName( "CAP Zone East" ) ) A2ADispatcher:SetSquadronCap( "Mineralnye", CAPZoneEast, 4000, 10000, 500, 600, 800, 900 ) A2ADispatcher:SetSquadronCapInterval( "Mineralnye", 2, 30, 60, 1 ) CAPZoneWest = ZONE_POLYGON:New( "CAP Zone West", GROUP:FindByName( "CAP Zone West" ) ) A2ADispatcher:SetSquadronCap( "Sochi", CAPZoneWest, 4000, 8000, 600, 800, 800, 1200, "BARO" ) A2ADispatcher:SetSquadronCapInterval( "Sochi", 2, 30, 120, 1 ) CAPZoneMiddle = ZONE:New( "CAP Zone Middle") A2ADispatcher:SetSquadronCap( "Maykop", CAPZoneMiddle, 4000, 8000, 600, 800, 800, 1200, "RADIO" ) A2ADispatcher:SetSquadronCapInterval( "Sochi", 2, 30, 120, 1 ) -- GCI Squadron execution. A2ADispatcher:SetSquadronGci( "Mozdok", 900, 1200 ) A2ADispatcher:SetSquadronGci( "Novo", 900, 2100 ) A2ADispatcher:SetSquadronGci( "Maykop", 900, 1200 ) CleanUp = CLEANUP_AIRBASE:New( { AIRBASE.Caucasus.Novorossiysk } ) -- Blue attack simulation local Frequency = 300 BlueSpawn1 = SPAWN :New( "RT NATO 1" ) :InitLimit( 2, 10 ) :InitRandomizeTemplate( { "SQ NATO A-10C", "SQ NATO F-15C", "SQ NATO F-16A", "SQ NATO F/A-18", "SQ NATO F-16C" } ) :InitRandomizeRoute( 0, 0, 30000 ) --:InitDelayOn() :SpawnScheduled( Frequency, 0.4 ) BlueSpawn2 = SPAWN :New( "RT NATO 2" ) :InitLimit( 2, 10 ) :InitRandomizeTemplate( { "SQ NATO A-10C", "SQ NATO F-15C", "SQ NATO F-16A", "SQ NATO F/A-18", "SQ NATO F-16C" } ) :InitRandomizeRoute( 0, 0, 30000 ) --:InitDelayOn() :SpawnScheduled( Frequency, 0.4 ) BlueSpawn3 = SPAWN :New( "RT NATO 3" ) :InitLimit( 2, 10 ) :InitRandomizeTemplate( { "SQ NATO A-10C", "SQ NATO F-15C", "SQ NATO F-16A", "SQ NATO F/A-18", "SQ NATO F-16C" } ) :InitRandomizeRoute( 0, 0, 30000 ) --:InitDelayOn() :SpawnScheduled( Frequency, 0.4 ) BlueSpawn4 = SPAWN :New( "RT NATO 4" ) :InitLimit( 2, 10 ) :InitRandomizeTemplate( { "SQ NATO A-10C", "SQ NATO F-15C", "SQ NATO F-16A", "SQ NATO F/A-18", "SQ NATO F-16C" } ) :InitRandomizeRoute( 0, 0, 30000 ) --:InitDelayOn() :SpawnScheduled( Frequency, 0.4 ) Hope this fixes the doctrinal response. 425678 bugs to go. FC AID-100 - AI_A2A - Demonstration.miz AID-100 - AI_A2A - Demonstration.lua

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

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

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

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

Maybe, but that is not the root cause.

Now THAT is a very useful requirement! :-) :-) Controller.getTask !

Hi Rob. Thank you for the great feedback. AI_A2A_GCICAP inherits all from AI_A2A_DISPATCHER. Send me your mission so I can have a look at it. The snappiness is configurable. Detection runs every 30 seconds. That is your issue on snappiness. May I ask you why you used some words which were expressing frustrations. You are already on slack.com. I invited you about a year ago. Come on board and ask your questions online. No need for frustrations. If possible you will be helped. I made these modules to help you all and the DCS community. To make something better and expandable. If you feel that goal has not been reached, then I am sorry. Maybe there is indeed something wrong and can be fixed. Sven

Use the _SETTINGS global in your script! It is available!

Guys, is the AI_A2A_GCICAP and AI_A2A_DISPATCHER now working? Beside the additional requirements from Rivvern on the MOOSE thread, on airbase capture. What are the satisfaction levels these days? The question is important for me to understand the readiness for release 2.2. So if you would be so kind to brind some light in the darkness? Thanks! FC

HOLD! That is another questions and i do have an answer for you there!!! MOOSE creates automatically a _SETTINGS object, that is globally known. You can use this to tweak the settings, for example: _SETTINGS:SetMetric() -- Defaults _SETTINGS:SetA2G_BR() -- Defaults _SETTINGS:SetA2A_BRAA() -- Defaults _SETTINGS:SetLL_Accuracy( 3 ) -- Defaults _SETTINGS:SetMGRS_Accuracy( 5 ) -- Defaults _SETTINGS:SetMessageTime( MESSAGE.Type.Briefing, 180 ) _SETTINGS:SetMessageTime( MESSAGE.Type.Detailed, 60 ) _SETTINGS:SetMessageTime( MESSAGE.Type.Information, 30 ) _SETTINGS:SetMessageTime( MESSAGE.Type.Overview, 60 ) _SETTINGS:SetMessageTime( MESSAGE.Type.Update, 15 ) Use the IntelliSense in LDT to find the methods attached to _SETTINGS. I am sure you'll find your way with this! When asking a question, don't just ask about the technicalities on what you try to do, but also provide a bit of context. That will allow for a broader response too! cheers FC

SETTINGS is not meant to be used as an instance. It is being managed in the background by the MOOSE system. A settings menu is automatically created when you design a mission using MOOSE. This settings menu can be used by players to tweak how A2G coordinates, A2A coordinates, measurement system and message timing is being displayed. When you use certain classes (and these will grow), the settings choosen by the player will automatically tweak the message formats and timings. Check the class TASK_A2G_DISPATCHER if you wanna try this out a bit...

The fix aligned also in AI_CAP_ZONE and AI_CAS_ZONE the method how the "next engagement step" is calculated. This fix has nothing to do with GCICAP or AI_A2A_DISPATCHER... Or actually it has ... For a slick GCICAP implementation, I changed the method how waypoints are triggering script calls, as part of the AI_A2A_DISPATCHER and CONTROLLABLE:Route is implemented. AI_A2A_CAS and AI_A2A_CAP were developed to be used in AI_A2A_DISPATCHER, where these classes have an optimized method to jump from waypoint to waypoint executed by a script. AI_CAP_ZONE and AI_CAS_ZONE weren't touched for months and implemented the old logic. Running a test mission together with @dexa, we saw that the logic was crashing when the engagement was started by the main demo script. So I fixed this crash, aligning the waypoint hopping method of AI_CAP_ZONE and AI_CAS_ZONE in alignment with AI_A2A_CAP and AI_A2A_CAS. For those who don't know, AI_A2A_CAP and AI_A2A_CAS are executing CAP and CASusing commanded by AI_A2A_DISPATCHER. AI_CAS_ZONE and AI_CAP_ZONE are classes that perform CAS or CAP independently, having its own detection logic. Maybe I am wrong.