FlightControl

Hi Bignewy, Bitdefender is fine. Dcs runs fine with Bitdefender these days. But ut didn't used to be like that, true... I remember very well

Mmmm... I'll check here also.. Tomorrow. Maybe double check your system with Bitdefender.

Nobody?

Bug is known and has been reported. Hopefully it will be fixed soon.

With some vector calculations it should also be possible to determine a % probability hit... Found the maths to do that, but time....

Maybe this is also a source of inspiration. Approach zones through coding...

Have a look at these test missions. Maybe this is a source for inspiration... https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Test%20Missions/ZON%20-%20Zones

Million $ question, which av do you use?

May I ask you, does the code crash, or does it do the job, but menus are not showing?

Suggest you use the guidelines in this post to revert to an earlier version of DCS until this bug is resolved. https://forums.eagle.ru/showthread.php?t=114030 I mean, spitfire is nice, but if you aren't using the new module, or are not really awaiting any added fixes, then this revert process can help. There is always a choice. DCS_updater.exe update 1.5.5.59992@release FC

Please take your time to consider the underlying written. "I wonder whether the community can be more proactively and interactively involved in the testing of new releases of DCS World by ED." The simulator is an enormously complex program, and I can imagine that in order to test for a new release, the ED development team, ED testers are facing enormous challenges to ensure that the product stays bug-free and that defects are properly reported and followed-up. What we're noticing within the community is that there are people who have become very acquainted with the simulator in its mission design aspects and mission editing aspects: - Designing missions using the DCS world scripting API. - Making highly complex scripts. - Having a large set of "mods" made within the product. The amount of users and scripts and missions have grown exponentially, and thus, the challenge for ED to release a bug-free product has grown, and the complexity to keep backward compatibility has also grown also. It has become very hard for ED to test everything keeping this large community happy. The challenges for ED are in the following areas: - Ensure that the promised functionality gets delivered within the expected deadlines. - New modules are integrated in relation with the partners. - Partner modules can have bugs, and fixes are required. - Changes in the DCS world core engine may sometimes mean a large rework, with a high risk for bugs. eg. the planned merged product (version 2.5), is a huge challenge for ED today. - the DCS world lua scripting engine is used within many missions, bugs appear frequently. Backward compatibility is key, and the functions need to work consistently. - the mission editor needs to keep up with the changes... and keep backward compability with previous designed missions. - cope with unexpected crashes during run-time, due to memory errors or other internal bugs in the C++ code... What we've noticed in previous releases is that bugs appear, and are staying within the system for a couple of months, if not years. Some bugs however, get quickly fixed, while others are awaiting to get fixed for a (very) long time... And unfortunately, some of these bugs were only detected after "beta testing", in the already release product... And i see a couple of reasons of that: 1. Beta releases are appearing very shortly after each other. The community has a hard time to follow-up... 2. Core changes are done in the product, but are not communicated to some community people who maintain complex scripts... 3. I really wonder how closely the broader community is involved today in bug fix prioritization and bug fixing. (So Beta testers are also community, but i mean here the broader community ...) Therefore, i have a couple of suggestions to help ED to make this better: 1. Would it make sense to involve some people of the community in "pre-release" testing? Especially major releases should be tested properly. Or another solution could be, the BETA stays longer alive, until all urgent defects have been reported and resolved ... 2. Would it make sense to establish a communication channel for testing and test results? A proper logging of bug fixes and follow-up? I don't think the ED forum is a good platform to do that. I think something else is needed. Hope these points make sense ...

