-
Notifications
You must be signed in to change notification settings - Fork 0
Miksuu Wiki Archive LoadoutManager
Imported from
Miksuu/a2waspwarfare.wikiat commit45ef3da(45ef3da367d65e6487de488bbe3b16a8a8b21ba3) on2026-06-03. Original file:LoadoutManager.md. This page preserves upstream community/developer documentation as historical provenance. It is not the current canonical source of truth for implementation details.
Current routing: Community & Dev | Miksuu upstream wiki import
Archive category: tool-history
Archive chain. This imported upstream page is historical provenance, not current implementation truth.
Previous: Miksuu Wiki Archive: Development Process | Next: Miksuu Wiki Archive: Chernarus Mission Script Architecture
Related: Community & Dev | Tools and build workflow | Gear/loadout/EASA atlas | Source fix propagation queue
Author: Miksuu
LoadoutManager is a C# program (created by Miksuu) designed for managing various vehicle loadouts. It manages generating code for Arma 2’s SQF language for the essential files: Common_BalanceInit.sqf & EASA_Init.sqf
Additionally the program brings these changes (and any other code change excluding mission.sqm, and version.sqf files) to our modded terrains which we currently run during biweekly events that are held on weekends.
Before we started working on the The Air Balance Patch, we noticed that editing the aircraft loadouts manually to the SQF code could have become a bit tedious. To alleviate this, we developed the LoadoutManager tool. Now, providing that the weapon/ammunition type/vehicle is defined into the program, editing the loadouts became multiple times faster. Later on, I made change to the program that it automatically takes data from Chernarus and Takistan and updates every terrain that is defined in the code as its own class. This way, every time the program is run, those terrains are kept up to date too. This lightens the developer's workload, as only the Forest and Desert terrains need to be edited. Later, I will create functionality to reduce that to one terrain as we could refactor the mission structure a bit.
SqfFileGenerator.cs is a C# utility class central to the LoadoutManager program. It specializes in generating SQF (Status Quo Script) files that are tailored to specific loadout configurations. The class serves as a vital link between the program's data models and the SQF files used in the game. One of the key methods inside the class is GenerateAircraftSpecificLoadouts(), that invokes a method: GenerateLoadoutsForTheAircraft() from the BaseAircraft.cs class. This method plays a significant role in generating aircraft-specific loadouts and leans heavily on other classes like BaseWeapon.cs and BaseAmmunition.cs to manage various types of ammunition. The class processes this data to generate the SQF files' content, providing a seamless transition from the program's internal logic to the external SQF files. By doing so, the class ensures that the generated files are compliant with the specific loadout requirements that are setup properly to create a balanced game environment. Beyond generating content, SqfFileGenerator.cs has methods for writing these configurations to files. This makes it easier to integrate them into different modded terrains. The class contains properties that store the text content for these SQF files, which can then be written to disk.
- Data Retrieval: The class first collects all the necessary data, such as vehicle attributes and weapon configurations, from its internal data structures.
- Data Processing: It then processes this data to determine the valid loadouts and other game mechanics, taking into account the factory levels and other conditions.
- SQF Content Creation: The processed data is then used to generate the content for Common_BalanceInit.sqf and EASA_Init.sqf
- File Writing: Finally, the generated SQF content is written to disk, updating the files with the new configurations.
The BaseVehicle.cs class is an abstract base class that encapsulates core functionalities and attributes applicable to all vehicle types in the game. It standardizes common properties like vehicle type, in-game display name, factory level, and production factory type through the implementation of the InterfaceVehicle interface. In addition, this class manages various weapon configurations and loadouts, including conditional weapon removal based on factory level. The BaseVehicle.cs class plays a vital role in generating the Common_BalanceInit.sqf file. It holds data structures that represent the various types of vehicles and their attributes. These data structures are then processed to create the content for the SQF file, which influences the balance of the game and overall mechanics. The class includes data structures for managing various attributes and functionalities of vehicles, such as:
- Weapon Configurations: It holds information on the various weapon types that can be equipped on each vehicle.
- Loadouts: Manages the specific combinations of weapons and equipment that can be assigned to vehicles.
- Factory Conditions: Includes logic for conditional weapon removal based on factory levels, affecting what can be produced in the game.
The PANDUR.cs class is a concrete implementation that extends from the BaseGroundVehicle class. It specializes in defining the attributes and configurations specific to the Pandur vehicle in the game.
public class PANDUR : BaseGroundVehicle
{
public PANDUR()
{
VehicleType = VehicleType.PANDUR;
inGameDisplayName = "Pandur";
base.vanillaGameDefaultLoadoutOnTurret.AmmunitionTypesWithCount = new Dictionary<AmmunitionType, int>
{
{ AmmunitionType.ATK44HE, 2},
{ AmmunitionType.ATK44AP, 2},
};
base.defaultLoadoutOnTurret.AmmunitionTypesWithCount = new Dictionary<AmmunitionType, int>
{
{ AmmunitionType.TWOHUNDREDTENROUND25MMM242APDS, 2},
{ AmmunitionType.TWOHUNDREDTENROUND25MMM242HEI, 2},
};
turretPos = 0;
inGameFactoryLevel = 3;
producedFromFactoryType = FactoryType.LIGHTFACTORY;
weaponsOnTheTurretToRemoveUntilFactoryLevelOnAVehicle = new Dictionary<WeaponType, int>
{
{WeaponType.SPIKELAUNCHER, 4},
};
}
}Here are some of the key properties set within the PANDUR.cs class:
VehicleType: This is set to VehicleType.PANDUR, specifying the type of the vehicle.
inGameDisplayName: The in-game display name for this vehicle is set to "Pandur". Right now, this is only used for displaying the comment that is generated for the SQF code.
vanillaGameDefaultLoadoutOnTurret.AmmunitionTypesWithCount: This Dictionary defines the default loadout that the game uses. Weapons that are not modified, can be left empty, since this will only affect the Common_BalanceInit.sqf (what weapons the vehicle will have on the start). The weapons to define here should be verified using the game files.
defaultLoadoutOnTurret.AmmunitionTypesWithCount: Through an algorithm, this will be compared to the vanillaGameDefaultLoadoutOnTurret to decide the final weapon loadout for the vehicle upon its spawn. In this case, we replaced the ATK44 cannon with the M242 cannon. This change was made to improve the vehicle's fire rate and increase its ammunition, thus making it more viable.
turretPos: Can be checked from the game files. Is not needed when defining ammunition to not be on the turret itself.
inGameFactoryLevel: Currently only have function for commenting purposes, in the future we might add automatic unit generation for SQF code and sorting them according to their price and factory level more properly.
weaponsOnTheTurretToRemoveUntilFactoryLevelOnAVehicle: Will be used for Common_BalanceInit.sqf to remove certain weapons on the vehicle. Define weapon name and it's level for it to be available here for the Dictionary. Multiple weapons are not supported at the moment (and probably not needed at least yet), functionality for this may be added later.
Here's an example output of that variable config:
// Pandur [LF3]
case "Pandur2_ACR": {
_this removeMagazineTurret ["140Rnd_30mm_ATKMK44_HE_ACR", [0]];
_this removeMagazineTurret ["60Rnd_30mm_ATKMK44_AP_ACR", [0]];
_this removeWeaponTurret ["ATKMK44_ACR", [0]];
_this addMagazineTurret ["210Rnd_25mm_M242_APDS", [0]];
_this addMagazineTurret ["210Rnd_25mm_M242_HEI", [0]];
_this addWeaponTurret ["M242", [0]];
_currentFactoryLevel = ((side group player) Call WFBE_CO_FNC_GetSideUpgrades) select WFBE_UP_LIGHT;
if (_currentFactoryLevel < 4) then {
_this removeWeaponTurret ["SpikeLauncher_ACR", [0]];
};
};producedFromFactoryType: If you are using the weaponsOnTheTurretToRemoveUntilFactoryLevelOnAVehicle Dictionary which is documented above, this is important, asides from the usage in the comments that are generated. It defines in what factory the vehicle is produced, so the in the code, for example WFBE_UP_LIGHT or WFBE_UP_HEAVY can be defined to restrict certain weapons under a specific factory updgrade level. In the future we might add code generation features to make this unit a certain level, and add variables like pricing too (right now hardcoded in to SQF codebase configs).
In the LoadoutManager program, loadouts for aircraft are primarily generated using the BaseAircraft.cs class. This class is an abstract foundation for all types of aircraft and is derived from the BaseVehicle.cs class. It also implements the InterfaceAircraft, encapsulating common behaviors, properties, and methods that are shared across different types of aircraft. The class also contains functionalities for calculating weapon counts and managing ammunition types among other features. It accepts various parameters, such as the type of aircraft and ammunition, to generate tailored loadouts. The method processes these inputs to produce a loadout that can then be written into an SQF file by the SqfFileGenerator.cs class.
public class SU39 : BaseAircraft
{
public SU39()
{
pylonAmount = 10;
allowedAmmunitionTypesWithTheirLimitationAmount = new Dictionary<AmmunitionType, int>
{
{ AmmunitionType.SIXROUNDFAB250, 0 },
{ AmmunitionType.FOURTYROUNDS8, 0 },
{ AmmunitionType.TWELVEROUNDSVIKHR, 4 }, // Vikhrs and Hellfires are automatically multiplied by two
{ AmmunitionType.BASECH29, 0 },
{ AmmunitionType.TWOROUNDGBU12, 8 },
{ AmmunitionType.TWOROUNDR73, 4 },
};
}
}(Note: BaseVehicle components have been omitted for brevity as they have already been provided in the chapter above)
For EASA loadouts configuration, data in the allowedAmmunitionTypesWithTheirLimitationAmount Dictionary. The program automatically calculates all possible loadout combinations for a given aircraft based on this data. Note that 12 Vikhrs and 8 Hellfires will always take four pylons. Additionally, some weapons can fit multiple units into a single pylon. For example, one pylon can hold 3 FAB250/MK82 bombs or 20 S8 rockets. The price of each loadout is calculated on a cost-per-pylon basis, and each magazine type has its own price. Each new weapon currently adds +1000$ to the cost (this may be changed later per weapon). List of these costs can be found at the Implementations folder of the Data of the Ammunition folder structure.
Here's an example how one of the loadouts,
[14400,'FAB-250 (6) | S-8 (40) | Kh-29 (4) | R-73 (2)',[['AirBombLauncher','S8Launcher','Ch29Launcher_Su34','R73Launcher_2'],['4Rnd_FAB_250','2Rnd_FAB_250','40Rnd_S8T','4Rnd_Ch29','2Rnd_R73']]],
is calculated:
6 FAB250s, 40 S8s, 2 R73's take two pylons each, and four Kh-29's take one each per missile. The per-pylon costs are [300, 3000, 600, 700], resulting in a total cost of 10 400. However, as mentioned before each of the new weapon types, such as AirBombLauncher for the FAB250s, adds 1000$ to the price, thus with four weapon types giving us the final price of 14400$.
Helicopters (BaseHelicopter.cs, AH1Z.cs) have modifiers of prices for missiles like the AIM-9/R-73, which makes them more expensive for that type of aircraft. If the need arises to make such missiles less accessible on helicopters, this modifier could be increased.
The complete list of all the loadouts can be found here (updated always when a new version of the mission is deployed to the server).
This system allows for easy modification of these values in the program to generate new loadouts. With this system, editing these values and exporting them to the game is very easy.
Home | Agent Guide | Current live state | Release 1.2.2 (B91) | Quickstart | Progress | Lifecycle wait-chain | Join/disconnect | Parameters/build | Assets/config | SQF atlas | PV index | Modules | Support/specials | Commander/HQ | Commander vote/reassign | Construction/CoIn | Construction cleanup | WDDM compositions | Factory/purchase | Upgrades/research | Towns/camps/capture | Victory/endgame | Markers/cleanup | Server runtime | AI runtime/HC | AI commander audit | HC delegation | Town AI safety | Commander reassignment | Resistance supply | Player UI workflow | UI atlas | Respawn/death | Gear template filter | Vehicle cargo loop | Service guards | UI IDD repair | UI design inspiration | WASP overlay | Feature status | Source propagation | release readiness | Tooling readiness | Integration trust | AntiStack DB | Owner decisions | Shelved registry | Abandoned feature revival | Hardening roadmap | PVF dispatch | Server authority | ICBM authority | Attack-wave authority | Telemetry families | AICOM V2 cutover | Consumer port map | Testing workflow | Server ops | Web tools | Ecosystem repos | Arma 2 OA refs | A2 traps | OA compatibility audit | Coverage ledger | Navigation inventory | Pruning ledger | Knowledge roadmap | Agent context | Collab protocol | Worklog | Audit archive 2026-07 | Briefing reference | Utes invasion concept
- Shelved AICOM concepts - revivable someday ideas (owner-shelved 2026-07-03)
Docs rule: source-backed claims only; Arma 2 OA scripting docs only; gameplay edits start in Missions/[55-2hc]warfarev2_073v48co.chernarus.
- Getting started
- Status and coordination
- Agent context
- Agent collaboration protocol
- Agent worklog
- Agent worklog archive
- Progress dashboard
- PR cleanup and integration lab
- Shelved PR #169: gear price double-count
- Shelved PR #194: Chernarus no-trees
- Coordination board
- Codebase coverage ledger
- Bottleneck removal queue
- Current source status
- Wiki mirror reconciliation
- Navigation inventory
- Registers
- Agent orchestration
- Architecture
- Architecture overview
- Mission entrypoints and lifecycle
- Lifecycle wait chain
- Player join/disconnect and AntiStack lifecycle
- Mission parameters/localization/build inputs
- Stringtable localization key-family catalog
- Source inventory
- Content structure and maps
- Assets/config/localization/parameters
- Mission start parameters index
- Code and networking
- Gameplay systems
- Core systems index
- Gameplay systems atlas
- Commander/HQ lifecycle atlas
- Economy, towns and supply
- Economy system reference
- Balance asymmetries
- Anti-stack skill-balance mechanic
- Empty-side supply income stagnation
- Towns, camps and capture atlas
- Victory and endgame atlas
- Victory conditions reference
- Territorial victory reference
- Marker cleanup and restoration
- Marker loop engine and registries
- Map marker families content catalog
- Marker subsystem function reference
- Client marker FSM updater map
- Support specials and tactical modules
- SCUD TEL tactical munitions
- Naval HVT objectives (carriers/SCUD)
- SCUD saturation strike mechanic
- Takistan airfield FPV drone design
- Construction and CoIn systems
- Structure damage reduction & friendly-fire
- Construction logic list cleanup
- Flak tower & WDDM anchor compositions
- Resistance supply scaffold
- GUER Insurgents faction overview
- GUER Insurgents branch audit
- GUER insurgent player economy
- GUER Commissar Panel
- GUER air-defense loop (Ka-137/Mi-24)
- Upgrades and research atlas
- Supply mission architecture
- Supply mission authority cleanup
- Current supply helicopters PR1
- Respawn and death-loop lifecycle
- Vehicle theft economy pitch
- GUER tunnel network pitch
- Content, reference and catalogs
- Faction unit/vehicle roster catalog
- Auxiliary/SF/civilian unit catalog
- Gear store loadout route catalog
- Upgrade research (cross-faction)
- Gear store price and upgrade catalog
- Gear store catalog (complete, per faction)
- Defense structures catalog
- Artillery reference per faction
- AI squad team templates catalog
- Town AI lifecycle reference
- Town AI group composition catalog
- Class-skill system reference
- Player skill abilities reference
- Default gear template content catalog
- Chernarus map content reference
- Takistan map content reference
- Takistan features
- Takistan parity reference
- Takistan oilfields objective reference
- IRS IR-smoke countermeasure
- Arty module special munitions
- Zeta cargo sling-load reference
- Spawn primitive function reference
- Kill and score pipeline
- Waypoint helper function reference
- Position and proximity function reference
- Side/team state function reference
- Player AI watchdog and recovery
- AICOM stuck-recovery v2
- LoadoutManager data-model contributor guide
- Discord status bot setup and reference
- GLOBALGAMESTATS extension reference
- New player quickstart (player guide)
- Optional client mods (player guide)
- Earning funds and score (player guide)
- Vehicle service and logistics (player guide)
- Commander's handbook (player guide)
- Tactical support menu
- Paradrop player experience
- Supply missions (player guide)
- In-game briefing & Diary field manual
- Playable maps catalog
- Faction root variables reference
- Faction base structures catalog
- Counter-battery radar system
- Bank, Reserve and Artillery Radar structures
- Map ruleset model and object config
- Countermeasures module reference
- Vehicle countermeasure (flares/spoofing)
- UAV terminal and spotter system
- Artillery firing function reference
- Service Point pricing model
- Medic redeployment truck (forward spawn)
- Side-patrol runtime and convoy mechanics
- Day/night cycle and weather system
- Config lookup helper reference
- CIPHER sort utilities reference
- Modded maps status and content
- BattlEye filter setup and OA taxonomy
- Player squad/group join protocol
- AutoFlip vehicle recovery
- Engine stealth fuel toggle
- Valhalla vehicle climbing-assist
- Missile and ordnance Fired-EH reference
- Vehicle equip and rearm reference
- Array and collection utilities
- Server composition spawner reference
- Upgrade queue server loop
- Map boundaries and off-map enforcement
- Namespace/profile/diagnostic utilities
- Group bool getVariable A2-OA trap
- Vehicle weapon balance init
- View distance auto-throttle
- Camp & respawn-camp getters
- Performance audit writer
- Site clearance (bulldozer)
- Factory queue cancel & refund
- AI commander tunable constants
- Experimental feature-flag constants
- Flag system quick reference
- Mission tunable constants catalog
- Gear parsing & cargo capacity
- Structure dressing function
- Paradrop delivery functions
- ICBM nuke client VFX & radiation
- Server HandleSpecial router
- LocalizeMessage chat router
- Gear buy-menu render & price functions
- Server broadcast & telemetry loops
- Per-unit client init pipeline
- Vehicle marking & texture pipeline
- Defense category & budget
- Legacy AI order primitives
- Commander-team driver
- AICOM command verbs
- AICOM behavior fix taxonomy
- AI commander wildcard deck reference
- AICOM aircraft and airfield system
- Static-defense manning
- End-of-game stats screen
- AI commander execution loop
- Deployable bipod / weapon resting
- Town-economy getters
- Server-init deadspawn & airfield probe
- GUER VBIED detonate action
- Resource income-tick engine
- AI commander treasury accessors
- PVF send-helper contracts
- AICOM logging & AICOMSTAT telemetry
- AICOMSTAT v2 event census
- WASPSCALE v2 telemetry
- WASPSCALE v2-ext coverage audit
- Telemetry families reference
- Group lifecycle & entity reaping
- Batch AI spawner orchestrator
- Client funds/income HUD readout
- Server group GC & cap warning
- Town runtime tuning constants
- Client input/hotkey handler
- WASP base-repair system
- WASP DropRPG launcher/ordnance
- CoIn construction-interface client engine
- Town-capture garrison & airfield rebuild
- Map-control & minimap templates
- Client FPS & state telemetry
- Client service-proximity getters
- Airfield-exclusive roster & unit hints
- Unit-camera spectator system
- Town-garrison patrol/defense worker
- RequestTeamUpdate squad-discipline
- Arma2Warfare GPT assistant
- LoadoutManager build configs & defines
- GLOBALGAMESTATS extension logging
- Discord bot instrumented logging
- Eden/Everon & Taviana map content
- Cruise missile strike asset
- AI / HC
- AI headless and performance
- AI mods and pathfinding reference
- Headless client scaling and topology
- AI runtime/HC loop map
- Headless client init and stat loop
- HC delegation target selection
- Player AI caps and role balance
- Old WarfareBE FPS comparison
- AI commander autonomy audit
- Upstream BE 2073 AICOM delta
- Parent 2.073 divergence audit
- AI commander capture & fun plan
- AI commander B69 improvement roadmap
- AI commander B69 implementation sketches
- AICOM V2 cutover status
- Headless delegation and failover
- Commander reassignment call shape
- GUER Director living-resistance pitch
- Quality and operations
- Foundation perf findings & Tier-3 dead-ends
- Dead/stale code register
- Commander vote/reassignment
- Attack-wave authority
- Server runtime and operations
- Server ops runbook
- JIP enrollment & client data delivery (b74.2 lessons)
- Server gameplay runtime atlas
- PerformanceAuditAnalyzer
- Performance opportunity sweep
- Documentation plan
- Knowledge platform roadmap
- Wiki quality audit
- Wiki pruning and relevance ledger
- Audit findings queue (2026-06-03)
- Deep review findings
- Client UI / server-loop perf findings
- Performance gain simulation
- Self-host testing field notes
- Cleanup and work lanes
- Hardening and authority
- UI / player workflows
- Client UI, HUD and menus
- UI HUD and dialogs
- Player UI workflow map
- Client UI systems atlas
- UI IDD collision repair
- UI control class library reference
- UI theme palette and style macros
- UI design inspiration 2026-07
- Available-actions client gate FSM
- Gear/loadout/EASA atlas
- Gear template profile filter
- Vehicle cargo equip loop bounds
- Factory and purchase systems atlas
- Service menu affordability guards
- WASP overlay
- Class-skill system reference
- Skin selector and class swap
- Earplugs audio toggle
- Mission audio catalog
- HQ radio knowledge-base catalog
- QoL trio player hints
- Player vehicle/travel actions
- Tooling / release / integrations
- Tools and build workflow
- Warfare web tools
- Ecosystem & companion repos
- Zargabad tooling parity
- July 2026 release readiness
- Operator monitor and CPU affinity tools
- Tooling release readiness audit
- Source fix propagation queue
- Agent release readiness ledger
- Release source intake map
- Testing/debugging/release workflow
- Current RPT release gate
- RPT telemetry consumer port map
- External integrations
- Integration trust boundary audit
- AntiStack database extension audit
- Community & Dev
- Community & Dev
- Miksuu upstream wiki import / archive index
- Upstream changelog feature leads
- Developer history and upstream lessons
- Upstream Miksuu commit intel
- Upstream mining ledger
- Archive script mining v2
- Upstream BE 2073 AICOM delta
- Parent 2.073 divergence audit
- PR8 and Drone upstream lesson match
- Development lessons learned
- External research reports
- Audit archive 2026-07
- Briefing reference
- Utes invasion concept
- Miksuu archive: Home
- Miksuu archive: Welcome
- Miksuu archive: Big announcements
- Miksuu archive: Changelog
- Miksuu archive: Development process
- Miksuu archive: Discord bot
- Miksuu archive: Gameplay videos
- Miksuu archive: LoadoutManager
- Miksuu archive: Chernarus script architecture
- Base-game visual catalogs
- Compatibility and references
- HC upstream history and lessons
- Player stats branch audit
- BuyMenu EASA QoL branch audit
- Perf quick wins branch audit
- Commander positions branch audit
- Zargabad branch audit
- Quad AI Commander concept
- Arma 2 OA external reference guide
- Base-game config & image reference
- Arma 2 OA compatibility audit
- Arma 2 OA agent traps reference
- Arma 2 OA command versions
- Wiki source consistency
- External Arma 2 OA reference index