FlightControl

The MOOSE CAP, CAS and BAI works for Normandy. Some guys around are already using it and it is fantastic, in combination with AI_BALANCER and the TASKING. And the AI_FORMATION class is stunning ... :-) What you need is a little assistence... What I suggest you do, is drop me a PM showing your email address, so I can join you up at our slack community. Also, there are demonstration missions that explain how CAP needs to be modelled. It may not be perfect to what you need, so please drop me your email and we can chat / help around it. Thanks for your interest in the framework! Sven

Hi Sir! First of all thank you for your interest in the framework! Regarding your question, I don't think this will be a problem, no. If it is, please tell us. Also, you are kindly invited to join our community at slack.com. It is free, open and also professional in the sense that we are jointly communicating and providing feedback on how to improve the framework... We also have a joint GITHUB site where we log issues and do joint fixes in pull requests. If you wanna join, please do, but you'll have to send me (private message) an email address to where i can send you an invitation to join the slack platform. Slack only allows you to join through an invitation by email. I encourage you do. It will save you a lot of time and you'll be able to meet the other kind members. Sven

Jump into your slack seat. I am online. You still know you slack Id and password, no? Come online and lets discuss.

When posting a problem, suggest you make one post per subject. Otherwise ED won't recognize it ... This is the post for the S_EVENT_PLAYER_ENTER_UNIT. https://forums.eagle.ru/showthread.php?t=186666 There is a video on it too ...

I confirm this problem about S_EVENT_ENGINE_STARTUP

S_EVENT_PLAYER_ENTER_UNIT is not fired when a player enters a CA unit ... in MP, it won't fire at all ... and ... coalition.getPlayerNames() won't return CA players in a CA unit :-( not even in single player. there are more.

We must wait for a patch. Thanks for posting this problem. Now we are with 2 persons with this problem :-) Please review my posts and confirm my problems too. The issue with scripters is that we seem to be individuals doing stuff in our ivory towers, somehow. We could work more together so that DCS understands that there is a world out there with people who wanna create fun missions using scripting. One way of working together is to confirm posts or provide feedback on posts of others about scripting bugs. A small note is sufficient. ED will notice then. (A lot of people did this already though!). Sven

What you can do ... This is not ideal, but this could be "some" workaround solution ... So when an airplane starts from the airbase, it will have a route start waypoint that is located at the starting airbase. Wait until the group is fully airborne. Then push a new task to the controller, the same route, but now starting from the 2nd waypoint, thus an airborne waypoint. The landing airbase should neither be given. But when the plane is near that airbase, i think it would automatically RTB to the nearest airbase... Now that I think of it, this method won't work neither, the plane will still fly back to its starting airbase :-( crap... Forget my post. Was tryin to help you out. For me this is a long time ago that I was searching for a solution for this, and finally gave up (I think)... So forgive me if the above would not work. Need to dig this up, but am doin something else now :-) (A2A tasking).

I am afraid that this is a bug that is a long time in the system... I've been searching for a solution myself on this. So the behaviour is that a plane flies to its destination airport (tries to land), but doesn't and flies back to its starting airfield? And this only happens when you push a new task with a route to a controller, correct? Have seen this issue in the system since 1.5.0. Because of this bug, there seems to be no way to let an airplane land at an airbase of your choice, correct?

Is your problem fixed?

