FlightControl

@ED and @DCS team, Markings are a nice addon functionality for DCS, although it also leans towards "cheating". But for briefing purposes this is excellent! Markings allow to be placed on the map by players or using scripting during mission execution as text boxes, providing tactical instructions or reference points, in free text format. The functionality also comes with 4 new APIs in DCS: - trigger.action.markToAll() - trigger.action.markToCoalition() - trigger.action.markToGroup() - trigger.action.removeMark() I've been testing this functionality and been trying to embed it into the MOOSE framework, and our team has a couple of comments about the workings of markings... 1. There is a bug with markings. Markings placed for specific groups (using trigger.markToGroup()) does not seem to work with CA units. Find the attached mission as a demonstration, running the following code: Plane = Group.getByName( "PLANE" ) if Plane and Plane:isExist() then local Vec3 = Plane:getUnit(1):getPosition().p local GroupID = Plane:getID() trigger.action.markToGroup( 1, "Plane Marking", Vec3, GroupID ) end Tank = Group.getByName( "TANK" ) if Tank and Tank:isExist() then local Vec3 = Tank:getUnit(1):getPosition().p local GroupID = Tank:getID() trigger.action.markToGroup( 1, "Tank Marking", Vec3, GroupID ) end The mission shows 2 units. To resimulate: Run the mission. Jump into the plane, and press F10. Wait 10 seconds and watch the mark appear on the plane. => OK! Run the mission (again). Jump into the tank, and press F10. Wait 10 seconds and watch no mark appear on the tank => NOT OK!!! 2. Messages generated when a mark is placed, not good. When a mark is placed by a user or using one of the APIs, a text is displayed "Mark added" within a running mission. While this is nice to have, it is quite not useful and it is disturbing. We wonder why that message appears and if it can't be disabled or removed overall. Even more, when you generate a mark to a specific Group, using markToGroup(), each player will still receive that mark message... Imagine a logic where 20 players are informed of a mark add, imagine if 5 marks are added for 20 players, that is 100 messages sent... 3. When a player in a running mission deletes a mark on the map, nobody knows about it. Is there an event generated that warns of this? Could such an S_EVENT_ be added in the scripting engine? 4. Is it possible to add APIs that allow to "enquire" the markings: An API that iterates through the markings set for All, Coalition or Group (based on choice of the mission designer), or, an API that retrieves all markings active in the mission? eg. trigger.action.getAllMarkingsForCoalition(coalition) An API that allows to enquire a specific marking status (like retrieve text, and if it is still displayed etc). eg. trigger.action.getMarking(id) Please consider the issue reported and the additional features if possible. I assume the time is still okay for this request, as the functionality is still under development at ED. kind regards, FC BUG-008 - Markings.miz BUG-008 - Markings.lua

Some more important fixes done today and published on the release 2.2.0.pre page of the MOOSE framework. Please download the latest moose.lua. Fixes include: AI_A2A_DISPATCHER: Corrected the calculation to the distance to the airbase, when the intercept calculation is used. Now the intercept point is not anymore interfering with the gci radius validation and gci radius is now correctly respected and validated. AI_A2A_CAP and AI_A2A_GCI: Player disconnecting will not result in coordinate calculation problems while engaged with the player machine. The engagement will stop. DESIGNATE: Unless autolase is activated, lase will stop after 60 seconds by the JTAC. Fixed CAP not engaging issue when there was more than one CAP squadron defined. A stupid typo in the logic overwrote the friendlies prefixes of the first squadron when a second squadron was defined. Stability fixes for AI_A2A_DISPATCHER in multi player. Players can exit units due to unexpected disconnects... Squadron and Default overhead is now correctly interpreted in GCI engagements. 1 is the neutral number for the Overhead parameter. Any fractional number larger than 1 will calculate additional overhead of defenses. Any fractional number smaller than 1 will calculate less overhead of defenses. Note that overhead is calculated in terms of GCI, not in terms of calculating the engagement of CAP and returning GCI aircraft! Thanks for the bug alerts and the great support in testing and helping to fix them! Enjoy your weekend and happy flying. FC

Thank you Grimes!!! Great to get this feedback. Maybe change the title also to [REPORTED]. So the community knows too. Thanks again.

