External Integrations

External Integrations

This page maps the Discord bot, C# extension, AntiStack database extension, BattlEye filter and public server metadata. For the security-first view across these boundaries, use Integration trust boundary audit; it separates the DiscordBot JSON reader risk from the in-repo extension writer and the out-of-repo AntiStack DLL.

Discord Bot

DiscordBot is a .NET 9 executable using:

• Discord.Net 3.10.0
• Newtonsoft.Json 13.0.2
• Pastel 4.0.2

The bot registers /setup and /cleanup, tracks a configured game-status channel/message, updates channel name and bot presence every 60 seconds, and reads database.json from a data source path. GameData maps exported mission stats to terrain/player-count display strings.

Required local files are intentionally absent from the repo:

• DiscordBot/preferences.json
• DiscordBot/token.txt

preferences_sample.json points DataSourcePath at C:\a2waspwarfare\Data. Runtime refuses to continue if token.txt is missing or empty, so do not treat a local bot run failure as a mission-code failure until those files are supplied.

Important startup nuance from the 2026-06-04 integration scout: ProgramRuntime.cs:14-21 loads GameData before it checks token.txt. GameData.LoadFromFile() reads Preferences.Instance.DataSourcePath first (GameData.cs:32-37), and Preferences.Instance unguardedly reads and deserializes preferences.json (Preferences.cs:24-25) with a nullable return suppressed at Preferences.cs:28-30. A missing database.json falls back to default game data, but a missing or malformed preferences.json can fail earlier than the clean missing-token exit. Runtime code later assumes a non-null preferences instance in command and status paths (GameStatusUpdater.cs:60-61, CommandHandler.cs:49,127), so operators should provide a valid preferences.json before interpreting bot startup failures.

Discord Config Hygiene

Claude Round 16 verified that DiscordBot/preferences_sample.json currently includes concrete sample IDs (GuildID, AuthorizedUserIDs) plus the production-style DataSourcePath. DiscordBot/FileConfiguration.cs also has DataSourcePath/botconfig.json support, but the active status-data reader bypasses it: DiscordBot/src/ExtensionData/GameData/GameData.cs resolves Preferences.Instance.DataSourcePath ?? C:\a2waspwarfare\Data. Static usage review found only FileConfiguration.LogsPath used by the live logging path, not by the live game-status JSON reader. Deployment should choose one source of truth for the data path; until then, prefer preferences.json for the live bot and treat botconfig.json as a dormant helper, not the current status-reader configuration source.

No token is committed, which is good. .logs/, token.txt and preferences.json are ignored, but botconfig.json is not currently ignored; keep live secrets, IDs and host paths out of that helper unless config ownership is cleaned up. Still, treat the sample identifiers and hardcoded path as governance cleanup:

• replace real-looking sample IDs with obvious placeholders;
• prefer one config-loading path instead of multiple fallbacks;
• document whether botconfig.json, preferences.json or environment variables are the intended deployment source, then remove or clearly demote the unused path;
• keep token.txt and any live Discord IDs out of committed files.

Discord Runtime Footguns

The bot currently blocks forever through await Task.Delay(-1) in ProgramRuntime.cs:59-60, without an explicit cancellation/shutdown path in that method. That is acceptable for a simple long-running process, but process managers should stop it externally and future code should add a real cancellation token before expecting graceful shutdown.

Deployment also depends on Discord application permissions beyond the local files. DiscordBot/src/BotReference.cs:51-59 configures the client with GatewayIntents.All, so a real bot needs the matching Discord privileged intents enabled on the application. Treat missing gateway intents as an environment/deployment failure until proven otherwise; it is not an Arma mission runtime bug.

The /cleanup command uses a heuristic over the last 50 channel messages and deletes bot-authored embeds whose title contains Chernarus/Takistan or whose description contains Score: (CommandHandler.cs:138-148). That can over-delete older or related bot status embeds if the channel is shared. Prefer a stored status-message id or a narrower marker before relying on /cleanup in mixed channels.

