Advice sought: batched external control of ~24 aircraft for multi-agent RL and human-in-the-loop research

[aaroncuilu]

Hi, and thank you for maintaining DCS-gRPC.

We are a university research group building a multi-agent RL and human-in-the-loop prototype. External Python policies would provide tactical intent to DCS AI aircraft every 1–2 seconds:

• desired heading, altitude and speed;
• target assignment;
• engagement mode / ROE.

Our target scenario is two externally controlled flights of eight aircraft each, plus up to eight human-operated or normally AI-controlled aircraft on a DCS Dedicated Server.

We plan to use one Python process and one gRPC channel, not one DCS client per AI aircraft. Since the full Controller task API does not appear to be exposed as typed RPCs in the current public proto, our proposed interim design is:

1. enable Eval;
2. install a resident Lua adapter at mission start;
3. send one small batched command table per tick for all controlled aircraft.

The installation would be offline and version-locked.

Before committing to this architecture, could you advise on the following?

Eval and task control

1. Does Lua state created through Eval persist for the lifetime of the mission? What happens after mission reload or restart?

2. Is Eval plus a restricted resident Lua adapter a reasonable interim approach for setTask, pushTask and setOption control? Are there payload-size, serialization or sandbox limitations we should know about?

3. Would updating trajectory intent every 1–2 seconds interfere with DCS AI attack, weapon-employment or threat-reaction logic? Is it preferable to evaluate every second but only replace tasks when heading, altitude, target or engagement mode changes significantly?

4. For independent control of each aircraft, is one single-aircraft DCS group per aircraft the recommended arrangement?

Scale and multiplayer

5. Our expected load is roughly:

• 0.5–1 batched Eval call per second;
• StreamUnits at about 1 Hz for 24–32 aircraft;
• one StreamEvents subscription.

At this scale, is the likely bottleneck gRPC/Lua processing, repeated Controller task changes, or DCS AI/sensor/weapon simulation? Is there a recommended StreamUnits interval or useful server-side performance metric?

6. Are there known issues when running DCS-gRPC on a Dedicated Server with human clients connected, particularly event completeness, Mission Scripting Environment differences, or integrity checks related to MissionScripting.lua?

Three-sided engagement

7. We would ideally support two externally controlled AI factions plus a human faction. Can DCS units be ordered to attack same-coalition or neutral-coalition units through AttackUnit or similar tasks?

Are neutral groups visible and controllable through DCS-gRPC and Eval, or is a true three-way mutually hostile engagement impossible at the DCS engine level?

Events and mission lifecycle

8. In dedicated-server AI combat, are S_EVENT_SHOT, HIT, KILL and UNIT_LOST generally reliable enough to use as the primary source for scoring and analytics?

9. Are loadMission and reloadCurrentMission reliable for automated batch runs? What happens to existing gRPC streams and clients after a mission reload with autostart = true?

Versioning and contribution

10. Which current DCS build would you regard as the best known-good pairing for a version-locked DCS-gRPC installation?

Would contributions toward a typed, batched aircraft-intent or Controller service be welcome? If the prototype succeeds, we would be happy to contribute reusable parts and share performance benchmarks from the 16v16 tests.

Thank you. We would also be glad to share our findings with the project.

[YoloWingPixie]

Thank you for the detailed description and apologies for the later response. One Python process, one multiplexed gRPC channel, one StreamUnits subscription, one StreamEvents subscription, and one batched command per policy tick is a sensible topology for this experiment.

1. Eval lifetime

Mission Eval executes loadstring(params.lua) followed by pcall, without creating a separate Lua environment. Consequently, functions or tables assigned to globals—such as _G.ResearchAdapter will remain available for subsequent calls in the same Mission Scripting Environment (MSE). Locals created only inside an individual Eval chunk do not persist. The result is serialized with net.lua2json. See the current Custom.Eval implementation.

That state lasts only for the current mission. On mission termination DCS-gRPC stops, and a reload creates a new mission Lua environment. With autostart = true, DCS-gRPC starts again, but your adapter does not: the client must reinstall it and reset its command revisions after every reload or restart. grpc.lua and grpc-hook.lua show that lifecycle.

2. Eval plus a resident adapter

For a closed, version-locked research prototype, this is a reasonable interim solution.

The request is just a Lua string and the response a JSON string in custom.proto. Return only plain, JSON-compatible values.

DCS-gRPC defines no project specific message size contract only ordinary Tonic/gRPC limits apply. Your record intent batch should be far below them. The practical limit is instead how much Lua and Controller work is performed synchronously on the simulation thread.

Normal MSE sanitization remains in effect: os, io, lfs, dynamic loading, and related facilities are removed in the MSE (Unless you desanitize your MissionScripting.lua). Controller and mission APIs remain available.