Hi everyone, It is been quite a ride, rather bumpy in fact ... But here it is, the next release of the MOOSE framework for DCS World is a fact. This release is adding the following functionality to MOOSE, on top of the pre-release version: Task orchestration: CommandCenters, Missions, Tasks, Task Actions ... AI balancing and AI bahaviour. AIBalancer, Patrol Zones, ... Cargo handling: Board, Unboard, Transfer cargo of different types. Dynamic detection and task assignment through FACs. Additional functions in existing classes. Preparing this release was a large work ... I hope you like using it. There are various test missions created to demonstrate the framework. It is worth to have a close look to the lua files for each test mission. You can find in each directory to lua file that is embedded in the test mission that explains the script. The documentation of these test missions is not yet up-to-date, but that will improve next year. On top, I plan to create training videos for you to demonstrate the capabilities of the introduced new concepts. These things take time and a good preparation, so pls be patient. API Changes! The good and bad news is that there are a couple of API changes that I had to push through. The reason why these API changes appear in the release is, I made some bad design decisions in the past, and I've made the interface more consistent. I would like you to review and update your missions to adapt and incorporate these API changes. Implementing these API changes can be quickly done I believe ... The changes are minor. In a nuttshell: - I changed the name of the SPAWN initialization functions, adding Init to the name. I wanted to make sure that the difference between Initialization and Spawning in the SPAWN methods were clear, because many people had questions and were confused! Please refer to the SPA-1xx for a demonstration on these new Init functions (they are the same, only the name changed). - Spawning of new units can be done now from a Unit location, a Static location, a PointVec2 location, a PointVec3 location and a Zone location. In order to make the interface consistent over all these functions, I added a new function called InitRandomizeUnits( RandomizeUnits, OuterRadius, InnerRadius ) and added, revised the APIs of the Spawning functions. Please refer to the test missions SPA-3xx for demo scripts to use these functions. - Zones can now also be randomized during Spawning using the method InitRandomizeZones( SpawnZones ). Please refer to the test mission SPA-220 for a demonstration to use this function. Here are the changes: BASE DCS Event handling functions have been added to the base class. These functions start with the OnEvent... prefix. These functions now allow you to DCS events in a class like when a birth of a unit happens, or when a crash happens etc. [*]SPAWN OnSpawnGroup( SpawnCallBackFunction, ... ) replaces SpawnFunction( SpawnCallBackFunction, ... ) SpawnInZone( Zone, RandomizeGroup, SpawnIndex ) replaces SpawnInZone( Zone, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex ) SpawnFromVec3( Vec3, SpawnIndex ) replaces SpawnFromVec3( Vec3, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex ) SpawnFromVec2( Vec2, SpawnIndex ) replaces SpawnFromVec2( Vec2, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex ) SpawnFromUnit( SpawnUnit, SpawnIndex ) replaces SpawnFromUnit( SpawnUnit, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex ) SpawnFromStatic( SpawnUnit, SpawnIndex ) replaces SpawnFromStatic( SpawnStatic, RandomizeUnits, OuterRadius, InnerRadius, SpawnIndex ) InitRandomizeUnits( RandomizeUnits, OuterRadius, InnerRadius ) added. InitLimit( SpawnMaxUnitsAlive, SpawnMaxGroups ) replaces Limit( SpawnMaxUnitsAlive, SpawnMaxGroups ) InitArray( SpawnAngle, SpawnWidth, SpawnDeltaX, SpawnDeltaY ) replaces Array( SpawnAngle, SpawnWidth, SpawnDeltaX, SpawnDeltaY ) InitRandomizeRoute( SpawnStartPoint, SpawnEndPoint, SpawnRadius, SpawnHeight ) replaces RandomizeRoute( SpawnStartPoint, SpawnEndPoint, SpawnRadius, SpawnHeight ) InitRandomizeTemplate( SpawnTemplatePrefixTable ) replaces RandomizeTemplate( SpawnTemplatePrefixTable ) InitUnControlled() replaces UnControlled() InitCleanUp( SpawnCleanUpInterval ) replaces CleanUp( SpawnCleanUpInterval ) InitRandomizeZones( SpawnZones ) added [*]AIBALANCER Has been completely reworked. I don't think anybody has been using this class beside hijack. [*]PATROLZONE: Has been completely reworked. I don't think anybody has been using this class beside hijack. [*]POINT_VEC3 and references in other classes methods to POINT_VEC3 objects: Translate( Distance, Angle )added. Replaced methods ending with Point_Vec3() to Vec3() where the code manages a Vec3. Replaced all references to the method. Replaced method Point_Vec2() to Vec2() where the code manages a Vec2. Replaced all references to the method. Replaced method Random_Point_Vec3() to RandomVec3() where the code manages a Vec3. Replaced all references to the method. [*]SCHEDULER has been reworked, see below. What's new! Find below a comprehensive summary of the MOOSE new features in this release: 1. Task Orchestration 1.1. Comand Centers COMMANDCENTER: Governs the communication and existence of Missions, Tasks and Actions for a Coalition. Create a new CommandCenter. Multiple CommandCenters can be defined within one Mission. Maintain Missions. Add, Remove and CleanUp Missions, and undelying Tasks and Actions. Provide a navigation menu to orchestrate for different groups the Tasking. Send Reports to players of the Tasks within all Missions of a CommandCenter. Send Messages to all players alive within all Missions of a CommandCenter. 1.2. Missions MISSION: Governs the process flow of the Mission, Tasks and Actions for a CommandCenter for a Coalition. Create a new Mission for a CommandCenter. Provide Mission status flow, implemented through a Finite State Machine. Expose Mission event- and state functions to influence the Mission orchestration. Maintain Tasks: Add, Remove and CleanUp Tasks and underlying Actions. Send Reports to players of the Tasks within the Mission. Send Messages to all players within the Mission. Attach a Scoring and event log implemented through the SCORING class. 1.3. Tasks TASK: Governs the process flow of the Task state and the execution of the Taskprocess and hierarchical processes by players. Create a new Task for a Mission governed by a CommandCenter. Provide Task status flow, implemented through a Finite State Machine. Expose Task event- and state functions to influence the Task orchestration. Create a Task Actions, implemented through a Finite State Machine Process, that the players will need to follow when the Task is Assigned to a Player (Unit). Maintain Tasks: Add, Remove and CleanUp Task Actions and hierarchical Actions. Expose Mission event- and state functions to influence the Task state. - Flag a Task as Planned. - Flag a Task as Assigned. - Flag a Task as Successful. - Flag a Task as Failed. - Flag a Task as Aborted. - Flag a Task as Cancelled. Send Reports of the Task to the players. Send Messages to the player executing and assigned to the Task. Create a Task Action workbook. Provide a mechanism to assign players to the Task. Provide a mechanism to abort players from the Task. Each assigned player to the Task, will have a Task Action flow executing, governed by the TASK object. Provide a mechanism to attach a Scoring scheme when certain states are reached in the Task and in the Task Action flow. 1.4. Task Actions ACT_ASSIGN, ACT_ROUTE, ACT_ACCOUNT, ACT_SMOKE: Governs Task Action Subroutines that can be embedded within a Task Action flow. These ACT_ classes will be further enhanced and expanded now the baseline of MOOSE is there. This will result in mission designed being able to quickly combine these actions to implement different Task flows. Create a new Task Action Subroutine for a Task Action flow, governed by a Task. ACT_ASSIGN: Base class to assign a player to a Task. If the player is in a Group that is already assigned to the Task, the Player will be assigned automatically. ACT_ASSIGN_ACCEPT: Assign a player to a Task, and automatically Accept the Task. ACT_ASSIGN_MENU_ACCEPT: Assign a player to a Task, and let the Player Accept or Reject the Task within 30 seconds. ACT_ROUTE: Base class to route a player. ACT_ROUTE_ZONE: Route a player to a zone. ACT_ACCOUNT: Base class to "account" events or things within a running mission. ACT_ACCOUNT_DEADS: Account if certain DCS Units are dead. ACT_ASSIST: Base class to assist players with certain actions through the menu. ACT_ASSIST_SMOKE: Assist players with smoking target areas while in flight through the menu. ACT_...: Expect in the future more ACT classes to be created and added to the MOOSE framework. It is upon our creativity to identify good functions to be added. 2. Finite State Machines FSM, FSM_CONTROLLABLE, FSM_ACTION, FSM_TASK, FSM_SET: Finite State Machine base classes that implement the necessary functionality to realise a workflow following various state transitions triggered through events being fired externally or internally within the FSM implementation. FSM: The Finitite State Machine base class. It provides functions to create a fsm workflow, adding state transitions schemes and adding sub processes. FSM_CONTROLLABLE: An fsm governing the workflow for a Controllable object within DCS, which can be a UNIT or a GROUP. FSM_PROCESS: An fsm governing a workflow for a Controllable object within DCS for a Task. Note that all ACT_... classes are derived classes from FSM_PROCESS, implementing an fsm to govern the Player unit for the Task given. FSM_TASK: An fsm governing a workflow for a Task. Note that the TASK class is derived from FSM_TASK. FSM_SET: An fsm governing a workflow for a Set. 3. Balance and Control AI AI_BALANCER: Balances AI within a Mission. It is up to the mission designer to capture the different AIBalancer events, and attach different AI processes to accomodate AI behaviour. Spawn new AI as there aren't players in the Mission. In other words, spawn as many AI required to simulate player behaviour. Attach various AI processes to let the AI execute certain tasks. Implements an fsm to accomodate a workflow to let the mission designer attach various AI workflows for AI implementation behaviour. PATROLZONE: AI_PATROLZONE: Is an AI behaviour class, governing AI to patrol a zone, used by the AI balancer. Provide an fsm process, implementing AI patrol behaviour so that AI is patrolling a zone for a defined time. Expose various event functions to influence the AI patrol behaviour. The PATROLZONE class can be used in AIBALANCER to simulate players. 4. Cargo Handling AI_CARGO: Cargo Handling of CONTROLLABLE object, thus UNITs and GROUPs. CARGO provides a dynamic way to Load, Unload, Board, UnBoard and Transfer Cargo between Carriers. The cargo handling of units is animated, that means, you'll see the units moving towards or from the carriers ... Board Cargo to a Carrier. Unboard Cargo from a Carrier to a point. Transfer Cargo from a Carrier to another Carrier. CARGO is the base class implementing the cargo workflow. CARGO_GROUP: Implements the Cargo handling for a GROUP. CARGO_UNIT: Implements the Cargo handling for one UNIT. CARGO_GROUPED: Implements the Cargo handling for multiple GROUPs. CARGO_PACKAGE: Under construction. This would simulate a package being carried by a carrier. Note: There are various Task Actions (ACT_) classes planned that would allow to deploy and pickup cargo in a battle field. Note: There are various AI_ classes planned that would allow to deploy and pickup cargo in a battlefield.[/td] 5. Scheduling SCHEDULER: The scheduling of methods has been intensively reworked. In the previous version of MOOSE, each SCHEDULER object controlled the scheduling of the method provided. However, with the new SCHEDULER implementation, the actually scheduling is now done by a SCHEDULEDISPATCHER class, which has one instance within the MOOSE framework, under _SCHEDULEDISPATCHER... SCHEDULER has some minor changes to the API. One of them is that SCHEDULER now allows to schedule more than one repeated schedule. When the method SCHEDULE.Schedule() is called, a ScheduleID is returned. This ScheduleID can then be used to Stop or (Re-)Start the schedule using the SCHEDULER object and the ScheduleID. The actual object controlling all the schedules is _SCHEDULEDISPATCHER. Other comments ... There are many more changes done within the framework, but these are very technical and hidden from the API set that the users will use. Some of the work that was done includes: rework scheduling, adding a scheduler dispatcher. There is still some work to be done on the TASK_DISPATCHER, but that will be done the coming weeks, so don't spend too much time on that for the moment ... Also, this release builds the foundation of many many other classes to come. Now that we have state machines and the object model is now more or less stable, other functions can be built upon this framework. It would be great that a community would see the benefits of this development and endorse it, like many have already done. The documentation is not completely up-to-date, but that will come and flatten out the next weeks. Also, demonstration videos will be published on my youtube channel next year to demo some of the new functions, and I'll rework a few of the older versions. If you have problems using this release and somehow feel blocked, you can use the previous commit on the master branch. Just click in GITHUB on the previous commit, sync and you'll be fine. I hope you will have the same pleasure using this framework as the creators had making it. Thanks all; FC

