rurounijones

I do not expect anything in these areas either; but the request has to be made to show that I tried at least. Unfortunately I don't think it will work as Viacom interacts with code on the client-side that I think it client-side specific and not usable from the server-side on behalf of client-side calls. Investigating it would take a while though and I don't have that time. There is also the issue that the code Viacom uses is complicated and not part of ED's public API (i.e. not part of their MSE documentation, such as it is) which subjects it to an extra level of risk when it comes to being broken by changes in the code. OverlordBot and DCS-gRPC only use the public stuff (which, technically, means they are not mods) and I don't want to change that.

Still occuring on the latest version. ED are unable to replicate even with trackfiles so unless they add some specific debugging code to the next version or someone figures out the cause some other way; I don't see this going away anytime soon.

@Kate PerederkoThe 2023 and Beyond Newsletter has listed a number of core improvements planned to be worked on in 2023, including the built-in VOIP Since it has been a while and things change. Could you confirm ED's current position on providing access to a multiplayer servers VOIP system for programs apart from the DCS executable? e.g. LotATC, OverlordBot, DATIS and others.

@Kate PerederkoThe 2023 and Beyond Newsletter has listed a number of core improvements planned to be worked on in 2023, including the new ATC. Could you confirm if any part of this request has been recognised by ED as something that will be implemented? Especially in regards to the new ATC?

@Kate PerederkoThe 2023 and Beyond Newsletter has listed a number of core improvements planned to be worked on in 2023 which is great but there was no mention of implementing community requested APIs, of which this proposal is a part, nor anything related to mission scripting generally.. * Can you confirm if working on this proposal is still planned for 2023? * If it is then, for the sake of managing expectations, could you confirm if it is going to be worked on in Q1 or not? (I assume ED, like most companies, plans on a quarterly basis).

Linking here for reference: https://forum.dcs.world/topic/311145-changes-to-scripts-fail-integrity-check-again/?do=findComment&comment=5114479

We do not need a perfect solution; there are a few "Good enough" things that can be done quickly and easily which will benefit thousands of players. DICE for countermeasures DICE provides countermeasure programming and has been downloaded over 5,000 times. It is providing a valuable service to players. ED obviously have the ability to whitelist these particular files and exclude them from IC but they do not wish to do so. So lets look at another easy alternative. Instead of having the values inside the .lua files themselves lets put them somewhere else and then read from that somewhere else in the lua files. For extra security and anti-cheat lets make that somewhere else a data file instead of a source-code file. In the C:\Users\$user\Saved Games\DCS.openbeta path ED can create a folder called "Countermeasures" and then inside can add a JSON file called "F-18.json" (These locations and filrenames are obviously just examples) with the following format which is just a JSON representation of the existing lua table: { "MAN_1" : { "chaff": 1, "flare": 1, "intv": 1.0, "cycle": 10 }, "MAN_2" : { "chaff": 1, "flare": 1, "intv": 0.5, "cycle": 10 } } ED then modifies the lua file to instead read the program values from the JSON file and then DICE, or other programs. or just people not afraid of JSON, can modify the JSON file values without breaking IC. There are obviously some other considerations to take into account such as JSON error handling, default values and the like etc. but a competent developer should be able to make and test this change in an afternoon per aircraft (since different aircraft will require different JSON structures). This is something that can be done now as an intermediate solution while we wait for a full-fledged DTC. Helios for instrument exports Helios literally has a list of patches that they apply to ED files to enable cockpit instrument exports that are currently missing. https://github.com/HeliosVirtualCockpit/Helios/tree/1.6.5600.0/Patching/Patches/DCS/002_008_00000_33006_00000/Viewports/Mods/aircraft ED can look at those, validate that they are safe, and then upstream them into DCS itself so that Helios no longer needs to do any patching. Most of them are literaly one-liners. ED can then invite the Helios devs to the Beta Test team so that they can validate changes work with Helios and contribute fixes before new versions go to open beta. Helios has also been downloaded thousands of times. With a minimal amount of work, ED has now catered to those users. These patches will also fix IC for people who just want to export displays by manually by providing the screens that they can reference in their moitor lua setups. VIACOM for voice commands Viacom has also been downloaded thousands of times. This one I am not sure can be fixed or not by upstreaming changes that VIACOM makes; I haven't looked into it in enough detail. However an alternative is to implement some APIs that allow access to the code that sits beneath the F10 radio menus to reduce the chances of breaking in the future. A request that has been outstanding for many many years. e.g. With these two simple, and one potentially less simple, changes. ED makes life easier for thousands (Close to 10,000 than 1,000 I reckon) of its customers which were impacted by EDs breaking changes.

