STW Combat Support API

What the API provides

STW Combat Support API gives compatible mods one common language for discovering support providers, listing eligible support units, submitting requests, tracking orders and cancelling them. It does not spawn or control vehicles itself. A provider owns its units, validation, dispatch behaviour and state; requester mods use the shared contract instead of coupling directly to a specific provider.

Built-in capability flags

Capabilities are bit flags. Providers can advertise more than one by combining the relevant values.

Registering a provider

Create a class derived from STW_CombatSupportProvider, implement its contract, and register one instance on server setup. Every provider must expose a stable, unique non-empty provider ID.

class MySupportProvider : STW_CombatSupportProvider
{
    override string GetProviderID() { return "my-support-provider"; }
    override int GetSupportedCapabilities() { return STW_ECombatSupportCapability.CAS; }
    // Override GetSupportUnits, SubmitRequest, CancelOrder and GetOrder.
}

STW_CombatSupportRegistry.RegisterProvider(new MySupportProvider());

RegisterProvider returns false if an existing provider already uses the same ID. Remove providers during teardown with UnregisterProvider(providerID). Reset() clears the complete in-process registry and is best reserved for controlled lifecycle or test cleanup.

Discovery

Use FindProvider(providerID) for a known provider, or GetProvidersForCapability(capability, output) to collect every provider supporting the requested capability mask.

Requests, units and orders

A requester creates STW_CombatSupportRequest and supplies its own request ID. The contract deliberately uses player IDs, group IDs, faction keys and positions rather than entities owned by a specific addon.

Call GetSupportUnits(request, output) for provider-owned STW_CombatSupportUnit records. Each identifies its provider and unit, position and distance, and can explain ineligibility with unavailableReason.

Submit a validated request with SubmitRequest(request). The returned STW_CombatSupportOrder carries the order/request/provider/unit IDs, result, state, detail, target and search radius. Query it later with GetOrder(orderID).

Order states and results

Orders progress through PENDING, ASSIGNED, EN_ROUTE, ON_STATION, ENGAGING, then COMPLETED, CANCELLED or FAILED. Results include ACCEPTED, NO_PROVIDER, NO_ELIGIBLE_UNIT, OUT_OF_RANGE, UNAUTHORIZED and NOT_CANCELLABLE.

Shared Combat Support map wheel

Provider or requester mods can add commands to one neutral Combat Support category in the map radial menu. Register each entry during commanding-manager setup:

STW_CombatSupportMapWheelService.RegisterEntry(
+    "my-support-command",
+    "Request Support",
+    "{YOUR_ICON_RESOURCE}",
+    "{OPTIONAL_CATEGORY_ICON_RESOURCE}"
+);

The identifier must be non-empty and unique; duplicate identifiers are ignored. The API creates the category only when at least one entry is registered, avoids adding it twice, and uses the first entry’s category icon when supplied. Commands are inserted when the map menu initializes.

Integration checklist

1. Load STW Combat Support API as a dependency of the integrating mod.
2. Register server-owned providers after their backing systems are ready.
3. Use stable provider, unit, request and order IDs; never expose addon-specific entity references through shared request types.
4. Validate faction, requester identity, range, unit availability and order state on the server.
5. Return meaningful result codes and details so callers can present useful feedback.
6. Unregister providers during orderly shutdown and register map-wheel commands only once.

The API is intentionally neutral: it coordinates several support mods while each retains its own gameplay rules, assets and optional dependencies.