Hi guys, may I remind you of the following script, that allows you to interact with escorting AI on your flight and take the lead. Demo scripts here: https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master-release-2.1/ESC%20-%20Escorting/ESC-001%20-%20Escorting%20Helicopters Each escorting group can be commanded with a whole set of radio commands (radio menu in your flight, and then F10). The radio commands will vary according the category of the group. The richest set of commands are with Helicopters and AirPlanes. Ships and Ground troops will have a more limited set, but they can provide support through the bombing of targets designated by the other escorts. RADIO MENUs that can be created: Find a summary below of the current available commands: Navigation ...: Escort group navigation functions: "Join-Up and Follow at x meters": The escort group fill follow you at about x meters, and they will follow you. "Flare": Provides menu commands to let the escort group shoot a flare in the air in a color. "Smoke": Provides menu commands to let the escort group smoke the air in a color. Note that smoking is only available for ground and naval troops. Hold position ...: Escort group navigation functions: "At current location": Stops the escort group and they will hover 30 meters above the ground at the position they stopped. "At client location": Stops the escort group and they will hover 30 meters above the ground at the position they stopped. Report targets ...: Report targets will make the escort group to report any target that it identifies within a 8km range. Any detected target can be attacked using the 4. Attack nearby targets function. (see below). "Report now": Will report the current detected targets. "Report targets on": Will make the escort group to report detected targets and will fill the "Attack nearby targets" menu list. "Report targets off": Will stop detecting targets. Scan targets ...: Menu items to pop-up the escort group for target scanning. After scanning, the escort group will resume with the mission or defined task. "Scan targets 30 seconds": Scan 30 seconds for targets. "Scan targets 60 seconds": Scan 60 seconds for targets. Attack targets ...: This menu item will list all detected targets within a 15km range. Depending on the level of detection (known/unknown) and visuality, the targets type will also be listed. Request assistance from ...: This menu item will list all detected targets within a 15km range, as with the menu item Attack Targets. This menu item allows to request attack support from other escorts supporting the current client group. eg. the function allows a player to request support from the Ship escort to attack a target identified by the Plane escort with its Tomahawk missiles. eg. the function allows a player to request support from other Planes escorting to bomb the unit with illumination missiles or bombs, so that the main plane escort can attack the area. ROE ...: Sets the Rules of Engagement (ROE) of the escort group when in flight. "Hold Fire": The escort group will hold fire. "Return Fire": The escort group will return fire. "Open Fire": The escort group will open fire on designated targets. "Weapon Free": The escort group will engage with any target. Evasion ...: Will define the evasion techniques that the escort group will perform during flight or combat. "Fight until death": The escort group will have no reaction to threats. "Use flares, chaff and jammers": The escort group will use passive defense using flares and jammers. No evasive manoeuvres are executed. "Evade enemy fire": The rescort group will evade enemy fire before firing. "Go below radar and evade fire": The escort group will perform evasive vertical manoeuvres. Resume Mission ...: Escort groups can have their own mission. This menu item will allow the escort group to resume their Mission from a given waypoint. Note that this is really fantastic, as you now have the dynamic of taking control of the escort groups, and allowing them to resume their path or mission. Kind regards, Sven

Use moose ... Look at these examples: https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master-release-2.1/EVT%20-%20Event%20Handling

If somebody is experiencing strange things while testing Normandy, designing and running test mission using moose, would you be so kind to post here your issues or findings? Positive news is also feedback.

I don't think resizing an entire table in a scheduled function would bring much problems... What errors did you get?

Guys, Try this for a change as a possible alternative way to handle cargo ... http://flightcontrol-master.github.io/MOOSE/ Expecially this class of the MOOSE framework: http://flightcontrol-master.github.io/MOOSE/Documentation/Cargo.html Warning; there is a learning curve... Watch these videos here: Watch these videos to setup your moose environment. Watch my signature below for further help with this framework... kind regards, Sven