Just learnt of a hack to get some more information about the rogue ballistics. They are allegedly "Category 3" weapons which translates to bombs, assuming that is not another default value like the map origin positioning and that it is using the Weapon.Category enum. If it is the Object.category then it is STATIC. The APIs for the object seem a bit schizophrenic about whether the object exists or not. local wep = { id_ = 33566465 } // The ID of one of the rogue ballistics objects. return Weapon.getCategory(wep) // getCategory = 3 (A bomb according to https://wiki.hoggitworld.com/view/DCS_Class_Weapon ) // isExist = false // getDesc = Weapon doesn't exist // getName = same as ID // getLauncher = Weapon doesn't exist // getTypeName = Empty string // destroy = No error but Weapon is not destroyed

@MetalStormGhostMaybe but I doubt it since: The coordinates don't match, the ballistics objects in thsi thread are not associated with shooting or weapon firing events and this has been going on a lot longer than 2.8. I would start a separate thread for investigation into what you are seeing.

This has been requested for a long time. See below link for the latest request. Might be looked at next year.

@Napillo@abelianJust in case you guys want to continue that conversation; could you do so in Private Messaging or another thread dedicated to the tool. I don't want to derail this thread from its original purpose, thanks.

I would wait until we get some information from ED on what, if anything, needs to be provided before any more time is spent by the community. They already have 3 Hoggit trackfiles and a liberation trackfile that is basically a miz by another name. I am not sure providing more of the same will be useful without feedback from ED.

@BIGNEWY Ballistics objects are still accumulating in DCS 2.8.0.32937 Open Beta This thread has been tagged "investigating" for over 2 months and 2 releases. If ED are having trouble replicating then please inform us so that we can provide more information.

As an update for anyone following along. Per @Kate Perederkoon Hoggit:

@NineLine@BIGNEWY - Could we get a statement by Eagle Dynamics that show that this request has at least been noted? So far there has been no comment by Eagle Dynamics on this thead so it is uncertain if this has even been seen by ED staff.

Ballistics objects are still accumulating in DCS 2.8.0.32066 Open Beta

@BIGNEWY Do you know if anything was included in DCS 2.8.0.32066 Open Beta related to this report?

Confirmed still occuring on latest patch

@BIGNEWY Do you know if anything was included in DCS 2.7.18.30348 Open Beta related to this report?

With this post confirming work on ATC features: https://www.facebook.com/eagle.dynamics/posts/10166982283080341 I am reiterating my hope that ED can de-couple the main ATC logic from the F10 user interface and provide mission scripting environment APIs so that we can implement alternative interfaces in both single and multiplayer environments.

The community does not have access to any APIs that can garbage collect these objects as far as I am aware. I fully agree that it will probably take time since debugging can be a pain and hope ED do not rush the investigation and potentially come out with a non-fix or break something in a rush to resolve the issue. However I hope that "It might be something in the mission" will not be a position that ED take as a reasoning for doing nothing since the DCS World Platform should not allow invalid objects to be created via its APIs in the first place. It should instead return an error if it is incorrectly called rather than silently create invalid objects. * If the problem lies within DCS world and can be fixed then great! * If the problem lies in the scripting involved in the missions then the DCS World API that is allowing these invalid objects be created should have validation added and return an error instead. Not just in this case, but in general.

