FlightControl

You see, the more people on the server, the better. I'll write up a manual how to use the tasking system, better, I'll make a video of it.

I was not kidding. You don't need to be an ace. Hit a few targets, and crash into the ground etc. I need "destructive testing".

The worser you are the better :-) Please come on board. You find the server? And join on slack, so we can call each other. Sven

Anybody here who would have time to fly with me a multi player mission for test on server "MOOSE A2A Playground" in DCS 1.5.6?

As I explain, the class and mission that i posted below handles all of this stuff!

There is an option "disperse under fire", you can turn that off.

Hi, DCS 1.5.6 In a client/server setup, client connected to server, there is an issue with ground late activated units that get activated. So, when you have a running connection to a server, in a running mission, and a late activated ground unit gets activated, it shows on the server as activated and you see it running on the map and in external view. But on the client, the unit just stays where it is. It does not move. There is no indication of movement at all on the client side. Nothing. You don't see it on the map, and you don't see it in external view as moving. When you have the late activated ground unit with flag "show before active" set, you see it, but it still does not move! If you then disconnect the client, and rejoin the client, then you see the unit moving!!! This is a quite inconvenient error! Can somebody at ED look at this issue please? I can run a test mission if you want. I mean, people wanna see ground units moving, no? Even if they were late activated or not. @Grimes are you aware of this error? Sven

Maybe this is also an option? It keeps the runway healthy. https://forums.eagle.ru/showpost.php?p=3182635&postcount=9

If you like, you can try out this CLEANUP process in a demo mission here: https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/release-2-2-pre/ACL%20-%20Airbase%20Cleaner/ACL-001%20-%20Airbase%20CleanUp The module is in pre-release, but you can include the moose.lua file in your missions which is located here: https://github.com/FlightControl-Master/MOOSE/blob/release-2-2-pre/Moose%20Mission%20Setup/Moose.lua The include process is the same as you would do with MIST, using a trigger. The following sets up a airbase cleaning for Batumi: Clean = CLEANUP:New( AIRBASE.Caucasus.Batumi ) This would do the same: Clean = CLEANUP:New( "Batumi" ) This will setup for 2 airbases: Clean = CLEANUP:New( { AIRBASE.Caucasus.Batumi, AIRBASE.Caucasus.Kutaisi } ) Note that this module is pre release. Detailed documentation is in process. Let me know what you think of this. Fc

Indeed! The slightest collision between two planes halts an airbase. You can bomb a base, or planes can crash at the base, as long as they aren't happening above a runway or taxiway. That being said, till dcs 1.2.6 there was a remedy. The trick was to destroy the objects right before they would be dead. By catching the S_EVENT_CRASH or S_EVENT_DEAD, of planes, vehicles, bombs etc, you could ensure that airbases were kept clean... That trick does not work anymore in DCS 1.5 and DCS 2.1. During the event handling, if you destroy the initiator object, the object won't be removed anymore... So an explosion will happen and the airbase will halt. There is a crappy solution however that I created within MOOSE. It is the CLEANUP class, which did initially as described above, but since DCS 1.5 I worked around the DCS engine problem by "preventing that any unit can drop on the runway". It is not a 100% safe solution, but had good coverage keeping runways clean... Let me post here a solution for your guys when i am back behind my laptop. FC

Found it! The event S_EVENT_PLAYER_LEAVE_UNIT is also fired when the player is connected to the server from a client machine, and when he does the following actions: 1. Select from spectators a slot (plane). 2. Don't press "Briefing", but immediately select another slot (plane). Then the S_EVENT_PLAYER_LEAVE_UNIT will be fired when switching slots, but no initiator field will be populated! So, this is something that is worth sharing to the community. Don't consider this to be a bug. I can easily fix this in the framework in the event dispatcher, now I know why this happens. There is no loss of information neither. When a player joins a unit and flies, and then does Quit, Back to Spectators or just leaves the sim, the S_EVENT_PLAYER_LEAVE_UNIT is correctly fired with the initiator field populated. @Grimes; Don't submit a ticket, not needed! Sorry for disturbing. FC

