FlightControl

just note that this class is a prototype a lot more stuff to be added, and upon a discussion you can steer the evolution of this class, if you understand what i mean.

That is the whole idea of this class. FC

When using DETECTION_AREAS, are U using the :BoundDetectedZones() method?

OK. I can simulate the crash now, with this test mission! So it is definitely detection. The worrying part is, it only started to crash after i added the moving (red) vehicles. Searching further! 07347.758 INFO SCRIPTING: 17389( -1)/E: DETECTION_AREAS00306.function({[1]="Detecting",[2]="DetectionGroup",[3]="Detecting",}) 07366.750 WARNING LOG: 19 duplicate message(s) skipped. 07366.750 INFO SCRIPTING: 17705( 18541)/E: DETECTION_AREAS00306.AddChangeUnit({[1]="Change on Detection Item:",[2]=4,[3]="RU",[4]="Mi-24V",}) 07366.750 INFO SCRIPTING: 17705( 18541)/E: DETECTION_AREAS00306.AddChangeUnit({[1]="Change on Detection Item:",[2]=4,[3]="RU",[4]="Ka-50",}) 07366.751 INFO SCRIPTING: 17705( 18569)/E: DETECTION_AREAS00306.AddChangeUnit({[1]="Change on Detection Item:",[2]=7,[3]="AU",[4]="M1128 Stryker MGS",}) 07366.751 INFO SCRIPTING: 17705( 18569)/E: DETECTION_AREAS00306.AddChangeUnit({[1]="Change on Detection Item:",[2]=7,[3]="AU",[4]="Mi-24V",}) 07366.751 INFO SCRIPTING: 17694( 18579)/E: DETECTION_AREAS00306.AddChangeItem({[1]="Change on Detection Item:",[2]=8,[3]="AA",[4]="Ka-50",}) 07367.099 INFO EDCORE: try to write dump information 07367.117 INFO EDCORE: # -------------- 20171019-104518 -------------- 07367.134 INFO EDCORE: D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\edObjects.dll 07367.150 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 0D5E3434 00:00000000 07367.167 INFO EDCORE: 00000000 00000000 0000:00000000 07367.225 INFO EDCORE: 0D5E3434 00D7EAB0 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\edObjects.dll ?getObjectType@SceneObject@@UEBAPEAVIModel@model@@XZ()+4 07367.242 INFO EDCORE: F350535C 00D7EB10 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?getObjectType@woLandPoint@@UEBAPEAVIModel@model@@XZ()+2C 07367.243 INFO EDCORE: F34E3B96 00D7EB40 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?getDetectionPoint@MovingObject@@UEAA?AVVec3d@osg@@XZ()+26 07367.244 INFO EDCORE: F3541E49 00D7EDC0 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?buildTargetDetectionInfo@wDetector@@IEBAXPEAVMovingObject@@AEBVwTargetDetectionStatus@@AEAUwTargetDetectionInfo@@I@Z()+1F9 07367.245 INFO EDCORE: F354046E 00D7EFD0 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?checkTarget@wDetector@@UEAAIPEAVMovingObject@@AEAVwTargetDetectionStatus@@_N@Z()+12E 07367.246 INFO EDCORE: F7772291 00D7F000 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.246 INFO EDCORE: F7771FE0 00D7F200 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.247 INFO EDCORE: F7771DAB 00D7F2A0 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.247 INFO EDCORE: F7769DD1 00D7F370 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.248 INFO EDCORE: F7769060 00D7F3D0 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.248 INFO EDCORE: F7744F41 00D7F410 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.249 INFO EDCORE: F774470F 00D7F460 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.250 INFO EDCORE: F34D57CC 00D7F4A0 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?NextEvent@wWakeupTime@@UEAAXXZ()+2C 07367.250 INFO EDCORE: 1FF66E63 00D7F520 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\World.dll 07367.251 INFO EDCORE: 1FF67346 00D7F570 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\World.dll 07367.251 INFO EDCORE: F779DF36 00D7F5E0 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.253 INFO EDCORE: F77A87FE 00D7F640 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.253 INFO EDCORE: F74530DB 00D7F670 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.254 INFO EDCORE: F7454959 00D7FD20 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.256 INFO EDCORE: F78E781F 00D7FD60 0000:00000000 D:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\bin\DCS.exe 07367.259 INFO EDCORE: 330E2774 00D7FD90 0000:00000000 C:\WINDOWS\System32\KERNEL32.DLL BaseThreadInitThunk()+14 07367.259 INFO EDCORE: 33F50D51 00D7FDE0 0000:00000000 C:\WINDOWS\SYSTEM32\ntdll.dll RtlUserThreadStart()+21 07370.691 INFO EDCORE: Minidump created. 07370.691 ERROR SOUND: render time = 3.350026s exceeded allowed slice of 0.046440s 07370.692 INFO EDCORE: try to write track file DET-250 - Detection AREAS.miz

