Search the Community
Showing results for tags 'api request'.
Found 6 results
-
DCS has a plethora of OutText APIs. * outText * outTextForCoalition * outTextForCountry * outTextForGroup But no ability to send outText to a single unit. This has massive impact on online mission design since it is one of the reasons mission makers end up making single unit groups which breaks wingman Datalink features, limits the callsign availability and increases the chances of callsign duplication. It has also limited my ability to provide good integration for Speech-To-Text functions for hearing impaired / deaf players so that they can "listen" to OverlordBot and conversations going on in SRS. Please implement outTextForUnit. It should be a copy/paste of outTextForGroup and a small code change to get a unit by id instead of the group and then check if this unit has the same id instead of checking if it is a member of a group. This is a very simple change with a massive impact.
-
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- 50 replies
-
- 45
-
-
- api request
- overlordbot
- (and 1 more)
-
OverlordBot is an Open Source SimpleRadioStandalone voice enabled AWACS and ATC Bot. * It has been installed on over 80 public and private multiplayer servers * It processes around 100,000 transmissions and about 3 days worth of audio per month * Over 600 players have submitted voice training sets to help the bot recognise them * The Discord has over 1,300 members. Currently OverlordBot implements all its features using internal code. It does not call any ED provided scripting APIs to implement its AWACS and ATC functions (Because there are none that are applicable to these use-cases). However it can also act as a simple voice-to-command proxy to the DCS functions that ED makes available to the Mission Scripting Environment so that those functions can be triggered using voice commands that are transmitted over SRS (Just like in real life, the radio voice channel is the communication method and requests and responses can be heard by everyone tuned in). I would like to give players the ability to call into the new ED ATC, that is currently under development, without needing to use the F10 radio menu, other mouse / keyboard based UI or requiring local mods and also generate the response using a TTS system. Providing a full two-way voice UI will increase immersion and make ATC radio calls more natural for both transmitters and receivers. Therefore this request is is to expose the APIs required so that we can trigger the functions that would otherwise be triggered by clicking on the existing F10 radio menu. For example, if there were an F10 radio command under a specific airfield for `Inbound` then there would be a mission scripting API along the lines of result = atc.callInbound(airfield_id, unit_name, transmit_pilot_voice = false, transmit_atc_voice = false) -- transmit_pilot_voice will determine if the in-game pilot states the request with the pre-recorded audio snippets. -- true means transmit using the pre-recorded audio snippets. Useful for things like Voice Attack where the player is not transmitting over voice comms -- false means there is no audio transmission sent as other players will already have heard the request over SRS and OverlordBot triggered the action -- transmit_atc_voice will determine if the in-game ATC replies with the pre-recordded audio snippests -- true means that the ATC transmits the response in-game -- false means that the ATC does not transmit a response in-game (Will be used by OverlordBot that will speak the response from the result) -- Result table contains structured pertinent information including the text of what the ATC would say or a structure containing the data that would be needed to turn into spoken text. If ED action this request then I would be happy to discuss this bit in more detail. (There would probably need to be some sort of push mechanism or method that can be polled for updates to be transmitted when ATC wants to contact the player. A new event in the event steam would be a good method I think, happy to discuss that if ED proceeds with this request.) As this new ATC is in active development I hope this request can be actioned more easily in the code being written now. A side request would be to expose the existing radio APIs so that we can do the same thing (For example being able to contact tankers via voice for air-to-air refueling operations).
- 92 replies
-
- 48
-
-
-
- overlordbot
- request
- (and 1 more)
-
As a result of a discussion on the Hoggit sub-reddit with NineLine I am submitting this documentation for consideration by Eagle Dynamics. This document was written mostly by myself but with heavy advice and expertise being provided by Grimes whom I believe to be _the_ expert on the DCS scripting system. This document could not exist without him. It has already been reviewed by around 30 community members and endorsed by admins of the following online servers: Hoggit Enigma's Cold War Server Growling Sidewinder Flashpoint Levant Conquest DCS Task Group Warrior 473rd Squadron MMSERVERSMACK [KW]LaTaniere SK Dedicated Server DCS Singapore Through The Inferno servers Rotorheads Server DCS Academy server D3W Server (Spanish community) Airgoons server Havoc Company servers VAF Servers Grim Reapers Stoneburner Training server BSD Squadron Servers As well as the following DCS related projects: LotATC DCS:Liberation Skynet IADS DCS-gRPC OverlordBot The CTLD Project The Hound ELINT project I am posting it here so that others can read, comment and offer their support if they so desire. This document can be read at the following URL: https://gist.github.com/rurounijones/92fee4f9f2acb4fac99da9121ac1cc1f and is available in PDF format as an attachment to this post. TL;DR Below is an example of things that could be done if these proposals were implemented so comment with your support if these sound good: For example: * Allow servers to fully implement their preferred logistics systems for units, weapons and fuel. Have players handle it or have AI handle it but let players escort or attack the ground, sea or air transports. A mix of both? Why not! What about Storing inventory in targetable objectives for strategic strikes by crazy Viggen players? Whatever the servers want for their scenarios. * Fully procedurally generated objectives instead of the usual hard-coded ones in a limited pre-created set of safe locations that the mission make manually picked. * Fully procedurally generated ground forces without units in forests and untargatable or clipped into buildings * Let players build their own FARPs and roadbases and spawn there to conduct their missions, then make them destroyable so the other side can recon and then deny them. * Allow for mission flight planning using an online Webmap then generate your flight group mid-mission with waypoints and loadouts on the server. ScriptingProposal.pdf
-
Dear Eagle Dynamics, There is currently no way to determine if an aircraft has: -A targeting pod -Fuel tanks (we can sort of figure this out from fuel state, but it is not optimal) -Gun pods -ECM pods -Some other types not listed By using the the scripting engine. I can see a few possible solutions: - Include these items in a getAmmo() call - Include these items in a getSensors() call - Create a new function call for these specific objects, call it getPods() - Create a new function call that dumps all objects on all pylons. - Give scripters some way to get the current weight/mass of the aircraft, this way at least we could do some math and determine what is equipped (this information is also not available through the scripting engine and probably should be... for this problem though, it is my least favorite solution). We have seen ammo points scripts being adopted to discourage silly "unrealistic" load outs in more serious PvE servers. Many in the community have enjoyed that capability. Some folks would like to see a less "equip whatever you want" type environment in favor of assigned load outs for particular mission types. There are a TON of possible use cases and applications for this, and in general the more access we have to information in the simulation environment the more ability we have to make engaging missions. This benefits you as well, as new players and potential customers tend to stick around (and buy modules) when there are fun and challenging scenarios freely available such as they are in multiplayer. Thanks for reading this, I very much hope you will implement this request. Yours sincerely, A DCS customer -
I run an A-10C training course and a server my students can use for practice and training. The training and the server are offered free to the Tactical DCS community. I've used the simulator scripting environment (SSE) to place comms menu F10 items so that students who come to the server can choose which training mission they wish to run and/or to reset their desired training mission so they have a known starting state (and targets to kill.) I've done this using ADD_RADIO_ITEM_FOR_COALITION to set a flag and then set a SWITCHED CONDITION to LOAD_MISSION the requested mission based upon the flag value. It works well--and if ED would like to see the result I'll be happy to share the server credentials with you--but there are three undesirable effects: 1. It's a pain to use the Mission Editor to duplicate this functionality for each mission, 2. Since the code exists in each training mission (multiple places) it's easily foreseeable that the code could get out-of-sync and defects introduced in one or more missions as a result of mis-typing or other inadvertent errors, and 3. I'm currently limited to 10 items in the comms menu--if I were able to use the ADD_RADIO_MENU_ITEM in the SSE I'd be able to offer a richer mission set via submenus to my students and the Tactical DCS community. I've looked through the OpenBeta LUA code (grep is eminently helpful) to see if a_mission_load is exposed in the SSE but it doesn't seem to be. If it is, please correct my misapprehension and advise on how I may access it from the SSE. Otherwise, please consider exposing it as a callable function in the SSE. Thank you!