FlightControl

In lua, there is a debug object present. It can be used for various purposes. http://www.lua.org/pil/23.html SLMOD puts debug to nil, resulting in a mission script not being able to trace-back the call stack when dropping a bug report in dcs.log. Also, it disables all tracing, which is used for debug reasons. Is there an option that you can keep the lua debug object?

In lua, there is a debug object present. It can be used for various purposes. http://www.lua.org/pil/23.html SLMOD puts debug to nil, resulting in a mission script not being able to trace-back the call stack when dropping a bug report in dcs.log. Also, it disables all tracing, which is used for debug reasons. Is there an option that you can keep the lua debug object?

Indeed. The issue is structural and likely not a quick fix will solve the problem.

Some more fixes for AI_A2A_GCICAP and AI_A2A_DISPATCHER Closest CAP is selected to engage closest intruder. Ensure that CAP is also engaging when there isn't any EWR network initially setup. Renamed method DETECTION_BASE:SetDetectionInterval() to DETECTION_BASE:SetRefreshTimeInterval(). This allows to modify the detection interval to a specified amount of seconds. Renamed method DETECTION_MANAGER:SetReportInterval() to DETECTION_MANAGER:SetRefreshTimeInterval(). This allows to modify the detection interval to a specified amount of seconds. Thanks Invisibull helping with testing! Ensure you download and include the latest moose.lua from the MOOSE release page: https://github.com/FlightControl-Master/MOOSE/releases FC

Guys, What are good strategies to defend EWR networks. So EWR is there to detect intruders "early" and provide a "warning". And are therefore the first line of defense. Without EWR, a coalition becomes blind. When you setup an EWR network consisting of ground radar vehicles, they become immediately vulnerable because they emit radar and become the first line of attack. I've seen that EWR has a certain limit in range of detection. The distance of detection is not really sufficient to get defense airplanes airborne from defending airbases, especially from a cold start. In other words, it seems that fast planes with long-range A2G ordonnance are able to destroy EWR before an interception can be done, and this is bad and I am not sure that this corresponds with real life ... Don't know. One of the defense methods I already apply is CAP, indeed. But there the problem is that they need to be airborne, and don't provide sufficient defenses when a large group of intruders are approaching the EWR. Maybe the placement of SAM S-300s could help, or are there other tactics that I am unaware of? FC

Guys, Implemented another important fix in the AI_A2A_GCICAP or AI_A2A_DISPATCHER module. CAP are now also engaging intruders, even when there isn't any EWR coverage. CAP are now part of the EWR network. So the dispatcher will order CAP to engage when the CAP detects intruders and reports them. Some of you have been awaiting this fix. So please check and tell me if this suits your needs. Note that the CAP is not just engaging any enemy when they detect targets. They are respecting borders and the engagement is coordinated. Fixed CAP not engaging problem. CAP become part of the EWR network. They are patrolling and reporting to the EWR their findings. Once they detect targets, the dispatcher will order certain patrols to engage. Fixed bug with a nil value when searching for friendlies in the vicinity. You can download the latest release from: https://github.com/FlightControl-Master/MOOSE/releases FC

@ED Can you please do a product release rollback to 1.5.6? (yes, revert the install of every customer back to 1.5.6). And run 1.5.7 in beta until all performance issues are fixed? You would have my full support to test put in beta. How long has 1.5.7 been in beta? These performance problems are going on too long now. FC

Okay, i tried to spawn a group at an airfield and set the skill of the first unit in the group to Client. The group does spawn, the unit does not appear. But unfortunately, the slot list does not get updated. So, you can't select the client from the slot list. I am sure it is spawned, i am quite sure it is, but you can't select it as there is nothing there... So forget it. We can't get too creative on this one. Until ED starts to realize that dynamic slot creation would be a great thing...

Am trying something out ... hold ...

I've added some other important fixes: This fixes aiplanes remaining on an airfield in case of AI_A2A_GCICAP or AI_A2A_DISPATCHER and the BAI to CAS task conversion when a player is nearby a BAI area while being assigned to the A2G task. Added DETECTION_BASE:FilterFriendliesCategory() method, which allows to filter friendlies based on the category of the units found. This method was required to be added to avoid counting airborne units as friendlies in A2G missions. It would result in tasks being converted from BAI to CAS when a player was nearby the target seated in an airplane, which is wrong. Now tasks won't be converted if a player seated in an airplane is near a BAI task area! AI_A2A_DISPATCHER: Planes remaining on the airfield is now fixed. The issue was with planes out of fuel doing CAP, which would return to a different airbase because they were out of control. At the landing, these weren't despawned. You can download the latest release from: https://github.com/FlightControl-Master/MOOSE/releases FC