Thanks Grimes for the explanations. A generic note though ... And not meant to you personally or ED, just an observation ... It is great reading this, and makes me also worry a bit ... Added: WW2 Large formation task Added: WW2 Carpet bombing task Knowing that if you follow this link: https://forums.eagle.ru/showthread.php?t=138043 with the extract: 2.7. Build large formations of AI. AI_FORMATION makes AI GROUPs fly in formation of various compositions. The AI_FORMATION class models formations in a different manner than the internal DCS formation logic!!! The purpose of the class is to: * Make formation building a process that can be managed while in flight, rather than a task. * Human players can guide formations, consisting of larget planes. * Build large formations (like a large bomber field). * Form formations that DCS does not support off the shelve. AI_FORMATION Demo Missions: FOR - AI Group Formation AI_FORMATION demonstration missions: * FOR-100 - Bomber Left Line Formation * FOR-101 - Bomber Right Line Formation * FOR-102 - Bomber Left Wing Formation * FOR-103 - Bomber Right Wing Formation * FOR-104 - Bomber Center Wing Formation * FOR-105 - Bomber Trail Formation * FOR-106 - Bomber Box Formation Note: The AI_FORMATION is currently a first version showing the potential, a "building block". From this class, further classes will be derived and the class will be fine-tuned. ---- Somehow we have been building in parallel the same functionality. What can I say. Some people in our moose community have told me I should hold this off this development ... But I haven't ... And the reason why I haven't is the following: 1. The AI_FORMATION will treat the formation flying not as a task, but as a process. That means that during formation flight, events can be triggered to tweak or update the formation, stop the formation, re-engage the formation etc. 2. I very well could use the new TASK components in the formation flying logic. 3. At the time people told me, there were some videos posted, but never an official announcement or anything. So all was an assumption. We did not know neither in what form this formation flying would come. So bottom line, maybe I spend time that is now in the waste basket, or maybe not ... Don't know. Time will learn. It is this code that I talk about for the formation flying ... --- @param Follow#AI_FORMATION self function AI_FORMATION:onenterFollowing( FollowGroupSet ) --R2.1 self:F( ) self:T( { self.FollowUnit.UnitName, self.FollowUnit:IsAlive() } ) if self.FollowUnit:IsAlive() then local ClientUnit = self.FollowUnit self:T( {ClientUnit.UnitName } ) local CT1, CT2, CV1, CV2 CT1 = ClientUnit:GetState( self, "CT1" ) if CT1 == nil or CT1 == 0 then ClientUnit:SetState( self, "CV1", ClientUnit:GetPointVec3() ) ClientUnit:SetState( self, "CT1", timer.getTime() ) else CT1 = ClientUnit:GetState( self, "CT1" ) CT2 = timer.getTime() CV1 = ClientUnit:GetState( self, "CV1" ) CV2 = ClientUnit:GetPointVec3() ClientUnit:SetState( self, "CT1", CT2 ) ClientUnit:SetState( self, "CV1", CV2 ) end FollowGroupSet:ForEachGroup( --- @param Wrapper.Group#GROUP FollowGroup -- @param Wrapper.Unit#UNIT ClientUnit function( FollowGroup, Formation, ClientUnit, CT1, CV1, CT2, CV2 ) FollowGroup:OptionROTPassiveDefense() FollowGroup:OptionROEReturnFire() local GroupUnit = FollowGroup:GetUnit( 1 ) local FollowFormation = FollowGroup:GetState( self, "FormationVec3" ) if FollowFormation then local FollowDistance = FollowFormation.x local GT1 = GroupUnit:GetState( self, "GT1" ) if CT1 == nil or CT1 == 0 or GT1 == nil or GT1 == 0 then GroupUnit:SetState( self, "GV1", GroupUnit:GetPointVec3() ) GroupUnit:SetState( self, "GT1", timer.getTime() ) else local CD = ( ( CV2.x - CV1.x )^2 + ( CV2.y - CV1.y )^2 + ( CV2.z - CV1.z )^2 ) ^ 0.5 local CT = CT2 - CT1 local CS = ( 3600 / CT ) * ( CD / 1000 ) / 3.6 local CDv = { x = CV2.x - CV1.x, y = CV2.y - CV1.y, z = CV2.z - CV1.z } local Ca = math.atan2( CDv.x, CDv.z ) local GT1 = GroupUnit:GetState( self, "GT1" ) local GT2 = timer.getTime() local GV1 = GroupUnit:GetState( self, "GV1" ) local GV2 = GroupUnit:GetPointVec3() GV2:AddX( math.random( -Formation.FlightRandomization / 2, Formation.FlightRandomization / 2 ) ) GV2:AddY( math.random( -Formation.FlightRandomization / 2, Formation.FlightRandomization / 2 ) ) GV2:AddZ( math.random( -Formation.FlightRandomization / 2, Formation.FlightRandomization / 2 ) ) GroupUnit:SetState( self, "GT1", GT2 ) GroupUnit:SetState( self, "GV1", GV2 ) local GD = ( ( GV2.x - GV1.x )^2 + ( GV2.y - GV1.y )^2 + ( GV2.z - GV1.z )^2 ) ^ 0.5 local GT = GT2 - GT1 -- Calculate the distance local GDv = { x = GV2.x - CV1.x, y = GV2.y - CV1.y, z = GV2.z - CV1.z } local Alpha_T = math.atan2( GDv.x, GDv.z ) - math.atan2( CDv.x, CDv.z ) local Alpha_R = ( Alpha_T < 0 ) and Alpha_T + 2 * math.pi or Alpha_T local Position = math.cos( Alpha_R ) local GD = ( ( GDv.x )^2 + ( GDv.z )^2 ) ^ 0.5 local Distance = GD * Position + - CS * 0,5 -- Calculate the group direction vector local GV = { x = GV2.x - CV2.x, y = GV2.y - CV2.y, z = GV2.z - CV2.z } -- Calculate GH2, GH2 with the same height as CV2. local GH2 = { x = GV2.x, y = CV2.y + FollowFormation.y, z = GV2.z } -- Calculate the angle of GV to the orthonormal plane local alpha = math.atan2( GV.x, GV.z ) local GVx = FollowFormation.z * math.cos( Ca ) + FollowFormation.x * math.sin( Ca ) local GVz = FollowFormation.x * math.cos( Ca ) - FollowFormation.z * math.sin( Ca ) -- Now we calculate the intersecting vector between the circle around CV2 with radius FollowDistance and GH2. -- From the GeoGebra model: CVI = (x(CV2) + FollowDistance cos(alpha), y(GH2) + FollowDistance sin(alpha), z(CV2)) local CVI = { x = CV2.x + CS * 10 * math.sin(Ca), y = GH2.y - ( Distance + FollowFormation.x ) / 5, -- + FollowFormation.y, z = CV2.z + CS * 10 * math.cos(Ca), } -- Calculate the direction vector DV of the escort group. We use CVI as the base and CV2 as the direction. local DV = { x = CV2.x - CVI.x, y = CV2.y - CVI.y, z = CV2.z - CVI.z } -- We now calculate the unary direction vector DVu, so that we can multiply DVu with the speed, which is expressed in meters / s. -- We need to calculate this vector to predict the point the escort group needs to fly to according its speed. -- The distance of the destination point should be far enough not to have the aircraft starting to swipe left to right... local DVu = { x = DV.x / FollowDistance, y = DV.y, z = DV.z / FollowDistance } -- Now we can calculate the group destination vector GDV. local GDV = { x = CVI.x, y = CVI.y, z = CVI.z } local ADDx = FollowFormation.x * math.cos(alpha) - FollowFormation.z * math.sin(alpha) local ADDz = FollowFormation.z * math.cos(alpha) + FollowFormation.x * math.sin(alpha) local GDV_Formation = { x = GDV.x - GVx, y = GDV.y, z = GDV.z - GVz } if self.SmokeDirectionVector == true then trigger.action.smoke( GDV, trigger.smokeColor.Green ) trigger.action.smoke( GDV_Formation, trigger.smokeColor.White ) end local Time = 60 local Speed = - ( Distance + FollowFormation.x ) / Time local GS = Speed + CS if Speed < 0 then Speed = 0 end -- Now route the escort to the desired point with the desired speed. FollowGroup:RouteToVec3( GDV_Formation, GS ) end end end, self, ClientUnit, CT1, CV1, CT2, CV2 ) self:__Follow( -0.5 ) end end