Summary: DCS World is creating invalid ballistics objects which are not cleaned up. These ballistics objects persist until mission restart and have a significant impact on the performance of Multiplayer servers, measured in "Server FPS" or the number of simulation frames per second that the server is processing. Background: Ballistics objects are spawned whenever a rapid fire weapon starts firing. They may also be spawned when cluster munitions are dispensed but I have been unable to confirm that. Ballistics Objects tend to have an impact on Server FPS which depends on the power of the server, the number of objects and, apparently, the number of connected clients. This is because the server has to spend time calculating the trajectories and other properties (Collisions etc.) of these ballistic objects. Here is an example of Ballistics Objects being spawned when rapid-fire weapons fire. You can see that the number of Ballistics objects in the mission spike when a shooting event starts and the resulting impact on server FPS. You can also see that the number drops back to 0 as the ballistics objects expire. (Note: The below graphs come from a liberation mission running with only AI running on a home-server) Bug: There are times, however, when Ballistics objects increase without an associated shooting event (Or any other event that I can find). You can also see that after this jump the objects are not cleaned up and the number of ballistics objects in-mission steadily accumulates. If we look at these objects we can see that they are invalid and they are always identical aside from the main ID. Their type is all 0, their coordinates are all 0 and the lat/lon is always at map origin, the country is 99 which is not in the country enum. Clearly these are not something that should exist. "33584385": { "Pitch": 0, "Type": { "level3": 0, "level1": 0, "level4": 0, "level2": 0 }, "Country": 99, "Coalition": "Enemies", "Flags": { "Jamming": false, "IRJamming": false, "Born": false, "Static": false, "Invisible": false, "Human": false, "AI_ON": true, "RadarActive": false }, "Name": "", "Position": { "y": 0, "x": 0, "z": 0 }, "Heading": 6.2831854820251, "LatLongAlt": { "Long": 34.265515188456, "Lat": 45.129497060329, "Alt": 0 }, "CoalitionID": 0, "Bank": 0 } I have also noticed that these invalid objects tend to (but not always) spawn 76 objects at a time as evidenced below (Note: This graph is from a Hoggit Georgia At War session). The trackfile for this Liberation mission can be found in the attached `liberation-mission.trk` which is tiny because, I assume, there is only AI. Impact: The accumulation of these Ballistics Objects has a deleterious impact on the Hoggit multiplayer servers (And potentially others, but Hoggit is what I was analysing) due to the fact that the server still has to assign time to process them even though they are doing nothing. Here is a graph of a typical mission on Hoggit Georgia At War. You can see that the server FPS steadily decreases as the number of Ballistics objects increases. I could find no other metrics that shows such a correlation. You can also see that the number of players also has an impact on the server FPS in that the FPS recovers very slightly as player count drops at the end. I am not sure if the number of players amplifies the impact of the ballistics objects but my assumption is yes because on a server with very few players the impact is not as great. (Note: The below graphs come from the Hoggit "Georgia At War" server) As well as a corresponding increase in CPU usage: You can see here that the number of invalid Ballistics objects is in the thousands. However I have also observed that this depends on which of the two missions that make up "Georgia At War" is running (P1 or P2). In one mission the Invalid ballistics objects consistently numbers in the hundreds and one in the thousands. However even just a few hundred ballistics objects has a massive impact as well. I have observed this behaviour across about 20 different mission sessions. Track files for some GAW sessions with this ballistic object accumulation can be found here: https://drive.google.com/drive/folders/1-_Ae-h6dl5s2k9v1FWwfkME0OBOflbWt (Size warning. 300-400MB) Request: Eagle Dynamics to find the root cause for these invalid ballistics objects being spawned and fix it. liberation-mission.trk

As an update for those following along. Unfortunately no more APIs have been released since the above post. Hopefully ED will prioritise the two APIs that allow us to create F10 menu options on a per-unit basis. Currently the finest granularity is at the group level. Adding these two APIs will complement the Out(Text/Sound)ToUnit APIs added the last time ED provided above. Doing so will remove the last impediment that restricts many servers to operating single unit groups. Although any of the requested APIs would be beneficial and appreciated

This API was added in DCS Open Beta 2.7.12.23362 https://www.digitalcombatsimulator.com/en/news/changelog/openbeta/2.7.12.23362/

https://www.digitalcombatsimulator.com/en/news/changelog/openbeta/2.7.12.23362/ Implements two of the requested APIs: Triggers. Added a trigger and scripting function to display a message to a selected unit. Triggers. Added a trigger and scripting function to sound to a selected unit. Thank you, ED!