Optional Client Mods Guide

Optional Client Mods Guide

Source anchors: docs/design/OPTIONAL-CLIENT-MODS.md, docs/design/ARCHIVE-MINING.md, server-config/server-pr8.cfg, and current Build84 source at origin/claude/build84-cmdcon36@5fca3239069a5eff6335f06fecb26bb72e8c9ceb. Wiki-only lane 317; no mission source, server config, package artifact, deploy, or live server state changed.

This guide is the player-facing route for optional client-side Arma 2 OA mods in WASP. It explains what the current PR8 test server allows today, which player-side mods are safe candidates, and which mod categories stay out because they affect simulation or require server/headless-client loading.

Current Server Policy

The current server config is permissive:

Setting	Current value	Player effect
verifySignatures	0	The server does not enforce addon signatures.
equalModRequired	absent	A player's -mod list does not have to match the server's -mod list.
BattlEye	0	BattlEye is off on the PR8 config.

The practical verdict is simple: today, a player can join with extra client-side mods loaded. That includes signed and unsigned addons. No server config change is required just to allow optional sound, visual, or HUD mods.

That permissive policy is not the same thing as "every mod is safe." A mod can still break the player locally, desync content, or change gameplay. Use the scope rules below.

Safe Scope

In scope:

• Sound replacement that runs locally, such as JSRS 1.5.
• Visual effects that do not change ammo, damage, ballistics, vehicle stats, or networked state, such as Blastcore or JTD FireAndSmoke.
• HUD/UI overlays that read local state, such as ShackTac Fireteam HUD / STGI.
• Client FPS/visual-reduction candidates after archive-id and safety verification, such as PROPER foliage/shader reduction from the archive-mining notes.

Out of scope:

• Weapon, vehicle, ammo, armour, ballistics, movement, fatigue, stamina, or realism packs.
• AI-behaviour addons as optional client mods. ASR AI, Zeus AI, GL4, bCombat, SLX and similar belong to server/HC evaluation, not a player-only pack.
• ACE/ACEX or other total-conversion stacks.
• Anything that adds required mission classes or assumes every client and the server load the same addon.

If a mod changes how the battle simulates, it is not optional-player-side. It needs a separate server-side lane and explicit testing.

Starter Pack Candidates

Candidate	Role	Current guidance
@CBA_CO	Dependency	Already part of the WASP server stack and the dependency for STHUD and Blastcore. Load it first in a client -mod line.
@JSRS1.5	Sound	Client-side sound replacement. The design notes mark JSRS as a safe sound candidate and the mission's current mod-detect helper recognises JSRS patch classes.
@Blastcore_Visuals_R1.2	Visual FX	Client visual effects. Safe in principle, but players on weak PCs should use low-FX settings because particle-heavy moments can cost FPS.
ShackTac Fireteam HUD / STGI	HUD/UI	Local HUD/group indicator. CBA dependency. The design source notes Alt-Shift-H as the STHUD toggle.
JTD FireAndSmoke 0.3	Visual FX	Optional tracer/smoke/fire visual layer. JTD_FireAndSmoke is the directly confirmed bIdentify id 1935 candidate; partly overlaps with Blastcore.

The prompt snapshot also named SOS, Name Tags, no-blur and GDT-style client tools. Those names are not promoted as confirmed pack contents here because the current Build84 ground-truth design page does not list exact archive ids and safety notes for them. Treat them as future candidates until a source pass records the archive filename/id, whether they ship signatures, and whether they are truly client-local.

Name tags specifically are already a mission feature in current Build84 source (WFBE_NameTagsEnabled in the client GUI/init path), so do not add a third-party nametag mod just to solve visibility unless a separate source-backed lane proves it is harmless and useful.

Player Install Model

The recommended future packaging model is a small @wasp_optional pack:

-mod=@CBA_CO;@wasp_optional

That pack should be distributed like the event packs: locked zip, manifest.json, SHA-256/size/source per PBO, and a player verifier script. Until that pack exists, the page is guidance rather than a download link.

No player should have to edit the server config. No player should need a drive password for the confirmed bIdentify candidates.

If Signatures Are Tightened Later

If Ray later wants anti-cheat tightening, keep this invariant: equalModRequired must stay off. Turning it on would defeat optional mods by requiring each player to match the server's mod list.

For signature enforcement:

• Put accepted optional mods' .bikey files in the server Keys path.
• Reinstall the WASP/Miksuu mod keys too, because current server-side mods ship signatures whose publisher keys are not present in the live key set.
• Consider a dedicated wasp_optional signing key if WASP re-signs a curated pack.
• Choose verifySignatures = 1 or 2 deliberately. The design notes warn that some era mods have old signature formats, so v1 may be more practical than v2 for classic Arma 2 OA addons.
• Treat any server config edit, key install, or service restart as Ray-approved ops work, not a player-guide task.

Smoke Test Checklist

For the first real optional-pack test:

Test	Pass condition
Client with pack joins	No kick, no missing-addon dialog, no client RPT spam.
Client without pack joins	Same mission works and no required-addon error appears.
STHUD/STGI	HUD toggles locally and no other player needs it.
JSRS	Sound changes for the player running it only.
Blastcore/JTD	Visual effects render locally; weak-client FPS remains acceptable.
Server RPT	No addon enforcement or missing-key churn.

Continue Reading

• New player quickstart - first-match basics.
• Client UI systems atlas - HUD/menu owners.
• Server runtime and operations - server config and ops routing.
• AI, headless and performance - server/HC AI and performance routes.