Discord Data Path Risk

Claude DR-31 completed the consumer-side review of the extension data path. The bot polls database.json on a 60-second timer, at startup and from a command path. Secret hygiene is good (token.txt and preferences.json are ignored, and commands are auth-gated), but DiscordBot/src/ExtensionData/GameData/GameData.cs deserializes that JSON with Newtonsoft TypeNameHandling.All.

That setting is unnecessary for the flat GameData DTO and creates a local-write-gated RCE sink in the token-holding bot process if anything can write to C:\a2waspwarfare\Data\database.json. Fix direction: use TypeNameHandling.None for the active reader and remove or make private/safe the still-callable .Auto helper in DiscordBot/src/ExtensionData/GameData/GameDataDeSerialization.cs:31-36.

Do not conflate this with the in-repo extension writer: Extension/src/SerializationManager.cs writes the live database JSON with TypeNameHandling.None. The active TypeNameHandling.All sink is the DiscordBot reader, while the in-repo extension's Auto deserialization path is dead/commented scaffolding unless a future persistence load path revives it.

Arma Extension: a2waspwarfare_Extension

Extension is a legacy .NET Framework 4.8 x86 Arma 2 OA extension using RGiesecke.DllExport/UnmanagedExports and Newtonsoft.Json. It is not an SDK-style dotnet build target. Build it with Visual Studio/MSBuild after restoring the old ../packages NuGet layout, and preserve x86 for Arma 2 OA extension loading. It exports _RVExtension@12, parses comma-separated arguments, resolves an extension class by enum name, and currently includes GLOBALGAMESTATS.

Parser caveat: ExtensionMethods.cs:18-21 indexes splitArgsArray[0] immediately after splitting the callExtension string. Empty or malformed argument strings can therefore fail before a clean error response is produced. Treat the callExtension contract as "class name first, then fields" until the parser validates length and returns a structured error.

Mission bridge:

• Server/CallExtensions/GlobalGameStats.sqf
• calls "a2waspwarfare_Extension" callExtension format ["%1,%2,%3,%4,%5,%6", ...]
• sends class name, west score, east score, map, uptime and player count every 60 seconds.

The handoff is file-based, not an HTTP API:

flowchart LR
    Mission["Arma mission GlobalGameStats.sqf"] --> Extension["a2waspwarfare_Extension callExtension"]
    Extension --> Json["C:\\a2waspwarfare\\Data\\database.json"]
    Json --> Bot["DiscordBot 60-second poll"]
    Bot --> Discord["Discord channel name, presence and status embed"]

Loading

The extension writes GameData.Instance to C:\a2waspwarfare\Data\database.json; DiscordBot reads the configured data-source path and updates Discord every 60 seconds.

database.json Contract Drift

The current file contract is not pinned in one code type. The mission sends class selector plus west score, east score, map, uptime and player count from Server/CallExtensions/GlobalGameStats.sqf:22. GLOBALGAMESTATS.cs:5-11 still labels uptime and player count as future fields, the in-repo extension DTO starts with exportedArgs = new string[2] in Extension/src/GameData.cs:29, and the DiscordBot reader allocates exportedArgs = new string[4] at DiscordBot/src/ExtensionData/GameData/GameData.cs:30.

The live DiscordBot display paths guard before reading player count at index 4 (GameData.cs:80-82, :111-114) and uptime at index 3 (:181-189), so short/default arrays mostly produce fallback/degraded status text rather than a separate mission failure. Future integration work should define the expected field count once, add normal/short/long/corrupt database.json fixtures, and keep extension writer plus DiscordBot reader in lockstep. Keep this contract work separate from the higher-priority TypeNameHandling hardening path above.

Shared Terrain Copy Caveat