3. Retasking every 1–2 seconds

Evaluate the policy every second, but do not call setTask every second simply because a new sample arrived. This is probably the most dubious thing in your list of questions. The DCS AI is a majestic black box with questionable training and motives. Aircraft AI don't respond to commands sometimes, in relatively benign and normal scenarios, and thrashing them with commands can lead to quite unpredictable results that might even differ from aircraft model to model, or depending on what tasking is loaded, or a variety of other initial conditions that are hard to account for.

I just wouldn't consider this part of the experiment at all. Typically speaking I do not like interfering with AI at all when its engaged in a 'terminal' behavior or you risk getting unexpected results.

4. One aircraft per group

One-aircraft groups are not strictly required. Aircraft units can have individual Controllers, unlike ground and naval units where control is only group-oriented. However, groups of aircraft will engage in tactics that might be unpredictable and hard to account for. I would lead with the recommendation of 1 aircraft per group.

5. Expected scale

The proposed load is modest. One gRPC channel is fine. dcs-gRPC will limit to 600 MSE calls per second, I would try to aim for a load of under 200, or even less, to guarantee no stuttering or issues.

The likely bottlenecks are DCS AI sensing/weapon simulation and AI/Controller task churn, not protobuf or network framing. I will say, people have a tendency in DCS to do a variety of n * m comparisons, where each comparison requires multiple calls to the MSE API. Avoid that if you care about performance, things snowball very quickly in DCS.

6. Dedicated Server and human clients

There is no documented incompatibility with connected human clients. DCS-gRPC explicitly supports Dedicated Server installation and having humans connected is definitely a requirement of DCS-gRPC to be useful to the community.

The required MissionScripting.lua modification is server-side and does not require clients to install modified scripts. DCS updates overwrite that file, so deployment automation should reapply and verify the line after every update.

7. Three-sided engagement

Neutral groups are visible and controllable from mission Lua, and DCS-gRPC’s unit enumeration includes Blue, Red, and Neutral. The coalition API exposes all three.

However, Neutral is not a third mutually hostile coalition. DCS’s native AI hostility, IFF, detection, datalink, threat reaction, and coalition scoring fundamentally model Red versus Blue, with Neutral outside that hostility relationship.

Explicit same-coalition AttackUnit or AttackGroup tasks have been demonstrated in DCS: for example this red-on-red test, but this is undocumented behavior that works only in some cases and, as far as I know, not officially supported by ED. I have generally had good enough luck getting same coalition aircraft to engage, but have seen weird behavior at times (especially if an opposite coaltion entity is in play)

Therefore:

• A true three-way mutually hostile engagement is not natively supported.
• Pairwise target assignment may be emulated with explicit tasks on a pinned build.

8. Combat events

SHOT, HIT, KILL, and UNIT_LOST are suitable as the primary low-latency telemetry feed, but not as the sole authoritative scoring ledger.

Known complications include:

• S_EVENT_SHOT does not represent machine-gun or autocannon fire; those use shooting-start/end events.
• HIT can contain missing initiator or weapon data in multiplayer/timing edge cases.
• KILL, UNIT_LOST, DEAD, and CRASH overlap and can arrive at different physical stages of a loss.
• Streams have no cursor or replay natively.
• DCS-gRPC’s StreamUnits implementation has a “gone” fallback partly because death events are not always observed.
• The underlying event channel is bounded and can drop events under severe backpressure.

The June 2026 DCS changelog still described a “potential fix” for missing HIT/KILL events during kill trades, which is good evidence that exactly-once assumptions remain unsafe. See DCS 2.9.27.24969.

9. Mission loading and reloads

loadMission and reloadCurrentMission are thin wrappers around net.load_mission. Their completion does not mean that the replacement mission is ready; the public response contains no readiness or detailed success result.

Expect current streams to terminate with EOF or an unavailable transport. You should reconnect with a backoff. Clients should remain connected during a mission load.

10. Versioning and contribution

There is no maintained public DCS-to-DCS-gRPC compatibility matrix from which to name an authoritative “best known-good” pair. As far as I know dcs-grpc is completely compatible with the current version of DCS unless it's something mentioned in Issues, which might also be the case for an older game version.

Contributions are generally welcome. Literal typed Controller RPCs whose semantics match DCS setTask, pushTask, and setOption would be more appreciated than a separate higher-level ApplyAircraftIntents RPC with desired-state, diffing, hysteresis, and batching semantics. I could see a use case but I don't think it really fits into dcs-gRPC's ethos.

Opening a design issue before implementation would let us settle whether we prefer ED API parity, the higher-level intent service, or both and what adding them might impact in the project. A reproducible benchmark mission and demonstration of the intent service might be most useful in that.