rurounijones

> We can say that we are developing a novel logistics system for the CH-47F that dynamically allows the player to determine what is loaded and unloaded from the aircraft based on weight and area. Will this be accessible via the scripting system (e.g. setting load & unload zones to integrate with this system, limiting what can / cannot be loaded) ? Will there be events emitted to the MSE to allow for scripts to react to loading and unloading events? Will scripts be able to load / unload the aircraft themselves without UI. (e.g. Deploy troops immediately on landing without needing pilot interaction) Alternatively. Will ED actually actively collaborate with server owners, mission makers and scripters so that a system that meets their needs, as well as any of ED's needs, is delivered?

That is a head-scratcher but ED will ED

@BIGNEWY Thank you for the information, based on that just a few follow-up clarification requests. > 2. ED doesn't save the traffic. There are no plans for it. If we will change the policy, the statement will be provided. Just to be clear since a lot of people asked me about this with OverlordBot: Does ED do anything with the voice data apart from route it to other DCS customer owned game clients? (e.g. does it stream it to an AI for training etc. This can be done without technically saving anything. Hence the specific phrasing of the question). Ideally the answer to this would be "ED does not do anything with the voice data apart from routing it between customer owned DCS game clients". > 4. Yes, Turn servers are designed to be distributed if needed. Understood but my question was more, are they currently geographically distributed rather than can they be. If they are not, for example, how does ED decide when servers are required in a specific region (e.g. Australia). Does ED even have the metrics and insight to know where traffic is coming from / going to, how much it is, and where a geographically distributed TURN server cluster would provide a better customer experience..

While that is nice to hear; it doesn't answer most of the questions in my original post. Could you have a look at them? 2. Privacy Policy: 3. Self-hosted 4. Geographic Distribution 5. Design

@BIGNEWY@NineLine - Any news? There are still threads being posted (e.g. the one below) where the answer still seems to be "We are adding more TURN servers"

I noticed that one of the reasons given for the variable performance of the In-Game VOIP at launch was not enough TURN servers and that ED were bringing more online to compensate. From For anyone reading along, think of a TURN server as a VOIP host server that the audio network traffic gets routed through like in a traditional client/server setup, although the WebRTC protocol ED users is peer2peer by default the reality of the internet makes this less than usable so TURN servers are needed so that data can flow between clients. This was a bit of a surprise to me and has raised a number of questions in my head regarding the implementation of DCS VOIP that I would appreciate if ED could answer, @BIGNEWY, @NineLine. 1. Centrally Hosted? Can ED confirm if it centrally hosts all TURN servers and that a community DCS server (e.g. a Hoggit server, an Enigma server) is not the server through which the radio network traffic is routed when TURN server option is enabled in the client. The following questions depend on the answer to 1 being "Yes, they are centrally hosted" so the following may not need answering. 2. Privacy Policy: What is the privacy policy at ED specifically regarding the handling of this audio traffic. Does ED do anything apart from route it to other clients. e.g. Does ED record or save the audio traffic. 3. Self-hosted Will ED allow community servers (e.g. Hoggit, Enigma) to run their own TURN servers, have control over them, and be able to have clients connect to them instead of the central ones via a server config setting that is read by clients. 4. Geographic Distribution Are the TURN servers geographically distributed? (e.g. are Australian players, playing on an Australian DCS server, having their audio traffic routed through a local Australian TURN server or is the traffic going half-way around the planet to servers in the US or example) 5. Design This one is more out of curiosity but why did ED go with a centrally managed setup? It increases costs to ED since they now have to pay for and maintain these servers when the DCS community servers are largely sitting idle in terms of spare CPU and RAM and could run them instead.

The latest newsletter https://www.reddit.com/r/hoggit/comments/1770pru/dcs_newsletter_voice_chat_data_link_development/ says > We are also working on a separate voice chat program, which will allow you to communicate with units in multiplayer servers without having to actually run the simulator. Given the above and the fact that we never got anything close to a positive response in this thread; I am going to guess that ED will only allow Voice Chat via their official client, probably locked behind having to log in using DCS username/password, and that any hope of things like OverlordBot, DATIS, Radio music players and the like that exist for SRS will not be available for ED's system.

The latest Newsletter: https://www.digitalcombatsimulator.com/en/news/newsletters/8ee1c3ca60f9edbd7bec24a7c8a1a56e/ Makes mention of lots of improvements coming to DCS Voice Chat but doesn't talk abou texternal integration. Is there anything that can be shared on this front?