DiscordBot carries terrain classes under ExtensionData/GameData/SharedWithLoadoutManager. Those classes include a copied WriteToFile() generator API (BaseTerrain.cs:9-32, InterfaceTerrain.cs:5-6), but static search found no bot caller; live bot code uses terrain metadata for display/player-cap formatting in GameData.cs:76-92, :108-124 and :147-156.

Actual mission write/propagation remains in Tools/LoadoutManager/Data/Terrains/BaseTerrain.cs and Tools/LoadoutManager/FileManagement/FileManager.cs. Treat the bot copy as stale shared/historical surface until a refactor splits display metadata from generator APIs or marks the write API unavailable to DiscordBot.

Discord Update Timeout Caveat

GameStatusUpdater.cs:91-106 creates a CancellationTokenSource around both the Discord channel-name update and bot-presence update. The channel rename passes RequestOptions { CancelToken = cts.Token } to ModifyAsync, but client.SetGameAsync(newChannelName, null, ActivityType.Playing) does not receive the token. The /setup command has the same direct presence-update shape at CommandHandler.cs:70-75. Treat bot presence updates as still uncapped until both timer and command paths have a real timeout/fallback.

Implementation notes from the source:

• Extension/src/ExtensionMethods.cs exports _RVExtension@12 through RGiesecke.DllExport.
• Extension/src/BaseExtensionClass/ExtensionName.cs only enumerates GLOBALGAMESTATS in the in-repo extension.
• Extension/src/SerializationManager.cs writes database.json through a temp file and File.Replace.
• SerializeDB() is async void, so extension write failures can become log-only/asynchronous failures rather than mission-visible errors.

Claude DR-29 sharpened this boundary: the in-repo GLOBALGAMESTATS extension is not an SQF RCE path today because GlobalGameStats.sqf discards the callExtension return, the extension does not write _output, and the active writer serializes with TypeNameHandling.None. It still has code-owner risks: a commented/load-path deserialization landmine using Newtonsoft TypeNameHandling.Auto, an async void create/write race around File.Replace, stale write-only persistence scaffolding, and a player-count heuristic in GlobalGameStats.sqf that subtracts the live HC count (read from WFBE_HEADLESSCLIENTS_ID registry, floored at 0) from the raw isPlayer count. This handles variable HC counts correctly but can still misreport in transient over-subtract conditions or when the registry is not yet populated.

AntiStack Database Extension

Deep page: AntiStack database extension audit owns the current runtime map, ON/OFF guards, wrapper procedure table, remaining call compile return-shape risks and validation pack.

Server AntiStack scripts call "A2WaspDatabase" callExtension for player/team score storage and map selection. Key scripts:

• callDatabaseRetrieve.sqf
• callDatabaseStore.sqf
• callDatabaseStoreSide.sqf
• callDatabaseSendPlayerList.sqf
• callDatabaseRequestSideTotalSkill.sqf
• callDatabaseFlushPlayerList.sqf
• callDatabaseSetMap.sqf

This is live-server sensitive because extension/database latency can affect monitoring loops and team-balance decisions.

Procedure and retry contract lives in the AntiStack audit: current wrapper codes are 101, 202, 303, 404, 505, 606, 707, 808 and 909; score retrieval polls up to 120 attempts with _sleep = 0.10, while side-skill requests poll up to 9 attempts with _sleep = 3. Any operator smoke or rewrite should preserve/replace those timing assumptions deliberately.

Claude DR-7 through DR-10 found that all seven AntiStack DB wrappers call compile the A2WaspDatabase extension return. The A2WaspDatabase DLL is not in this repo, and WFBE_C_ANTISTACK_ENABLED defaults on in mission constants. In Arma 2 OA there is no parseSimpleArray, so hardening has to guard and shape-check the compiled value before reading it, plus add a circuit breaker for missing/slow extension responses.