I think you misunderstood :-) I meant to have Air to Ground, so AI air units attacking ground targets. This to bring the immersion to the players and to allow for AI attack assistance. There are many aspect that are different from AI A2G dispatching in comparison to AI A2A dispatching, is that the definition of threat is different and the AI engagement results in different tactics and patterns to be applied. So, the tactics needs to be defined in terms of: - Zones: If ground units reach certain areas, then engage. - Time: If certain detected ground forces aren't engaged for a period of time by human playes, engage with AI. - Threat level: only engage till a certain threat level. - Assisted attacks. AI assists attacks by players, through menus. In your case, having ground forces doing something like an A2A dispatcher, requires a who new approach, because there you have the terrain that plays a role. That is going to be the G2G dispatcher, which is planned later.

Planned in release 2.3 and a long time ago promised to Gunterlund. This module is a long due request. I plan to start with release 2.3 very soon., and it will be focused on expanding the CARGO and other functions like A2G and MEDIVAC.

I was the one who messed up :doh:, not you. I should have checked this a long time ago. Hope you enjoy the demos and code examples. You know where to find us in case of questions.

Could you resimulate it Grimes? What's your take in this?

No server tonight or in the future, and no joint test missions unless you have explicit requests or see advantages to do such. I Suggest you run your own. We can clarify offline in the MOOSE thread answering questions or discuss requirements. Issues or requirements should be logged in the github issues list, so we keep track. Please try to log ONE issue per issue. So keep a one to one mapping to avoid expanding discussions and confusion. I know it was great to run our tests together, but my time has also become more limited now and i wanna use my available time more efficiently. Please follow the guidelines as explained below. I know a lot of people in this community are still in sunny cloud kuku land what this is all about, but that will come more understood once we start this process and start logging the issues and discussing them. Lets help each other. FC

Hi guys, great to reach out of help. As you know, a lot of work has been put in the tasking on the MOOSE framework overall. It has become a great module and quite a lot of people have been using it not only in multi player missions but also in single player missions. I also got a lot of recommendations and feedback on the overall mechanism and menu system, from an end-user perspective. Fantastic. If you would like to help with testing and provide structured feedback, I can only recommand and encourage you do so. It is a challenge to get people all over the world engaged on a joint conf call. I've tried many times but it is a bit hard ... Please feel free to build a test mission, and run this mission with your team or squad mates or just run it in single player. Any question or defect or suggestion, please try to do the following: 1.Try to resimulate or quickly log it as you see the problem. 2. Quickly take a screenshot if applicable that demonstrates or illustrates the problem (just do Ptr-Scr) in the mission and DCS will save the screenshot in the ScreenShots folder under the DCS folder in your user directory in windows. 3. Create a new github issue in the MOOSE GITHUB site. 4. In the issue ticket that you are writing, you can easily drag and drop the taken screenshots into the ticket explanation. So you can add text and pictures easily. Pictures get automatically uploaded into github if you drag/drop or cut/paste into the ticket text. I have then a joint trace of the problem and we can discuss a resolution or requirements and come to a joint conclusion. If you have questions and wanna discuss, please discuss on the MOOSE thread. I think this is the best way to approach things and thanks for the help in advance!!! FC

In various forms... As a vector: POSITIONABLE:GetVelocity() In Kilometer per Hour POSITIONABLE:GetVelocityKMH() In Meters per Second POSITIONABLE:GetVelocityMPS() Note that GROUP and UNIT have the following inheritance hierarchy in MOOSE: GROUP: OBJECT -> IDENTIFIABLE -> POSITIONABLE -> CONTROLLABLE -> GROUP UNIT: GROUP: OBJECT -> IDENTIFIABLE -> POSITIONABLE -> CONTROLLABLE -> UNIT So any method defined in the parent classes is also available in GROUP and UNIT. So you can write: GroupObject = GROUP:FindByName( ... ) SpeedKMH = GroupObject:GetVelocityKMH() Hope this helps...