Excellent update. Thanks to all involved, hopefully this will add some more gameplay loops for the transport degenerates.

Warehouse APIs, which were part of this request, have been added in todays patch https://www.digitalcombatsimulator.com/en/news/changelog/openbeta/2.8.8.43489/ : And a related Hoggit post: https://www.reddit.com/r/hoggit/comments/15tp037/update_2_on_proposal_for_short_term_goals_for_dcs/

Unfortunately over a year later there appears to be nothing happening. Any updates, @Kate Perederko ? Are you still hiring for a role? Do you have a link to the role on the https://www.digitalcombatsimulator.com/ru/vacancies/ hiring site?

@Se1ko The work to enable exports of all the other instruments has already been done by the HELIOS team. See my post earlier in this thread (posted 6 months ago) about what ED can do to use that work to get exports to function again for everyone and also fix custom countermeasure programs as well. It is not difficult work and I do not believe it to be time-consuming. However ED, for whatever reason, does not care to do it nor provide updates on this topic despite multiple people asking @c0ff @BIGNEWY @NineLine for an update multiple times. Welcome to "How ED reacts to community suggestions, especially low-hanging fruit QoL ones" crash course 101. Leave your optimism on this topic by the door.

@Why485Could you clarify if you mean "Nautical Miles" or not when you say "miles" in your post? Just to remove ambiguity.

@NineLine@BIGNEWY@Kate PerederkoCan we get an update on this topic?

This feature would be very useful for friends wanting to play on popular servers. I have 0 expectations that ED will actually implement this feature in a reasonable timeframe. Please prove me wrong, ED.

@NineLine@BIGNEWY@Kate PerederkoCan we get an update on this topic?

@c0ffAny updates on this? What about the suggestions two posts above for at least DiCE and Helios ?

The Good After a few mission cycles I beiieve this issue has been fixed. Ballistics are not accumulating, server FPS is not degrading and CPU usage is not climbing. It is possible that this was the sole root cause of the ballistics leak and there are no others. If I come across any then I will create a new thread. So congrats to @Flappie@abelian@Moezilla, the others who helped, and the ED staffers who fixed and tested. The Bad While I am happy the issue has been resolved I still believe that ED's handling of this issue has overall fallen short of acceptable standards and I want to go into detail here so that, maybe, things can improve. Server Owner <-> ED Relationship I posted this issue on 2022/09/01 however the general issue of a ballistics object leak was known about by the Hoggit admins for a long time before that with posts in the Discord describing the general issue from 2022/06/01. Now I don't know if anything was reported or not but, having spoken to many different server admins, the general concensus I hear is "It is a waste of time to report server issues to ED" along with a general lack of support, debug tooling etc. This is an awful situation. If a server is having an issue that usually means all the clients on that server are having a suboptimal experience. In the case of this issue it meant players suffering lag, warping and otherwise unfavourable conditions. How many ED customers on the various multiplayer severs have left with a sour experience due to this bug in the course of the 6 months or so it took to resolve it? I am willing to bet that it is thousands of customers and thousands of hours of flying time where customers have been left with a bad taste in their mouth at the end of a session . My suggestion to ED to improve this situation is: 1. Provide a formal way for mutliplayer server admins of servers with large player bases to contact you to report issues. Either a forum or a discord channel explicitly for communicating issues to ED and collaborating on fixing them. You have stats on which servers are heavily populated I am sure so invite their admons. Admins having to rely on "Try pinging @NineLineor @BIGNEWYand hope for the best" doesn't cut it. 2. Having created this formal communication method. Listen to them and accept that things like "please provide trackfile" is not always feasible on servers with scripts that run for hours with 10s of players on them where an issue may be inconsistent. Work with them collaboratively to try and find the issues which leads me to the last point: 3. Provide them with the tools they need to be able to perform this kind of investigation. I know this has been requested because multiple people have complained to me about these requests being ignored. The handling of this issue by ED, aka "Cannot Reproduce" & Radio Silence I am going to go out on a limb here and say that this bug report was about as good as ED can expect without deep-diving and finding the root cause itself. It contained lots of information, it pointed to exact syptoms. It included 4 different trackfiles from two completely different setups. Including an AI only tiny trackfile. Despite this the response was "Cannot reproduce". But when @Flappiestarted looking into it he appears to have been able to reproduce it from the small AI trackfile I provided in short order. So the questions that ED needs to answer, at least to itself is "Why couldn't ED staff reproduce something that was reproduced by a volunteer in short order using submitted data.". If ED cannot reproduce things via trackfiles then why should the community spend time and effort to provide them? My next issue is that, once the "cannot reproduce" status was entered that was basically it. The issue languished for months and there were no updates; I had to literally contact ED staff on discord to try and get an update on what what was going on. Had @Flappienot taken the effort to root cause this I have no doubt that this would still be unresolved and ED customers would still be suffering. This ties into the linked post which I think ED needs to consider a lot more carefully.