There seems to be a (new) problem in Single Player with CA. I remember that when i joined CA units using ALT-J, I could retrieve the "player name" of that unit, which used to be "killer". That seems to have stopped working too ... <dissapointed> Run the attached mission. There are 2 airplane slots and a 2 command slots. Suggest you do the following actions: 1. Join an airplane slot. You'll see the "player name" appearing who is in the slot. 2. Join now a CA unit from the map using ALT-J. The "name" of the player does not appear. The mission runs in continuous trigger mode the following code (thus every second). function ShowPlayers() local CoalitionsData = { AlivePlayersRed = coalition.getPlayers( coalition.side.RED ), AlivePlayersBlue = coalition.getPlayers( coalition.side.BLUE ) } for CoalitionId, CoalitionData in pairs( CoalitionsData ) do for UnitId, UnitData in pairs( CoalitionData ) do if UnitData and UnitData:isExist() then local UnitName = UnitData:getName() local PlayerName = UnitData:getPlayerName() trigger.action.outText( PlayerName .. " in " .. UnitName, 5 ) end end end end Can somebody please have a look at this problem and check if this needs to be reported or not? There is currently no way to test in DCS when a player has joined a CA unit or not. Not in Single Player Mode, not in Multiple Player Mode ... The problem seems to be with the API coalition.getPlayers( coalition.side ). This API does not return the players that have joined a CA unit :-( May I take the freedom to say this is a problem :-) ? thanks in advance for checking, Sven BUG-002 - coalition.getPlayerNames for CA not working.miz BUG-002 - coalition.getPlayerNames for CA not working.lua

I think you could be right. I will try to build in a spawn "delay and queue" method in the framework to avoid these lock-ups. Max one airplane can be taking off ... Good idea and thanks!

To give a bit more info, i "think" it only happens when planes are spawned at the airport. So, when you create a mission and put planes at the airport for take-off, this problem won't happen. There seems to be a glitch with the airport traffic controller getting confused when planes spawn in. Maybe there is a workaround for this problem?

I made the video to show there is a problem. Others have confirmed this too. Not only at Anapa, but at other airports too.

Sorry but there is no workaround for this mate.

Is there an update on this issue please? Somebody looked at this? Thanks!

Just published MOOSE Release 2.1.4, a couple of bug fixes have been done.

Have a look here, in chapter 1.8 http://flightcontrol-master.github.io/MOOSE/Documentation/Scoring.html

I once had code using co-routines and those go horribly wrong... In many ways. Simply forget using co-routines and scheduled calls. Normally you should be able to remove entries in a table. Scheduled calls are in the same thread. Only using co-routines a multi threaded environment can be setup but forget it to make it work in dcs... There problem is that co-routines aren't pre-emptive and neither are event driven. That means you need to write yourself a thread routine scheduler for these routines and asynchronous processing can only be achieved using scheduled calls. You can't call a co-routine and let dcs do something else in the meanwhile. The old code i wrote is commented out in the SET_BASE class... But when using co-routines, the scheduled co-routine calls would crash after garbage collection.