Talked too soon... Here is a problem situation ...: Initiator is nil !!! And this without any network, just on localhost. 01163.389 INFO NET: onPlayerSlot(2, 100) 01163.389 INFO NET: passed onPlayerTryChangeSlot 01163.389 INFO NET: release unit 132 01163.389 INFO SCRIPTING: 5123( 13)/E: EVENT00000.onEvent({[1]="S_EVENT_PLAYER_LEAVE_UNIT",[2]={["id"]=20,["time"]=27876.602,},[5]=-1,}) 01163.389 INFO SCRIPTING: 44867( 44290)/F: MISSION00104.AbortUnit({}) 01163.389 INFO SCRIPTING: Error in SCHEDULER function:[string "C:\Users\fligh\AppData\Local\Temp\DCS\/~mis00001345"]:44871: attempt to index local 'PlayerUnit' (a nil value) 01163.389 INFO SCRIPTING: stack traceback: [string "C:\Users\fligh\AppData\Local\Temp\DCS\/~mis00001345"]:4999: in function <[string "C:\Users\fligh\AppData\Local\Temp\DCS\/~mis00001345"]:4995> [string "C:\Users\fligh\AppData\Local\Temp\DCS\/~mis00001345"]:44871: in function 'AbortUnit' [string "C:\Users\fligh\AppData\Local\Temp\DCS\/~mis00001345"]:44290: in function <[string "C:\Users\fligh\AppData\Local\Temp\DCS\/~mis00001345"]:44285> (tail call): ? [C]: in function 'xpcall' [string "C:\Users\fligh\AppData\Local\Temp\DCS\/~mis00001345"]:5250: in function 'onEvent' [string "Scripts/World/EventHandlers.lua"]:13: in function <[string "Scripts/World/EventHandlers.lua"]:11>

It is really strange. So I've been doin tests on my local machine. So run a DCS Server on a local Windows user session (3D off etc), and then connect to this server using IP 127.0.0.1 from a full DCS Client. And guess what... Now it works, and I just cannot resimulate this problem. The initiator field is correctly provided and no problem finding all the relevant fields, including player name... Note that this is a test with one remote player connected on a local host... But I do see the same messages appearing (the 3 lines of NET in the front)... So that is not the issue neither ... 00414.274 INFO NET: onPlayerSlot(2, 132) 00414.274 INFO NET: passed onPlayerTryChangeSlot 00414.274 INFO NET: release unit 100 00414.279 INFO SCRIPTING: 5123( 13)/E: EVENT00000.onEvent({[1]="S_EVENT_PLAYER_LEAVE_UNIT",[2]={["IniUnit"]={["UnitName"]="Defender",["ClassName"]="UNIT",},["IniCoalition"]=1,["IniPlayerName"]="FlightControl",["initiator"]={["id_"]=16777474,},["id"]=20,["IniTypeName"]="Su-27",["IniObjectCategory"]=1,["IniUnitName"]="Defender",["IniCategory"]=0,["IniGroupName"]="Defender",["time"]=27127.486,["IniDCSGroup"]={["id_"]=37,},["IniGroup"]={["_Menus"]={["Command Center (Lima)@Mission \"A2A Mission (High)\"@Statistics Reports@Report Mission Progress"]={["Path"]="Command Center (Lima)@Mission \"A2A Mission (High)\"@Statistics Reports@Report Mission Progress",["MenuText"]="Report Mission Progress",["MenuPath"]={[1]="Command Center (Lima)",[2]="Mission \"A2A Mission (High)\"",[3]="Statistics Reports",[4]="Report Mission Progress",},["ParentMenu"]={["Path"]="Command Center (Lima)@Mission \"A2A Mission (High)\"@Statistics Reports",["MenuText"]="Statistics Reports",["MenuPath"]={[1]="Command Center (Lima)",[2]="Mission \"A2A Mission (High)\"",[3]="Statistics Reports",},["ParentMenu"]={["Path"]="Command Center (Lima)@Mission \"A2A Mission (High)\"",["MenuText"]="Mission \"A2A Mission (High)\"",["MenuPath"]={[1]="Command Center (Lima)",[2]="Mission \"A2A Mission (High)\"",},["ParentMenu"]={["Menus"]={["Mission \"A2A Mission (High)\""]=,},["MenuText"]="Command Center (Lima)",["Coalition"]=1,["ClassName"]="MENU_COALITION",["MenuPath"]={[1]="Command Center (Lima)",},["MenuCount"]=1,},["MenuGroup"]=,["ClassName"]="MENU_GROUP",["MenuGroupID"]=37,["MenuCount"]=4,},["MenuGroup"]=,["ClassName"]="MENU_GROUP",["MenuGroupID"]=37,["MenuCount"]=2,},["ClassName"]="MENU_GROUP_COMMAND",["MenuGroupID"]=37,["MenuGroup"]=,},["System Settings@Player Settings@Settings \"FlightControl\"@A2G Coordinate System@MGRS Accuracy 2"]={["Path"]="System Settings@Player Settings@Settings \"FlightControl\"@A2G Coordinate System@MGRS Accuracy 2",["MenuText"]="MGRS Accuracy 2",["MenuPath"]={[1]="System Settings",[2]="Player Settings",[3]="Settings \"FlightControl\"",[4]="A2G Coordinate System",[5]="MGRS Accuracy 2",},["ParentMenu"]={["Path"]="System Settings@Player Settings@Settings \"FlightControl\"@A2G Coordinate System",["MenuText"]="A2G Coordinate System",["MenuPath"]={[1]="System Settings",[2]="Player Settings",[3]="Settings \"FlightControl\"",[4]="A2G Coordinate System",},["ParentMenu"]={["Path"]="System Settings@Player Settings@Settings \"FlightControl\"",["MenuText"]="Settings \"FlightControl\"",["MenuPath"]={[1]="System Settings",[2]="Player Settings",[3]="Settings \"FlightControl\"",},["ParentMenu"]={["Path"]="System Settings@Player Settings",["MenuText"]="Player Settings",["MenuPath"]={[1]="System Settings",[2]="Player Settings",},["ParentMenu"]={["Menus"]={[table: 00000000393DB0A0]={["Menus"]={[table: 0000000033C02628]={["Menus"]={[table: 0000000032B367E0]={["MenuPath"]={[1]="System Settings",[2]="Default Settings",[3]="A2A Coordinate System",[4]="Activate BULLS",},["ClassName"]="MENU_MISSION_COMMAND",["ParentMenu"]=,["MenuText"]="Activate BULLS",},},["MenuText"]="A2A Coordinate System",["MenuPath"]={[1]="System Settings",[2]="Default Settings",[3]="A2A Coordinate System",},["ClassName"]="MENU_MISSION",["ParentMenu"]=,},[table: 0000000037B3B540]={["Menus"]={[table: 0000000037B0F5E0]={["MenuPath"]={[1]="System Settings",[2]="Default Settings",[3]="A2G Coordinate System",[4]="MGRS Accuracy 3",},["ClassName"]="MENU_MISSION_COMMAND",["ParentMenu"]=,["MenuText"]="MGRS Accuracy 3",},[table: 000000003392F7B0]={["MenuPath"]={[1]="System Settings",[2]="Default Settings",[3]="A2G Coordinate System",[4]="Activate LL",},["ClassName"]="MENU_MISSION_COMMAND",["ParentMenu"]=,["MenuText"]="Activate LL",},[table: 0000000032E34B20]={["MenuPath"]={[1]="System Settings",[2]="Default Settings",[3]="A2G Coordinate System",[4]="MGRS Accuracy 1",},["ClassName"]="MENU_MISSION_COMMAND",["ParentMenu"]=,["MenuText"]="MGRS Accuracy 1",},[table: 00000000C3F57D10]={["MenuPath"]={[1]="System Settings",[2]="Default Settings",[3]="A2G Coordinate System",[4]="Activate BRA"