> Now, maybe some other things are also causing these eternal ballistic objects. I tried countermeasures, but they are not (ATGM ammo is another source of eternal ballistic objects but it's reported already). I think there probably is something else due to the number discreprencies between GAW P1 and GAW P2 but it might be better to wait until the current known issues are fixed then do some more recording of trackfiles between the two (i.e. if P1 stops accumulating completely and P2 is still accumulating) which may make finding other causes easier.

This behaviour was observed in our MP session today on both the F-16 and the F-18. The replication instructions below are for the F-18. Start with an F-18 with a TGP (I was using the Lightning). 1. Create a waypoint, hereafter referenced as WP1. 2. Take-off. Turn on Radar and TGP and wait for warm-up. 3. Enter A/G mode. Have the TGP on one MFD and the Radar on another. 4. Waypoint Designate WP1 The status as this point is that WP1 is designated and both the TGP and Ground Radar are slaved to it. 5. Select the Radar and move the Designation Cross to a new point 500 meters west of WP1. I am calling this poing AP1 (Aim Point 1). At this point the TGP will now be pointing at AP1. However the radar's Designation Cross does not move and is still pointing at WP1. These two sensors are now desynced by 500 meters. 5. Select the Radar and move the Designation Cross (Which is still on WP1) to a new point 500 meters west of WP1. I am calling this poing AP2 (Aim Point 2). AP1 and AP2 should be the same offset from WP1, given the wierd current logic, and the TGP and Radar should both be looking at this location if they were synced. However in reality At this point is: * The Radar Designation Cross has snapped back on WP1. * The TGP is now looking at a point 500 meters west of AP1/2 because when we slew the radar based on an offset of WP1 the TGP will slew the same amount but from AP1 instead of WP1. If we drop a bomb at this point it will hit WP1. So there are two bugs here. A. The Ground Radar Designation Cross snaps back to the Waypoint and targetting systems will use this as the drop point for things like bombs in CCRP. B. The TGP does not stay slaved to the Desicnation Cross. Things not tested: * What happens if you switch to the TGP, does the Radar Designation Cross start following the TGP? Properly or using the wrong base offset?

The AI only track is a self-contained liberation generated mission so the only scripting that may be involved will be in the mission file itself. I am not aware of anything liberation does that would cause wierdness, I think their scripting is imited to writing stuff out when the mission closes. I am not sure if could be scripting or anything outside of the ED generated code that could be causing the issue directly since there are no APIs available for creating or managing ballistics objects. Obviously something is causing this, but I think the root cause must lay somewhere in the built-in ED code, not any 3rd party scripting. I don't think it is the ship missiles are the root cause since the ballistics count can go very high on GAW servers where ships are not firing at all. The worst case is in the thousands. But I wonder if it could be a pointer in that some long-lived ballistics objects are not being deleted properly and an invalid object takes their place? However I see the ballistics count increase almost immediately sometimes on server start so again I am not sure it could be related to existing ballistics objects.

Not really. I screwed up and forgot about MOOSE, massive brain fart but what is done is done and I would prefer not to derail this thread talking about it.

Thank you for the update. Then please correct me if I am wrong but that sounds like: It will not be worked on in Q1 2023 There is no guarantee it will be worked on at all in 2023; depending on if Eagle Dynamics are able to hire an employee solely / primarily to work on the scripting environment as no existing employees will be assigned to working on it.

When a DCS server fails to authenticate with the central DCS authentication servers and is displaying the modal window indicating that fact; DCS will max a single CPU core in the background. Below you can see a server which failed to login on restart and was not reset for 3 or so hours and the effect it had.

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.