Grimes, Today I could test in MP the client bug too... It is indeed not resolved completely. It works as you indicated only when the group has only one client. When there are more clients in the group, the DCS Unit:getGroup() API fails and returns nil. So the fix is indeed half done. You did a great job testing this too and thanks for sending this fix back to the ED team for further fixing. So I was today half excited and half dissapointed :-) For the new upcoming tasking framework to work completely, it is required that this bug gets fixed. And I guess for many many scripts at DCS too. So the current temporary workaround is to design only missions with one client per group... Fortunately within the upcoming new release of MOOSE, you have the capability to "group" multiple groups into a set, that is given as a parameter to the tasking. So, in other words, MOOSe can simulate a logical "group" within a HQ->Mission->Tasking perfectly... A good test actually to see how that scenario works ... Sven

Interesting article on the su -25. http://www.popularmechanics.com/military/aviation/a24303/russia-sukhoi-su-25-a-10/

How can one send a message to the spectators in a multi player mission? This would be good for statistics and mission update information etc. I know message to all works for spectators, but then ALL players are seeing this. Sven

Yup. This is an idea, but how to realize it properly is another question. It should be designed in such a way that it is transparent and if ED adds or deletes unit types to the DCS product, that it does not require modifications in the MOOSE framework... I think a function or two would not hurt making new groups, but then again, ... need to assess the impact on the code for such design. For the moment we can put it on the todo list in github. Right now the framework is tackling some other ideas and problems with higher urgency. Want to get that release out first ... Thanks for the feedback. kind regards, FC

