Sending data to clients from Mission Scripting Environment.

[rurounijones]

A request has been made to be able to have OverlordBot send transmissions from the MSE. For example, something like the following:

coalition = 2
frequency = 253
text = "Objective alpha has been neutralised"
OverlordBot.speak(coalition, frequency, text)

Thoughts on how this could be done.

OverlordBot connects to DCS-gRPC and calls the OverlordBot.StreamTransmissionRequests API. This API then uses similar rust code as the current event streaming to check a lua table(?) for entries that are added by the OverlordBot.speak command and then streams them to the connected OverlordBot.

This is just a vague general idea at the moment and needs fleshing out so putting here for further pondering.

[rkusa]

TTS:
Not the main question here, but still some notes about TTS. We could in theory pull in the whole TTS/SRS stack from DATIS and implement this without going through OverlordBot. We could also try to implement it using trigger.outSound instead of going through SRS.

Push/pull data from MSE:
I have a similar use-case for DATIS in my backlog. I want people to be able to dynamically create/change/disabled ATIS stations with Lua scripting. This comes down to the same underlying principle.

OverlordBot connects to DCS-gRPC and calls the OverlordBot.StreamTransmissionRequests API. This API then uses similar rust code as the current event streaming to check a lua table(?) for entries that are added by the OverlordBot.speak command and then streams them to the connected OverlordBot.

That or instead of a lua table, we could add something similar like onChatMessage that allows to directly push the data to the gRPC server instead of having the server poll for lua table changes.

[rurounijones]

I prefer going via SRS since that gets us the radio effects / not radio effects based on client preferences which I think is better for the user and adds consistency.

I called this OverlordBot.speak because that was what I was thinking but there is nothing stopping us from making this generic I think which would allow clients fo implement their own TTS if they wanted. Something like onRadioTransmission maybe? and the clients would connect to MODULE.streamScriptedTransmissions to receive the transmissions (Not sure what name would be best for MODULE here).

The onChatMessage approach is definitely the better solution. I wasn't really thinking too much on th details.

Someone just messaged me about another use-case for this related to possible use with https://github.com/uriba107/DCS-Hound/tree/develop

[uriba107]

That would be me :)

I think we can generalize it by saying we need a wrapper for SRS_ExternalAutio.exe

Ciribob provides a LUA interface
https://github.com/ciribob/DCS-SimpleTextToSpeech

But LUA isn't the best at running binaries, has some wierd limitations and issues. like charachter limit and not being able to launch background process..

so adding a "TransmitRpc" function, which will emit all the args in json format to gRPC which will launch the binary, should cover most cases.

[rurounijones]

I think we can generalize it by saying we need a wrapper for SRS_ExternalAutio.exe

I think that is different to what we are talking about here. This is about sending radio transmission text data to gRPC clients that will then do what they wanted with it. This could be OverlordBot transmitting, some client that outputs that to text for someone who is deaf, some client application that then calls SRS_ExternalAudio.exe

However DCS-gRPC shouldn't be calling SRS_ExternalAudio.exe itself. That is not what it is about.

[rkusa]

I think what @uriba107 is referring to is my comment about TTS, which is kinda another topic, but my bad for mixing it into the discussion. I've created a separate discussion for it: #70

I called this OverlordBot.speak because that was what I was thinking but there is nothing stopping us from making this generic I think which would allow clients fo implement their own TTS if they wanted. Something like onRadioTransmission maybe? and the clients would connect to MODULE.streamScriptedTransmissions to receive the transmissions (Not sure what name would be best for MODULE here).

I'd go a bit more generic, something in the likes of of the following (@rurounijones this might remind you of something we've previously already discussed on Discord).

In the MSE, one can call something like:

GRPC.sendCommand(initiator, "commandName", commandParams)

service MissionService {
  rpc StreamCommands(StreamCommandsRequest) returns (stream StreamCommandsResponse) {}
}

message StreamCommandsRequest {
}

message StreamCommandsResponse {
  optional dcs.common.Initiator initiator = 1;
  string command = 2;
  google.protobuf.Struct params = 3;
}

The main drawback is that google.protobuf.Struct is not a strongly typed message anymore. However, I think we'll have another use-case where we need this, and where we might not get around the google.protobuf.Struct: F10 radio commands.

Let's say I want to add radio commands to spawn different groups of bandits:

• F1: Spawn Mig29
• F2: Spawn Mig21

As a client when a player selects one of those commands, I need to receive feedback from the gRPC server about what has been selected. What I'd want to receive is something like:

{
  "initiator": { "unit": ... },
  "command": "spawnBandit",
  "params": { "name": "Mig29" }
}

command pretty much corresponds to functionToRun and params to anyArgument in missionCommands.addCommand. This example is just one of many F10 radio use-cases, and I think it is impossible to get around the google.protobuf.Struct.

So why bring this up. I think this is the exact same use-case as OverlordBot.speak. We have an arbitrary/custom command send from the MSE to the gRPC client. The OverlordBot.speak use-case would become:

GRPC.sendCommand(nil, "overlordSpeak", {
  coalition = 2,
  frequency = 253,
  text = "Objective alpha has been neutralised"
})

[rurounijones]

It sounds like we will have to have a StreamCommands API to support F10 usage for example. But I really want to avoid it becoming the "default" answer. My worry is that StreamCommands it becomes a free-for-all undocumented dumping ground for functionality instead of thinking about, designing, writing and documenting actual specific APIs for them.

It sounds like it might be the only option for the F10 setup but I don't think it is necessary here. The parameters for sending a transmission are generic and fixed enough I think that we can have a generic GRPC.sendTransmission(coalition, frequency, modulation, text) method and then the clients can do what they need with it.

Also is your vision for SendCommand that it is only callable from the MSE or can gRPC clients send as well to enable client <-> client communication which might be a benefit.

[rurounijones]

In terms of sending freeform data to clients, this is now possible using events in the event stream. See #121 as an example. You can send an event using GRPC.event() - I am still not sure we want to encourage the direct use of this method vs a wrapper with specific event types, but the option is there.