@Grimes after a more thorough investigation this problem has become more clear what the mission designer meant ... The problem regards to multi player. Hidden units do show up on the map view on client machine, although they are "hidden" when you check the map view on the server side. To resimulate: 1. Please run the attached mission on a server. 2. Connect with a client machine to the server. 3. On the client, select briefing (as spectator) and "fly". 4. Press F10, and you'll see a watch tower and a launcher. 5. Do the same on the server, and you'll see the luancher is hidden on the map view. Problem: On the client machine, the launcher should be hidden on the map. If you run this mission in Single Player, the launcher is also hidden. For completeness, I am also adding there the bug report on github: https://github.com/FlightControl-Master/MOOSE/issues/676 Feel free to chime in if you see it as useful. SPA-026 - Ground Ops - Spawn RandomizeTemplate Hidden.miz SPA-026 - Ground Ops - Spawn RandomizeTemplate Hidden.lua

@Grimes, The hidden flag is indeed working for spawned units, also in the MOOSE framework. This issue must be with multi player I think. I need to further validate with the mission designer what the exact error was that he experienced. I know that in multi player, hidden spawned units appear on the map (but don't remember the exact scenario). Sven

The errors you experienced were because of the wrong branch you were using. As a result of your message, I have reworked the branch structure of the MOOSE MISSIONS repository this afternoon. This should greatly make it more easy to try out test missions. The base branch of the MOOSE MISSIONS repository is called Release. This is the branch you will see by default when accessing the github repo. The missions in this release branch will all load MOOSE the normal way, that is a complete moose.lua file is integrated into each of these missions. So you shouldn't anymore experience errors like you had before. I've also updated the MOOSE MISSIONS release page of the MISSIONS repository so you can download all the latest missions in a zip file. Hope this helps! FC

Thanks for your response. To be honest, I am a bit puzzled about this. So, the issue is about spawning new groups eh, not respawning existing alive groups ( = teleporting ). I got a issue logged in our MOOSE community that new spawned groups are not "hidden", although the hidden flag is set on. MOOSE copies the exact group definition (of the ME) into the addGroup method.But the MOOSE logic is not touching the hidden flag at all. MOOSE touches the following flags: - lateActivation - visible (only for ground units) To be honest, I haven't really invested time myself in deepening the root cause of this issue, but will do now. I will come back later with either a confirmation that the issue was found in the MOOSE code or maybe that I need some help. Talk to you. FC

@Grimes, is this already reported to ED? When using coalition.addGroup(), it seems that new spawned groups are not hidden, although the "hidden" flag is set on. Do you have the same experience, (and others)? FC

Indeed. Let us clarify a bit further what the issue really is, and what the (possible) symptoms are, and the possible causes, because indeed there are different levels of understanding. The problem is binary, true or false. It works or it does not. The problems started to appear since the last patch upgrade from DCS 1.5.6 to DCS 1.5.7. Something has been added or changed, that causes a severe stutter in existing missions. 1. Let us take first the clarification in Single Player. Take a mission that runs smooth in DCS 1.5.6 with lots of AI activity. That means, AI that is activated, and preferably has radar capability. With smooth we mean, no stutter (or very limited that does not hinder the simulation experience). When you run this mission in DCS 1.5.7, you'll experience stutter. Actually the mission will be unplayable. Not all missions have lots of AI, so this appears only at specific missions. 2. Let us move now the clarification up to Multi Player. Multi Player missions that ran fine in DCS 1.5.6 will suddenly not perform at all in DCS 1.5.7. Again due to lot of AI Activity, and there must be (lots of) AI with radar capability. You have two components, client and sever. The server runs the mission, the client connects to the server and synchronizes the mission. The 'smoothness' experience however is something different here. The client is doing no mission processing. The client is simply taking the synchronized inputs from the server, that is running the mission, and render the received information in the simulation. Now if the server becomes CPU overloaded (= does not perform anymore), you'll see lag, but no "stutter" on the client. The symptoms you see is "lag", but this is very subjective, and really not a measurement to judge this issue at all. Measurements need to be done on the server, in terms of CPU load and "FPS" (on the server). FC

@Grimes, fantastic. Thank you for taking your time going through the report(s) and interpreting the results. I know plenty had been reported in the past. This is only the first batch of tests. More tests to come. I hope the table in post provides a good overview. https://forums.eagle.ru/showpost.php?p=3236467&postcount=12 For years we are suffering these things. A lot of these issues were reported but pulled to the back of the fix queue or it never got attention by the team. ED may or may not take this as a (positive) signal. Trying to collect the facts through objective measurements and document by demonstration. Test missions are made, which took me about 6 hours to test, observe, document findings and report. I hope ED will spend some time in this in the near future. FC And please to the community, please let us try to focus instead of deviating to side discussions.

FlightControls system spec Find dxdiag.txt attached. It should contain all the information you need. What I also suggest to do, I have a mission (Gori Valley), which ran fine in 1.5.6. And it completely collapses in 1.5.7. It is the mission that triggered me initially to post this thread here. And I ran this on this machine reported in dxdiag.txt. Shall I post this here? FC DxDiag.txt

Maybe, and when planes are dynamically spawned the operations fail sometimes. Most servers spawn dynamically, as they run GCICAP functionality or other spawning logic. I've been soft on the tests. Now planes are spawned every 3 minutes. If we try every 2 minutes and more planes, some airbases come to have real issues. But that is for the next pile of tests to show. The tests below are the "optimal scenario" tests. Next come out of fuel, damages, airbase crashes... I will also do a scenario without spawning but just placing 10 planes at an airbase and complete the findings. We are suffering these things for years and to my knowledge never a good report was made on these things, very sporadic issues were raised though. The diagnosis is the first, then comes the cure... If we dont put some focus on this, nothing will change, right? ED will assume all is okay, while maybe it isn't. Just note that I KNOW this stuff is not easy to optimize. So all respect to the team if they are okay to consider these matters for an investigation. FC

MOOSE is only used for the spawning, nothing else.

One may ask; why all this and why such a fuss? Well: 1. Airbase operations are crucial to effective air defenses. 2. Intercept must be fast, so airplanes takeoff should be very efficient. 3. Damaged airplanes should be a priority, but only if no urgent takeoff. 4. Returning airplanes should have the lowest priority, only in urgent cases not, like out of fuel, or severely damaged. I know that these are very demanding requirements. I know that building a solution for these is not an easy feat, to be honest, the current APC is already good! But unfortunately not good enough. If possible, could ED have a look at these issues? I would really like to have a look at the APC logic to see where optimizations are possible. Not sure what are the principles defined and logic built that is in place at the moment. - Deadlocks, timings, and prioritization are key parameters in such a process. I know this is not easy and very difficult to get right. Many pitfalls and exceptions can occur. A good APC development may take quite some time, as the audience is big and the exceptions can be huge. But still... Are there any improvements possible on what the test results show?

In summary of APC-001 Test scenarios, some of the findings: 1. Planes crash into each other while taxiing. 2. Planes stop taxi and never depart. 3. Planes hold sometimes for a very long time without apparent reasons. 4. Planes are removed after landing. Just vanish. 5. Some airport operations consume high CPU. 6. Efficiency of airbases differ a lot in Caucasus. 7. Beslan is really bad. 8. Anapa is really bad. 9. There is also good news, some airbases are really efficient in the optimal scenario (no destroyes etc). Some other remarks ... - Why do landed planes after parking remain on the parking spot for hours? Although there isn't a performance impact (it seems) it is a problem for airbase operations. - I noticed in the last DCS 1.5.7 release, although airplanes were destroyed, the landing and taxiing just continued until a block happened. Has this behaviour changed over the last release patch? Because I don't see an update note of that. In previous releases any destroyed airplane will halt airbase operations immediately. The next test scenario will be about testing damaged planes returning to airbases... Landing behaviour will be observed.

APC-001 - Vaziani Overall: Very good Time: 00:58 APC-001 - Takeoff and Landing - Vaziani.miz

APC-001 - Tbilisi-Lochini Overall: Very good Time: 00:53 APC-001 - Takeoff and Landing - Tbilisi-Lochini.miz

APC-001 - Soganlug Overall: Very good Time: 00:42 (fast!) - Some planes were holding a bit too long. - Landed airplanes at the airbase were removed due to limited parking spots. That's okay! APC-001 - Takeoff and Landing - Soganlug.miz