I've been trying to resimulate this crash, but can't. Can you resimulate this easily? If yes, can you post the mission please? Sven

Which airbase? Groom Lake?

Can you explain a bit more what you mean? azimuth split, range split?

Nope, DCS crashes when detecting!!! The crash to do with the detection of scenery objects on the nevada map... I will try to resimulate this crash and post an error report to ED. Sven 02731.764 INFO EDCORE: try to write dump information 02731.803 INFO EDCORE: # -------------- 20171019-001003 -------------- 02731.821 INFO EDCORE: Z:\DCS\DCS World 2 OpenAlpha\bin\edObjects.dll 02731.822 INFO EDCORE: # C0000005 ACCESS_VIOLATION at BAA43434 00:00000000 02731.825 INFO EDCORE: 00000000 00000000 0000:00000000 02731.838 INFO EDCORE: BAA43434 006FE8D0 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\edObjects.dll ?getObjectType@SceneObject@@UEBAPEAVIModel@model@@XZ()+4 02731.839 INFO EDCORE: A9F8535C 006FE930 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?getObjectType@woLandPoint@@UEBAPEAVIModel@model@@XZ()+2C 02731.840 INFO EDCORE: A9F63B96 006FE960 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?getDetectionPoint@MovingObject@@UEAA?AVVec3d@osg@@XZ()+26 02731.840 INFO EDCORE: A9FC1E49 006FEBE0 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?buildTargetDetectionInfo@wDetector@@IEBAXPEAVMovingObject@@AEBVwTargetDetectionStatus@@AEAUwTargetDetectionInfo@@I@Z()+1F9 02731.840 INFO EDCORE: A9FC046E 006FEDF0 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?checkTarget@wDetector@@UEAAIPEAVMovingObject@@AEAVwTargetDetectionStatus@@_N@Z()+12E 02731.841 INFO EDCORE: F8842291 006FEE20 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.841 INFO EDCORE: F8841FE0 006FF020 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.841 INFO EDCORE: F8841DAB 006FF0C0 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.841 INFO EDCORE: F8839DD1 006FF190 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.841 INFO EDCORE: F8839060 006FF1F0 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.842 INFO EDCORE: F8814F41 006FF230 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.842 INFO EDCORE: F881470F 006FF280 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.842 INFO EDCORE: A9F557CC 006FF2C0 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\WorldGeneral.dll ?NextEvent@wWakeupTime@@UEAAXXZ()+2C 02731.843 INFO EDCORE: BD096E63 006FF340 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\World.dll 02731.843 INFO EDCORE: BD097346 006FF390 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\World.dll 02731.843 INFO EDCORE: F886DF36 006FF400 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.843 INFO EDCORE: F88787FE 006FF460 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.844 INFO EDCORE: F85230DB 006FF490 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.844 INFO EDCORE: F8524959 006FFB40 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.845 INFO EDCORE: F89B781F 006FFB80 0000:00000000 Z:\DCS\DCS World 2 OpenAlpha\bin\DCS.exe 02731.847 INFO EDCORE: D7512774 006FFBB0 0000:00000000 C:\WINDOWS\System32\KERNEL32.DLL BaseThreadInitThunk()+14 02731.847 INFO EDCORE: D84D0D51 006FFC00 0000:00000000 C:\WINDOWS\SYSTEM32\ntdll.dll RtlUserThreadStart()+21

I will look into this with big magnifying glasses! Sven

OK. This may need indeed a bit of explanation... You may have been looking at missions and found a lot of triggers, correct? MOOSE or other scripts use the "scripting engine" of DCS, also subnamed "SSE". This is a set of application program interfaces (APIs) that can be called using the lua language. In other words, MOOSE is "skipping" the Graphical User Interface trigger mechanism embedded within missions, and is directly loading a "mission scripts", using the DO SCRIPT FILE mechanisms. That is why you see only two triggers in the mission. The first trigger loads moose.lua, and the second the actual mission script, which is using the MOOSE classes to orchestrate the mission. Both Moose.lua and the other lua file are embedded in the .miz file! You can unzip the .miz file yourself using unzip of 7z or any other zip tool and check for yourself! RAT is a class of MOOSE, but there are many other classes now that you can use to make missions, which are all included and defined within the moose.lua file. Consider the moose.lua file as the "definition" of the moose framework, and after loading it in your mission, you can use any MOOSE class to do more advanced stuff. The funny thing about mission design is that you can design a mission using a mixture of triggers and other DCS mission editor capabilities and scripts and even MOOSE framework classes or objects. In other words, you don't have to have only 2 DO SCRIPT FILE triggers in the beginning of your missions, but you are free to use scripting within the mission editor as well! (Just note that lua predicates is bugged in DCS since release 1.5, which is a shame!!! bummer :pain:. Using lua predicates, you could still use the normal DCS mechanism, and check using scripting some conditions on the fly within your mission. It would make mission scripting much more acessible for people like yourself who are starting up. We have escalated this to ED a few times now, but they haven't fixed this since 2 years. In short, if you wanna have a good intro about how to embed your scripts into your missions, maybe have a look at this video, that explains a bit this process: fIp2VdvRXQw FC