I will do some more tests in a MP setup (server and client), and will report back. I am currently installing a server on my machine (under another user). You can run a DCS server on the same machine, just create another windows user and logon, install dcs, and run as a server with 3D render disabled. No mods or anything. Then back on your normal windows user, you can connect to the server using IP 127.0.0.1. (localhost). The only thing you need is sufficient memory, like 12GB. CPU is not an issue if your PC has 4 cores, DCS only uses 1. It is a bit of a hassle to switch between users, but it is functional. An alternative could be to install a VM, but that works slower and costs extra f.e. a new windows install license. Sven

Hi Grimes, thanks for reaching out. I ran this morning a test for the new tasking engine in the framework with another person and also using his server. So we ran a MP mission on 1 dedicated server, 2 players logged on as a client to the server. And this situation appears soon, when we changed slots. DCS version 1.5.6. I also saw this in the logging on the server: 01318.206 INFO NET: onPlayerSlot(3, 144) 01318.206 INFO NET: passed onPlayerTryChangeSlot 01318.206 INFO NET: release unit 140 01318.206 INFO SCRIPTING: 5123( 13)/E: EVENT00000.onEvent({[1]="S_EVENT_PLAYER_LEAVE_UNIT",[2]={["id"]=20,["time"]=28237.301,},[5]=-1,}) To my current understanding, there wasn't an slmod or something like that running on the server. (Wasn't my server). I will do some more testing on this issue here at home, until I better understand the scenario when this occurs. Maybe you can do this kind of test also? Sven

Anybody having any idea why sometimes the initiator field in the event S_EVENT_PLAYER_LEAVE_UNIT is empty??? This happens only in multi player. @Grimes, is this a reported bug? See the serialized unmodified EventData that i receive (element 2 of the array): EVENT00000.onEvent({[1]="S_EVENT_PLAYER_LEAVE_UNIT",[2]={["id"]=20,["time"]=28237.301,},[5]=-1,}) There is no way to know which player has left which unit? FC