No, you need to create templates. What's your thinking? Why this question?

Okay, will fix that and it will be populated with the next release. Maybe as a feedback let the community know how you experience the tracing functions usage. Fc

The API is BASE:TraceOnOff( true ) You can "level the output", by using the API: BASE:TraceLevel( value )Value is a number from 1 to 3. You can trace one class: BASE:TraceClass( "CLASSNAME" )for example BASE:TraceClass( "GROUP" ) All GROUP objects will be traced ... You can use objects derived from the BASE class to trace also: local GroupObject = GROUP:FindByName( "object" ) GroupObject:T( "Text" )The functions E, T, T1, T2, F, F1, F2 take a table as a parameter... Thus you can write: GroupObject:T( { "Text" } )This will provide the output as: [1]="me"Or, you can do as follows GroupObject:T( { Text = "Text" } )Provides the output: [Text]="Text"You can provide a structure to the trace functions... GroupObject:T( GroupObject )This will trace the complete GroupObject field values ... The key to success is trying it out ... The tracing will put light into darkness ... There are MANY examples in the MOOSE code base. Refer to this post for more explanation: https://forums.eagle.ru/showpost.php?p=2961579&postcount=245 FC

Try to press F5 in the GIT Desktop. This key press is undocumented, but refreshes the branch structure in your GIT Desktop. Then Sync. The AI Balancer is updated, but there are still some issues with it. Fixing those this week. Have a look at the Patrolling test mission, which you can find in the test missions section. FC