SCORING works like this also. And the accounting for the deads in the FSM works like this too. Is this for scoring deads? Because that has already been written... SCORING class ... FC

Let me explain... 40 fps with an NVIDIA GTX1070? No man, that should not be. I have a high feeling your NVIDIA is disabled! Also, 1 - 2 second stutter, that is possible, but only when it is loading from the HDD, not from an SSD. And only in the beginning. Try to set the preloading radius to maximum. that will load all, and will reduce the stuttering as a consequence of scenery loaded from the disk. Sven

That is bad. Is this in DCS 1.5.7?

Is you NVIDIA activated?

Thank you! That is great to read! It is a bit invisible how many people are using this framework, so thanks for the appreciation to the team. This framework is an ongoing target, the more people use it, the better it will get, and less bugs will appear over time. The more people are contributing and helping others, the more time the developers have with extending the framework with new modules. Thanks

Guys, I had the same... in 2.1... But, i had statics at the airbase. Once i removed the statics from the mission, I had no crash anymore! Can you or Tracerfacer try this?

Are you having statics in your mission?

lua predicates would be really an asset if it would work. I agree!

Hi, Within DCS, the design of the API to control the radio menus in the sim could have been better. However, what you want to achieve is possible. When DCS sets a radio menu for all players or for a coalition, then all players or all players of the coalition will see the menu command. However, once a player selects a menu command, the system does not provide the unit that pressed the menu command, which is a severe flaw in the design of the menu system. Fortunately, there is a way, but it does not cover what you wanna achieve. The first point is that within the DCS scripting engine and DCS design, all menu handling and all communication (like messages, sounds) can be done for all players, all players in a coalition or to specific groups. It is the latter that is the most interesting, however, again, communication is to groups, so not to individual units in a group. This may seem like a limitation, but in fact it is not. There are two aspects to know: 1. There is an open error still within the DCS system, that prevents DCS to handle groups within the scripting engine that can have 2 or more players in it (so 2 or more clients). As a result, most groups within the current missions will only have 1 player (client). The method Unit:getGroup() will return nil if there are 2 clients or more in the system. 2. There is an open bug in the sim to handle the event S_EVENT_PLAYER_ENTER_UNIT, which is important to detect which players are entering which units. Right now, in multi player, this event is only fired for planes and helicopters on the server, not for ground units and maybe later ships. With these two points in our mind, there is a way to handle menus to specific groups, and make groups receive the selected menu items. MOOSE uses this all the time, it allows to define which groups can have which menu item, and to know which group (player in group) has selected which menu item. It is the only way that I know of that works. The class to set specific menu commands to specific groups in MOOSE is: MENU_GROUP_COMMAND:New( PlayerGroup, MenuText, MenuPath, MenuFunction, ... ) There is also a core API within DCS that does the same, but the MOOSE class using this API has made the following improvements: It prevents menus to be set twice or more times (upon sequent calls). In other words, menus set with the same menu text, will be updated or changed, and not added every time in the menu system. In this way it is possible to update the MenuFunction and parameters of a menu item. Notice the ... , which allows for a variable amount of parameters to be given. In the core API of DCS, one parameter is only possible, which results in having to use tables etc, but I feel this is too much low level for that is needed. MOOSE hides this complexity for you. The class has methods that allow to "refresh" menus based on a batch of updates. I won't get into details here, but basically the methods allow to set a timestamp and tags on each menu item. A logic can update the relevant menu items using the new timestamp and relevant tags. And later in one command any menu item that has not received the new timestamp with the related tag, will be removed... So this allows for efficient refreshing of menus. A concrete example of how a menu for a specific group can be set is as follows: PlayerGroup = GROUP:FindByName( "PlayerGroup" ) MENU_GROUP_COMMAND:New( PlayerGroup, "Call in air support MI-28", MenuRoot, CallInAirSupport, PlayerGroup, "MI-28" ) MENU_GROUP_COMMAND:New( PlayerGroup, "Call in air support KA-50", MenuRoot, CallInAirSupport, PlayerGroup, "KA-50" ) .... function CallInAirSupport( PlayerGroup, HelicopterType ) MESSAGE:NewType( "Calling in Air Support " .. HelicopterType, MESSAGE.Type.Information ):ToGroup( PlayerGroup ) if HelicopterType == "MI-28" then ... elseif HelicopterType == "KA-50" then ... end end The example outlines that when a player in the PlayerGroup selects one of the two menu items, the function CallInAirSupport shall be called. A message is sent to the player, and specific actions are executed depending on the HelicopterType... When setting the group menu, notice in the New method the two variable parameters PlayerGroup, "MI-28" or "KA-50" to be set, which are received by the function. So, to answer your question, it is possible, but this method also has important drawbacks: The mission designer needs to set for each group that can have specific menu commands for the group, a group menu command. If this is not carefully managed, this may result quickly in a performance drop. Updating and maintaining different menu items for each group is complex. Especially in case for different contexts (like different missions, tasks etc). That is why the S_EVENT_PLAYER_ENTER_UNIT is so important, as this will prevent the mission designer to execute excessive loops within the system setting for each possible group a menu command... Instead, if this event would be fired consistently, it would be possible to catch the event, and set the menu command for the group of the unit for which the event was fired and done. The DCS simulator could really be enriched with two addons that would really ease the simulation experience: Add a 4th type of API that allows to set menus for a series of Group objects. Provide a means to pass the group object that has selected the menu command, in case of menus for all players and/or all coalitions. This would ease the complexity of menu management a lot for specific groups, and would provide a more user friendly interface for mission designers. I hope this helps, Sven