Spawned groups are addressable, I use it all the time, but I think you haven't understood. The spawning of these groups is delayed because U use SpawnScheduled. So in your code, as i see, you declare your SPAWN object and do a scheduled spawning. So these groups will be spawned later. You need to catch the time when the group is spawned, and then act upon it. Otherwise these groups simply don't exist! On top, when you use SpawnScheduled, you'll see a group immediately appearing, but that is only perception!!! When you process your logic as you have shown me a few threads earlier, it won't work. A scheduled spawn will have a delay in spawning, even a fraction of a second. Maybe you need to use the SPAWN:Spawn() method! The :Spawn() method immediately spawns a group and will return the GROUP object instance! Spawn_Vehicle_1 = SPAWN:New( "target1" ) :InitLimit( 3, 3 ) :InitRandomizeRoute( 1, 4, 5000 ) -- The 3 vehicle groups spawn successfully and begin their randomized route -- They are named according to the map as target1#001-#003 MESSAGE:New("DEBUG: MOOSE LOADED",10,"MOOSE Event"):ToAll() local HeliGroup = GROUP:FindByName( "FAC01") local GroupInside = GROUP:FindByName( "helo1") --local target1 = GROUP:FindByName("target1#001") --this doesn't work, but if I used GROUP:FindByName("target1") it does. [color=Red]target1 = Spawn_Vehicle_1:Spawn()[/color] if (target1) then MESSAGE:New("DEBUG: TARGET1 initialized",10,"MOOSE Event"):ToAll() endBut I really think you should have a careful look at the :OnSpawnGroup() method!

Okay, so you use the SpawnScheduled method. This spawns new groups according the schedule, but you need the "event" when a group is created, and use that group to do actions, correct? Fortunately, that exists :-) Have a look here: http://flightcontrol-master.github.io/MOOSE/Documentation/Spawn.html##(SPAWN).OnSpawnGroup This is the code that is useful: -- Declare SpawnObject and call a function when a new Group is spawned. local SpawnObject = SPAWN :New( "SpawnObject" ) :InitLimit( 2, 10 ) :OnSpawnGroup( function( SpawnGroup ) SpawnGroup:E( "I am spawned" ) end ) :SpawnScheduled( 300, 0.3 ) So the function that receives the parameter SpawnGroup is called when a new group is spawned. If you use IntelliSense and LDT, you can add the following in front of the function: --- @param Wrapper.Group#GROUP SpawnGroup This will make the SpawnGroup variable known to the LDT IntelliSense type list. You can then inspect SpawnGroup and its methods. Hope this helps FC

Implemented a bunch of new fixes. Some are important changes. The most important are improvement for the AI_A2A_DISPATCHER or the AI_A2A_GCICAP module. Fixed CAP and GCI issues. DETECTION now has a "cache" that keeps the last coordinates after a detection. TASKING and DISPATCHER now use the coordinate cache instead of the real coordinates. Bottom line, you'll notice that the coordinates of detected targets are only updated if a detection run happens. That means that when you arrive at the target vicinity, you will still need to "search" for the exact targets, as they may have moved since the last detection :-) Updated TASK_A2G_DISPATCHER, in terms of assigned task updating and planned task updating... Fixed DETECTION reports, and COORDINATE reports. When a source controllable is not given and the requested format is BR or BRAA, the COORDINATE is formatted as MGRS. See details here: DETECTION has now a detection "cache" that contains the last detected targets and coordinates. AI_A2A_DISPATCHER now uses the DETECTION cache. So until a new DETECTION is done, the coordinates aren't updated! TASK_A2G_DISPATCHER now uses the DETECTION cache. So until a new DETECTION is done, the coordinates aren't updated! AI_A2A_DISPATCHER: CAP now counts correctly per squadron. The specified amount of CAP will work now. AI_A2A_DISPATCHER: CAP now schedules at different start times, and have different repeat times. More random. AI_A2A_DISPATCHER: GCI is now correctly spawning. AI_A2A_DISPATCHER: Fixed issue with waypoints working differently in 2.1.1 as in 1.5.7!!! It cause big issues. AI_A2A_DISPATCHER: Solved issue with CAP not engaging target. DETECTION problem with ESCORT fixed! DESIGNATE can now lase targets with specific laser codes upon request by players. Methods :AddMenuLaserCode() and :RemoveMenuLaserCode() added, which allow to set or delete specific additional menu options in the lase menu for players to lase with specific codes. This comes in handy for the SU-25T and the A-10A and other planes. Detection reports of DETECTION classes now are returned as a REPORT object. So they can be streamed with various delimiters \n or , or other... If a coordinate needs to be represented by BR or BRAA, then a "source" controllable is required, which is usually the player aircraft. If not given, the coordinate will be returned in MGRS format !!! TASK_A2G_DISPATCHER task updating is now improved. New tasks when defined for the first time aren't dissapearing from the menu and appearing again. They are consistent. The whole task dispatching has been reworked and is now much more consistent. The conversion of assigned tasks are now improved. The conversion of planned tasks are also improved. TASK_A2A_DISPATCHER: Need to do the same as above. You can download the latest release from: https://github.com/FlightControl-Master/MOOSE/releases FC