Important distinction: the in-repo Extension project implements a2waspwarfare_Extension / GLOBALGAMESTATS; AntiStack uses a separate out-of-repo A2WaspDatabase extension. Current source also has a controlled AntiStack ON/OFF parameter and disabled-mode loop guards, but enabled mode still needs extension return-shape hardening; see AntiStack database extension audit.

BattlEye Filter

Page ownership: this section is the canonical shipped BattlEye/server-filter posture. Other pages should link here instead of restating the kickAFK/missing-filter evidence.

BattlEyeFilter/publicvariable.txt contains the public-variable rule used for AFK kick behavior. Client updateclient.sqf intentionally broadcasts kickAFK; BattlEye detects it and kicks because direct serverCommand paths are unavailable/disabled.

Shipped evidence	Developer meaning
BattlEyeFilter/publicvariable.txt contains only //new and 5 "kickAFK".	This is feature plumbing for AFK kick, not a comprehensive publicVariable hardening layer.
No in-tree scripts.txt, server.cfg, basic.cfg or broader BattlEye filter bundle is present.	The repo cannot claim shipped public-server BattlEye hardening; production BEpath files remain an owner/deployment question.
updateclient.sqf:153-162 explicitly tells hosts to place publicVariable.txt beside server.cfg and broadcasts kickAFK.	BattlEye filtering is a contingent local-server filter layer: if production loads BE filters, they can act as defense in depth; if it does not, server-side authority remains the durable fix.
PVF registered commands and direct mission PV channels both exist.	Filter design must include WFBE_PVF_* plus direct channels, and still does not replace server-side authority checks.

Claude DR-30 closed the remediation loop: as shipped in this repo, the "rely on BattlEye" option is not implemented. No scripts.txt, server.cfg, basic.cfg or broader BattlEye filter bundle is present in the tree. Production servers may have external BEpath files, but that is an owner/deployment question, not documented source truth.

Arma 2 OA filter guidance should name the OA-era files that matter here: publicvariable.txt for PV/PVEH channels, scripts.txt for script-command injection/client locality abuse, and command-specific filters such as createvehicle.txt, setvariable.txt, setpos.txt, setdamage.txt, deletevehicle.txt, mpeventhandler.txt, cargo filters, teamswitch.txt, waypointcondition.txt, selectplayer.txt and attachto.txt. Do not list remoteexec.txt as a missing Arma 2 OA filter; remoteExec / remoteExecCall are Arma 3 commands.

Filter design should be driven by Networking and public variables, Public variable channel index and Server authority migration map. A PV filter alone still will not solve client-side createVehicle/createUnit authority; that class needs BattlEye scripts.txt or a server-authoritative redesign.

License And CI Posture

Claude Round 16 resolved the external reports' license uncertainty: LICENSE.md is a custom/proprietary/source-available license, not an OSI open-source license. Treat redistribution/reuse as restricted unless the repo owner explicitly grants it.

The docs branch now has docs-only CI in .github/workflows/docs.yml: Windows wiki validation plus an Ubuntu MkDocs strict build. Treat that as documentation validation, not release CI. Useful additional checks for this project would be:

• .NET builds for Tools/LoadoutManager, DiscordBot and Extension where the platform/toolchain is available;
• generated-mission drift checks after LoadoutManager runs;
• SQF/string reference checks for preprocessFileLineNumbers, execVM, ExecFSM and dialog onLoad paths;
• wiki machine-file validation for agent-context.json, agent-status.json, agent-collaboration.json and agent-events.jsonl.

Public Server Metadata

The repo README lists:

• IP: 144.76.185.231
• Port: 2302
• Server name: Miksuu's Warfare | CTI TvT PvE | discord.me/warfare
• BattleMetrics and GameTracker links
• Trello board link

For deployment inventory and the distinction between committed artifacts and operator-supplied server files, start with Server ops runbook.

Continue Reading

Previous: Tools/build | Next: Integration trust boundary audit

Main map: Home | Fast path: Quickstart | Agent file: agent-context.json