table coalition.getStaticObjects(enum coalitionId ) Hello Grimes and @ED, This method does not return Cargo static objects. Known issue? Is there a workaround known? FC

I am in ...

Release 2.3 - Alpha for Early Adopters MOOSE Release 2.3 alpha - (EARLY ADOPTERS VERSION) FlightControl-Master released this 2 days ago · 21 commits to Release-2.3-alpha since this release For those who want to use the latest of the latest, use the following Moose.lua files... Note that this version of MOOSE contain prototype methods, and are bound to change. However, when methods are changed, I will communicate that, so you can adapt your missions. I will try to keep the changes to the minimum. All the available MOOSE classes come delivered in one Moose.lua file. There are two versions of this file that are functional (work), but with different file sizes: Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc. Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance. To use, include the Moose.lua in your .miz file using a DO SCRIPT Trigger. Mission Designers need to read here for a detailed usage description. Consult the MOOSE documentation for further details on the framework. List of changes: Added GOAL, ZONE_GOAL, ZONE_GOAL_COALITION, ZONE_CAPTURE_COALITION classes to model capturing of Zones by a Coalition. Added on the ZONE class an improved search method to search for SCENERY in a ZONE. Added also methods ZONE:GetScannedScenery() and ZONE:GetScannedSceneryType() methods to inspect which Scenery has been found after a Zone:Scan()... Added USERFLAG class to manage user flags Added USERSOUND class to manage sounds Added SET_BASE:GetSetNames() to return an array of the object names of a Set. (Created dynamic lists based on mission editor groups defined). Added SET_BASE:GetSetObjects() Revised the message naming. Optimized the code for GetScannedCoalition Markings text optimized for ZONE_CAPTURE_COALITION. Now the owning coalition is also shown.

Release 2.2 - Patch 3 Release 2.2 - Patch 3 (LATEST VERSION) FlightControl-Master released this just now This patch brings a change on the SCORING class: Fixed error in AI_A2A_PATROL due to a stupid error that sneaked into the logic due to a variable rename. Fixed now! (sorry). This problem stopped AI_A2A_DISPATCHER patrolling. All the available MOOSE classes come delivered in one Moose.lua file. There are two versions of this file that are functional (work), but with different file sizes: Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc. Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance. To use, include the Moose.lua in your .miz file using a DO SCRIPT Trigger. Mission Designers need to read here for a detailed usage description. Consult the MOOSE documentation for further details on the framework.

Release 2.2 - Patch 2 Release 2.2 - Patch 2 (LATEST VERSION) FlightControl-Master released this a minute ago This patch brings a change on the SCORING class: Disabled the logic of Fratricide until a DCS bug gets fixed by ED. There is no workaround possible. Units containing a player cannot be destroyed using Unit:destroy() API in multi player when the player is seated in a Unit from a Client connected PC to the Server. By default, hit messages are disabled. They can be enabled by using SCORING:SetMessagesHit(). All the available MOOSE classes come delivered in one Moose.lua file. There are two versions of this file that are functional (work), but with different file sizes: Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc. Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance. To use, include the Moose.lua in your .miz file using a DO SCRIPT Trigger. Mission Designers need to read here for a detailed usage description. Consult the MOOSE documentation for further details on the framework.

Can write a ticket here on GITHUB explaining the requirement? https://github.com/FlightControl-Master/MOOSE/issues Those labelled with a blue "enhancement" are feature requests... This is for my memory, which is being put regularly at test ...