Babylonic confusion. The getRadar DCS api does not work for ships. true. What has this to do with the framework?

An example... --- -- Name: ZON-500 - Polygon Zone -- Author: FlightControl -- Date Created: 18 Feb 2017 -- -- # Situation: -- -- A ZONE_POLYGON has been defined, which boundaries are smoking. -- A vehicle is driving through the zone perimeters. -- When the vehicle is driving in the zone, a red smoke is fired from the vehicle location. -- -- # Test cases: -- -- 1. Observe the polygon perimeter smoke. -- 2. Observe the vehicle smoking a red smoke when driving through the zone. GroupInside = GROUP:FindByName( "Test Inside Polygon" ) GroupOutside = GROUP:FindByName( "Test Outside Polygon" ) GroupPolygon = GROUP:FindByName( "Polygon A" ) PolygonZone = ZONE_POLYGON:New( "Polygon A", GroupPolygon ) PolygonZone:SmokeZone( SMOKECOLOR.White, 20 ) Messager = SCHEDULER:New( nil, function() GroupInside:MessageToAll( ( GroupInside:IsCompletelyInZone( PolygonZone ) ) and "Inside Polygon A" or "Outside Polygon A", 1 ) if GroupInside:IsCompletelyInZone( PolygonZone ) then GroupInside:GetUnit(1):SmokeRed() end end, {}, 0, 1 )More examples can be found here including demonstration missions that you can run. https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master-release/ZON%20-%20Zones kind regards, Sven

This meeting never took place, because nobody was interested in such a workshop.

Could be. Dunno. Highly likely you're right.

Ha YES! Thanks, that is a good idea stonehouse. Just spawn a static, it will resolve the CPU overhead and also will make a better simulation experience. Will think about this. For the moment however, i am now finalizing the TASK_A2A_DISPATCHER, which is TASK dispatching for HUMAN PLAYERS, somewhat the counterpart of the AI_A2A_DISPATCHER. Both will be included in the 2.2 release of MOOSE. I am currently fixing bugs and documenting stuff. Also a lot of work, and time consuming. Later, when the release is okay and working, based on the discussions we had on our slack site, I'll try to finish that template to make it "easier" for people to use this. Sven

Hey Matador, Thanks. To answer your first question: There are three different ranges at play in the logic. (I just added one today). 1. The "Grouping Range": So once a target has been detected, the logic will check if there are other detected targets within the Grouping Range of the first detected target. If there are, then these targets will be added to the same "Target Area". So multiple Target Areas will be formed, consisting of X targets. The amount of targets within a Target Area will determine the amount of defenders to be engaged From Cap or Gci. Note that the overhead parameter can influence the amount of defenders being engaged to those targets. 2. The "Engage Range": This will influence as the video explains, the evaluation which airborne friendlies are "in range" around each detected target. Airborne friendlies can be those that are "patrolling" or "returning" from a previous battle. 3. The "Intercept Range" or "Gci Range": EWR networks can detect targets over a very long range, especially with AWACS. But you don't want to submit a GCI when your target is more than 300km away. Thats what the Gci Range does, it will only submit GCI from the nearest airbase to target, when the distance between airbase and target is lower than the Gci Range. To answer you second question: This is a good idea. Thinking about it, a few questions though: 1. The only way to get planes spawned at airbases without them flying off, is to spawn them "uncontrolled". Once these planes would need to be "activated", these would be spawned accoding the TakeOff setting per squadron. So I see your idea as a way to spawn those airplanes in advance, at the airbase of the squadron, waiting for takeoff... This WILL however have impact on performance. I could add a method on Squadron level to configure the airplanes to be spawned before activation. But then i'll need to check which planes are alraedy dead and which not :-) 2. Uncontrolled planes have an impact on performance. 3. Shelters ... When you spawn planes some of them may arrive in a shelter. The shelter doors are opened, even when uncontrolled. 4. Available places at the airbase. It would be the most realistic scenario ever. Indeed, the amount of planes already at the airbase. However, It should be checked that the amount resources allocated at the squadron should not be more than the amount of places available at the airbase... Interesting requirement overall. So I have a suggestion. Will make the first version work and release it, and then I can add the uncontrolled airplanes before take-off. Hope this helps. Sven

i will help you. yesterday my availability was limited. Check you PM.

The thing needs to be considered as a whole, not just that one function, when you would design missions, i agree. The video and my question however, focuses on GCICAP, that is the subject of the function here for the discussion. So I completely am behind your points that, how people use GCICAP over the years is indeed a good question from a mission designer point of view.

For the ED team, a small note. This appears in the log: 00600.963 WARNING WRADIO: Can't create NDB "BS Belosarayskaya" beacon on the water! FC