rurounijones

I am the developer of OverlordBot, a voice controlled AWACS and ATC bot used on a number of multiplayer servers ( More info: https://gitlab.com/overlord-bot/srs-bot/-/wikis/home ). In order to provide more requested features for pilots I am asking ED to implement the following APIs in the mission scripting environment so that they can be called by the bot, they will also be useful to other scripters. Obviously the exact call semantics are up to ED as long as they fulfil the desired goal. API TO HELP WITH DECLARE Players have requested that the bot supports declare calls, currently this is not really possible because the bot does not know what the player's radar is looking at. An attempt was made ( https://gitlab.com/overlord-bot/srs-bot/-/issues/15 ) whereby players would have to specify bearing and distance but this was not reliable enough. This also opens up the ability for the AWACS to be smarter about who is targetting what and provide more SA. Unit.getRadarTarget() -- returns a table {object = object} of whatever the units's radar has bugged or STT locked. Note that the above code is specific to OverlordBot's needs. Grimes has a similar request (listed below) that is a superset of functionality that, if implemented, would also work. Unit.getSPI() -- returns a table {point = vec3, object = object} of whatever teh radar or TGP is focused on APIS TO HELP WITH ATC In order to enable the bot to provide better ATC functions to players, especially at night, the following APIs are requested. Airbase.getRunways() -- returns a list of runways at a base. {id = {headingNumber, length, actualHeading, shape, active = boolean}} -- Ideally ILS information as well if ILS is present Airbase.getActiveRunways() -- returns the data as above entry but only for the active runways Airbase.setTaxiwayLights(true/false) -- true to turn the lights on, false to turn them off Airbase.setRunwayLights(id, true/false) -- true to turn the lights on, false to turn them off

Thanks BIGNEWY. If possible could you also confirm the logic of active runway selection? Based on what other people have said in this thread it is not as simple as wind direction. (Or there are bugs elsewhere). Having this information, along with any custom logic (Khasab for example) will help us make sure things like DATIS and OverlordBot can stay in-sync with DCS.

We did some testing and it looks like there are two separate issues at Al-Dhafra (We did not check any other airfields) Issue 1 : ILS 109.10 and 111.10 are mounted incorrectly. * The ILS for 31 (109.10) is mounted backwards (It provides ILS information for Runway 13). * The ILS for runway 13 (111.10) is mounted backwards *and* there is something wrong it that causes the glidelope info to not appear until you are basically over the midpoint of the runway. (It is mounted upside-down?) Issue 2: Incorrect ILS selected with low wind. (Incorrect based on the statement by BIGNEWY above at least in that it is determined by wind direction and requires very little wind). When the wind is set to 190 @ 2m/s in the mission editor, and therefore the headwind is 010, then runway 31 should be in use. However the ILS channel (111.10) is active (as well as the above issue of being mounted incorrectly). When setting the wind to 10m/s it appears to select the correct ILS channel (againt, mounted incorrectly). Trackfiles attached for the following weather conditions: Wind 190 @ 2m/s Wind 190 @ 10m/s Wind 130 @ 10m/s Wind 310 @ 10m/s ILS-track-files.zip

Unless we know the underlying logic of how airfields' active runways are determined (including exceptions) then there is nothing we can test since we don't know what we are supposed to be asserting, hence my question. The best we could do is come up with (possibly inaccurate) assumptions, black box test on those and hope that the assumptions are correct and submit trackfiles. If those assumptions are not correct then that is needlessly wasted time. However, since BigNewy has since stated The logic is allegedly very simple and can now be tested.

What is the logic that DCS uses to determine the active runway? Is it generic or do individual airfields have different logic? We were flying on Persian Gulf with the wind 010 and 2m/s which, based on wind, should mean Runwas 31L/R are active. This is what the humans ATCs were using, it is what DATIS and OverlordBot were reporting. However the in-game airfield ILS was only active on runways 13. Is this a bug or does DCS use more than just wind heading to determine the active. Man it sure would be nice to have an `Airfield.getActiveRunways` or `Airfield.getActiveRunwayHeading` API

Without going off-topic (I would prefer to keep this thread mainly between SRS based Voice Developers and ED) LotATC will also be badly affected by this change since people will not be able to use it and the voice system at the same time. Hence my request for clarification from @Kate Perederko .

Thank you for the update Kate and a apologies for the late reply. Disappointing but understood. I don't really understand this bit. The requirement is that ED don't restrict access to the voice system. It sounds like is based on open protocols and therefore would be accessible by default and probably only restricted by an authentication system. So I am not really sure what you mean by "Open to cooperation", could you clarify?

davidp57 has done the job and all is well. This request is closed.

@davidp57 I ran the mission and all seems well and it highlighted errors in the JSON I had already created for Anapa which is a damn good way of proving the tool's worth! I might have come across some wierdness with reloading edited values but it only happened once and a mission restart was all that was needed so I didn't investigate. I will put together a wiki page on the OverlordBot wiki with a link to the mission and other details for the mappers to look it. It is possible they may run across some issues Thanks again for you work and volunteering your time.

@davidp57. Thank you very much! I shall look at it as soon as I get home from work.

Ahoi all. If anyone has some time to kill, DCS scripting knowledge and would like to volunteeer to help the Overlordbot project then please keep reading. Background I am the developer of OverlordBot, an SRS enabled AWACS bot: https://gitlab.com/overlord-bot/srs-bot/-/wikis/Interaction and am currently working on an ATC implementation. The first version allows people to call into an airfield and request taxi at which point the bot will respond with instructions. e.g. For Anapa when runway 04 is active: In order for the bot to work we need to do airfield mapping for each airfield. This require someone(s) to map out the taxi points for a particular airfield so we can then add them to a navigation graph (e.g. https://git.io/JJL9f For Anapa 04 active). We need the Lat/Lon of these points as well so the bot can determine where someone is when they call in. It has been a long time since I have had to do DCS lua scripting so if someone has some spare time and can volunteer to do some scripting for the following request; it would be much appreciated. Request In order to reduce the amount of effort it will take to map out the airfields we want to give some tools to the people who will be doing it. Therefore write a script that: On mission start, reads a json file with the following format: https://gist.github.com/rurounijones/21d3735ce88e9acf10bd2b758761e6fa from a location of your choice (If one exists). For each ParkingSpot, Junction and Runway in the json file: Place an F10 map marker (using markToCoalition) at the appropriate position (json file is decimal lat/lon) and with the marker title set to the name of the ParkingSpot, Junction or Runway. Allow for export of all Map Markers to a machine readable format (not necessarily the above json config file although it would be nice, we can convert it later if necessary.) on command. e.g. If it is too much hassle to write back to the json then this would work: # Name lat Lon Charlie Mike, 45.00000, 37.000000 Apron 1, 45.50000, 37.100000Stretch goals: * A radio menu command that re-reads the file so that people can update the file and re-display while still in mission. * Read all json files in a directory and places their map markers. (Very optional, as would require writing back multiple config files with F10 markers associated to their parent airbase) This will allow mappers to do something like the following then export the data. Embedding the script in an empty mission and just sending the mission with some basic instructions (e.g. where to put the json files) would be the preferred deliverable. This isn't particularly difficult work I know but it is work in a domain I haven't touched for a while and when I have plenty of other things I can be working on. If no one can do it then I will get around to it. but if someone does have the time, great

Thanks very much. We know the answer to the first one is WebRTC. The rest are the open ones. Honestly, please ignore those mostly uninformed comments and don't let them derail the requests for information from myself, n26, DArt and other Developers who are working on Voice integration in various ways.

With the latest news about Voice Chat in https://forums.eagle.ru/showpost.php?p=4409321&postcount=260 Is it possible to get an update on this request?

@BigNewy Changelog: https://www.digitalcombatsimulator.com/en/news/changelog/openbeta/2.5.6.45915/ "Known issue: VC availability is controlled by client’s setting only, ignoring server options" Again, this does not match what we have reported. It was ignoring client settings as well as far as we have been able to tell. My client had voice chat disabled but it still appeared to be activating. Can you confirm this is how you have understood the bug report. Or is the issue that if one person's client Voice chat is enabled then everyones is also enabled? Or did you guys fix the fact that client settings weren't honoured and not list it in the Changelog? Could we please get some clarity around what you understand the issue to be; because right now what we are saying and what you are saying is reported do not seem to match.

@BigNewy Thanks for the update.You stated "dedicated server unable to disable voice chat" however there is no mention of the fact that I am seeing VoiceChat stuff in my client logs despite voice chat being disabled in my client. Can you confirm if the client honouring settings is also investigated and reported? I don't want only the dedicated server I am playing on to be able to determine if I have voice chat enabled or not. I want my client to honour my client settings as well

GAW has been having desync and lag issues since the new patch. Someone also mentioned GrowlingSidewinder is having similar issues but I have not checked. Upon looking at logs it looks like VoiceChat is running in some capacity despite being disabled on my client and the server. My client logs (Trimmed for just the voice chat stuff): https://gist.github.com/rurounijones/e367135aa9e10c953c827cc5e1ea487f Other players were also reporting similar logs. GAW'S Acidic mentioned that he is seeing the same sort of logs server-side despite ["voice_chat_server"] = false It is not confirmed that the voice chat is what could be causing the desync but to my knowledge it has just started happening with the latest patch. Check the hoggit discord "georgia-at-war" channel around 2020/03/21 19:40 UTC for discussion.

Cycling through zombie missiles (Missiles that no longer exist but still have an external view associated with them) using F6 resulted in a runtime crash for both myself and another player. There were an unusual number of them on GAW at the time which may have made the issue more obvious. My DCS log is attached. Other player will submit theirs here as well. I was also streaming at the time: I have no idea if this F6 cycling happens if you cycle through enough normal weapons or not or if it is only due to zombie missiles. Obviously if the zombie missile issue was fixed then it would remove one *possible* root cause for this issue (And would be really really *really* nice from a player's perspective anyway). dcs-f6-crash.zip

Suffered colossal lag and framerate drop on PGAW. This is the same incident as StandingCow above. Again, was streaming so you can see for yourself. - 10 Minutes onwards Quit after last framerate drop. Logfile attached Track file at http://www.filedropper.com/persiangulfatwar100evening-20191020-145458 dcs.zip

More samples Playing on GAW without too many issues then got crippling framerate for a bit. After that there was obvious rubber banding. I was streaming at the time so you can see it happen. Framerate crash - 0:51:30 Rubber Banding - 0:52:30 dcs.log file attached. The issue occurred around the timestmap of 2019-10-19 06:56:xx in the logfile. Interesting to note that Both I and StandingCow were in game together and both have the same errors in our logfiles at that timestamp and very similar ones afterwards. Track file available @ http://www.filedropper.com/georgiaatwarv3024evening-20191019-150804 dcs.zip

Ahoi ED types. As you know the current standard tool for voice communication for DCS players is the 3rd party SimpleRadio Standalone (SRS). As well as SimpleRadio Standalone the client for use by players in-game (and external for people using LotATC in an AWACS role) there is the Network Protocol that can be used by anyone who integrates with it. This has lead to applications such as: A 3rd-party ATIS application which is used on major servers such as Hoggit: https://github.com/rkusa/DATIS/ A prototype AWACS Bot: https://old.reddit.com/r/hoggit/comments/dbkea7/overlordbot_preview/ A music player that broadcasts over SRS. Basically the open ecosystem of SRS allows people to do interesting things with voice & DCS. My question is: What is the plan for the built-in DCS VOIP System? (as described by Wags in https://www.mudspike.com/mudspike-ama-with-eagle-dynamics-senior-producer-matt-wagner/ ) I seem to remember that it was going to be based on Discord and their GameSDK but not sure. So my questions are: Can you share with us what VOIP solution you are going with? Is the technical solution ED is using for VOIP going to be externally accessible? (Externally here meaning accessing VOIP outside of DCS) Will ED allow external access? Will ED require a bureaucratic process to get such access or will it be freely available? Will this access be only to the Lobby system or also to be able to communicate with Clients using Stage 3 radio communication (as described by Wags.

If the original creator is not coming back to DCS is there any possibility of open-sourcing the code so that others can take up the load?

F10 visibility is just a broken system for GCI on Blueflag (which is an ED issue I think, not a blueflag one). * Mirages at 40k approaching an EWR site suddenly disappearing then reappearing a minute later still cruising at 40k. * Enemies seen taking off from enemy airfields waaay in their backlines then disappearing after take-off. * F-15 radar locks usually showing enemies on GCI F10 while no other blue planes do (I am assuming some legacy FC3 code at play here). * EWRs losing bandits between 10 and 20 miles away over flat terrain while they are at 3k feet (In fact based on my experience I have never had an instance where an EWR appeared to be actually working or doing anything) * Bombers basically highlighting every SAM site on the map * Randomly being able to see certain SAMS up in Anapa while blue is still down in Kutaisi. * I once could see an enemy way NW of the map despite having no friendlies nearby and no EWR or airfields. I ended up guiding an F-15 in on the target with his radar off so that he could get a surprise kill. No way I should have been able to see that enemy. There may be some twisted logic to all these wierd scenarios I see but I cannot fathom it.