Ok … The SETTINGS work specifically with: TASK_A2G_DISPATCHER TASK_A2A_DISPATCHER DESIGNATE DETECTION_AREAS DETECTION_TYPES DETECTION_UNITS And for ESCORT too, but for that you need a fix that i did for you this morning. Can you wait till tomorrow? Maybe run this test mission here: https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master/TAD%20-%20Task%20Dispatching/TAD-105%20-%20A2G%20Task%20Dispatching%20DETECTION_AREAS

My pleasure, these kind of questions let me know that there are people using some stuff of the framework. So something must be right about it :) What stuff are U using of it? Any other questions?

SETTINGS are embedded in many classes now, that use the SETTINGS selected. So, it depends what you wanna do ... Can you explain this a bit?

Check out MOOSE ... It supports coordinate communication in A2G and A2A formats. A2G: BR, LL Decimal Minute, LL Minute Second, MGRS, BULLS A2A: BRAA, LL Decimal Minute, LL Minute Second, MGRS, BULLS It provides a settings menu where players can select which settings they want for A2G and A2A modes. I also saw your note on ESCORT and have fixed the issue with escorts not "detecting" units. They did but there was a problem with the reporting. I will publish a fix in a couple of days. Stay tuned!

Sure! Check the SPAWNSTATIC class! It allows to "spawn" dynamically new static objects into your running mission. You need to "import" first all the static objects you wanna spawn into your mission as a "template". Just place them at a random location and give it a name. Then you can use the SPAWNSTATIC class to spawn new statics from the template. The reason why I opted for this method is that is avoid having to type complicated type names of static objects... Now you just use the name of the static you have given. For now, you can spawn STATICs in ZONEs (at random locations) and at specific COORDINATE locations. Note that ZONEs can be instances of: ZONE_POLYGON ZONE ZONE_RADIUS ZONE_GROUP ZONE_UNIT In other words, the sky is the limit! This is the documentation page of SPAWNSTATIC. Select the demo mission link for a demonstration mission. --- Name: SPS-100 - Simple Spawning -- Author: FlightControl -- Date Created: 09 Apr 2017 -- -- # Situation: -- -- At Gudauta spawn a static. -- -- # Test cases: -- -- 1. Observe that the static is spawned. local ZonePosition = ZONE:New( "Position" ) local SpawnBuilding = SPAWNSTATIC:NewFromStatic( "Building", country.id.GERMANY ) local SpawnBarrack = SPAWNSTATIC:NewFromStatic( "Barrack", country.id.GERMANY ) local ZonePointVec2 = ZonePosition:GetPointVec2() local Building = SpawnBuilding:SpawnFromZone( ZonePosition, 0 ) for Heading = 0, 360,60 do local Radial = Heading * ( math.pi*2 ) / 360 local x = ZonePointVec2:GetLat() + math.cos( Radial ) * 150 local y = ZonePointVec2:GetLon() + math.sin( Radial ) * 150 SpawnBarrack:SpawnFromPointVec2( POINT_VEC2:New( x, y ), Heading + 90 ) end Hope it helps. FC

Hi Rivvern, I am working on a pile of fixes in one github branch. There is also a new issue raised regarding this. It seems that when the EWR does not detect the intruder (you), the CAP won't do anything. Can you check if you were in EWR range when you had this issue? I am thinking on a solution for this problem. See here: https://github.com/FlightControl-Master/MOOSE/issues/670

Yep, and what does it say then? How much FPS?

Check here: https://forums.eagle.ru/showthread.php?t=138043

You need to look into the DESIGNATE functionality of the moose framework. DESIGNATE performs a JTAC functionality, but does it in a proprietary system. I will however add later proper JTAC radio commands in the system, so that capable planes can use the radio menu to communicate with the JTAC over the radio, but for now it just works with a proprietary logic using self created radio menus, which also allow russian era planes to use a JTAC function. It also allows to lase, smoke and illuminate targets. These targets may be dynamically spawned. gGX7GcCBq_E

Nope. Run an empty mission and do the same. What fps?

You can go to spectators and then press fly.

I agree. Fuel consumption is out of proportion. How long can an Su-27 be airborne in real life?