Hello all, A small note regarding the current status of the MOOSE framework. :detective: MOOSE has always been in "pre-release state". But slowly it is getting to a point where it is ready to be released as a comprehensive package for mission builders to work with. Therefore, I've been preparing a pre-release branch on GIT-HUB. https://github.com/FlightControl-Master/MOOSE/tree/MOOSE-RELEASE-2 Those who would like to have a peek look into the new release, can use this branch for pre release mission building, taking into account that there will be bugs and things may change further. Planning to get this release out by the end of December, beginning of January. This release of MOOSE will add some interesting additional new features: - Mission Orchestration: :pilotfly:Per coalition, one can setup multiple logical Missions, which contain multiple Tasks to be achieved by a Group of players. Once Players join the Group, the latest pendingTask needs or is accepted automatically, and the Task goals are followed. Upon achievement of the Task, a Scoring is granted. These Missions are governed by CommandCenters, which are any Identifiable objects within your mission. The CommandCenters take care of communication between the Groups of players, and coordinate Task status, Mission status etc. - Cargo Handling: :juggle:Cargo is being handled through Finite State Machine orchestration. There are different Cargo types: Units, Groups, Packages, ... - AI Balancing: :drunk:Balancing the AI is a defined quality in any good mission design. The AI Balancing capability within MOOSE allows you to balance AI based on Player joining events. AI Balancing is actually a Finite State Machine mechanism, that will trigger or destroy/manage AI being dynamically spawned within your mission based on player activity. The AI will receive Tasking to complete, and many different processes can be developed within the MOOSE framework to balance the AI and add its behaviour. - As mentioned above, the major achievement of this release is the implementation of several Finite State Machine :pain: classes, which orchestrate long-lasting processes within your mission, without much CPU overhead and provides a clear, understandable method to transition between states within the process based on events that are being fired both internally in the process and externall from the process. Also, the Finite State Machines support sub processes, that support the re-use of pre-defined state machines as a long lasting process with possible end-states as a result. Note that MOOSE is a framework, meaning :sleep:, it provides a mechanism to develop functionality. The current release will contain some functionality required or wanted by the community, but it is the idea that others will use MOOSE to extend the functionality in the future. Now, I am further preparing this release to get it deployed for others to use and get excited about :music_whistling: cheers, FC

cool. the are a couple of things that need to be changed in the code. I'll explain tomorrow about documentation, naming conventions...

This bug happened before... When new units were spawned, they started moving... That bug got solved earlier, but if this is again happening, ED may want to have a close look at this again. Sven

I think you misunderstood. It worked in Mutiplayer before 1.2.14. Units were dead, smoking ... When you deleted the group, the dead, smoking units dissapeared. But only on the CLIENTs in MP. Because on the server and in single player mode, the units remained visible, dead and smoking. Now, after 1.2.14, this does not happen. The best that CLEANUP can do right now, is once a unit gets hit and is within the airbase perimeter, it starts to "monitor" the unit. Once the unit is below x meters and damaged, it dissapears. Once that unit has damage larger than x%, it dissapears. But that has consequences and disadvantages: 1. High CPU load on the server. 2. Units that are dead immediately can't be tracked. 3. What about units flying under x meters, damaged, but still flying? 4. There are still units that can crash and become dead, because the monitoring is done with a timer event. Sometimes the timer does not fire in the required intervals, due to high server load or long processing. So, for 3 years this has had no track or follow-up. FC

But again, this used to work till DCS 1.2.14. If you destroyed a group right after the unit fired an EVENT_DEAD, it used to be able to remove both the group and alive and dead units ... It doesn't do that anymore ... That was the catch of the CLEANUP class. I catched the EVENT_DEAD stuff, and cleaned up the groups who were "dead". Sven