1.8.0.13

Reproduction A (no workshop mods): vanilla Arma Reforger Server 1.8.0.13 plus one test addon, PADTEST (GUID 6A1C0DE15A0B1E02, depends only on the base game). Its only content is 3000 classes of the form:

class PADTEST_C0 { protected static ref array<string> s_V = {"a0", "b", "c"}; }

Steps:

1. Start a dedicated server with only the base game and the PADTEST addon loaded.

2. Wait for script compilation.

Expected: the server starts.

Actual: compilation fails with thousands of "Too many instructions per function" errors (5383 on my machine), followed by Can't compile "Game" script module!. The server does not start.

Same test with a different declaration in the 3000 classes:

- Also fails: "static const ref array<string> C_V = {...};" (same error count), "static ref array<string> s_V = new array<string>();" (2228 errors).

- Starts normally with vanilla only (so they fit in the headroom vanilla leaves): "static int", "static const int", "static const string", a non-static member "ref array<string> m_V = {...};", a local array literal inside a function, and 3000 classes with 40 lines of ordinary code each.

Reproduction B (public workshop mods, 10 entries): SHS Modular Framework 1.2.2 (688719AD953F7AD6) plus these nine, all at their latest versions:

AKI_Core_Upgrade 662EB83AB3F8CAE3, ACE Medical Circulation Dev 65AD7D4F994EA327, ACE Medical Hitzones Dev 65B343F799FB521B, Bacon Loadout Editor 606B100247F5C709, Anarchy Markers 69A510CE600D1126, WCS_VON 69333B6C7C8BE8AB, Server Admin Tools 5AAAC70D754245DD, GM Tools 64F10E068D5880A6, gm snap to terrain tool 687EE407F9B26A7F.

Result: Can't compile "Game" script module! (1 error: SCR_FeedbackDialogUI.c,44). With SHS Modular Framework 1.2.1 instead, or with any one of the nine removed, it compiles. The result is the same for every load order I tried (given order, reversed, two random shuffles).

After a mod update, a modded dedicated server of mine that used to start fine no longer starts. Script compilation stops with a long series of “Too many instructions per function” errors, followed by Can't compile "Game" script module!. No single mod is broken: each one works on its own and in smaller combinations.

This looks like the same limit as in T200535, though I could not confirm that it is the same issue. The static initializers of the whole script module appear to be compiled into one function, and that function has an instruction limit. I reproduced the error with vanilla plus one minimal test addon that contains a single large static array (reproduction A: [attach or describe]).

What counts toward the budget

Static and static const initializers that construct an object or an array fill this budget, and their size matters as well as their number: a single static array of a few hundred elements can be enough to break a stack. Non-static member initializers, local array literals and ordinary code did not measurably count (3000 classes with 40 lines of code each compile fine). Standalone scalar and string constants count far less, if at all: 3000 of them still fit in the headroom that vanilla alone leaves. (Elements of a static array count individually, including string elements.)

Measurements

The budget is shared by vanilla and every loaded addon. As a rough unit I counted the elements (commas plus new calls) of all static array and object initializers in the .pak files. Vanilla Scripts/Game has 447 such initializers, about 1,850 elements. My 122 addons add about 970, for roughly 2,820 in total. Six addons account for most of that 970: SHS Modular Framework 1.2.2 (367), WCS_Armaments (231), 2HGZ-LoadoutManager (78), RHS - Status Quo (69), WCS_Interface (55) and 2HGZ-AutoArsenal (52). The other 116 add about 120 together.

The limit cannot be pinned to one number in this unit, because the unit undercounts constructor calls. Stacks of 2,611 and 2,714 started. My stack of 2,820 fails, and so did a stack of 2,592 that contains many constructor calls. To stay on the safe side, I would keep a stack below about 2,500 in this unit.

What triggered it

The trigger was a mod update. SHS Modular Framework went from 1.2.1 (about 154 in this unit) to 1.2.2 (367). One of its static arrays (SHS_AREA_TYPE_ROUTING_MAPPINGS) grew from 53 to 120 new SHS_AreaRoutingMapping(...) entries, and three small static map initializers were added. My modpack fails with 1.2.2 (275 error lines) and compiles again when only that addon is pinned to 1.2.1. SHS 1.2.2 alone with vanilla compiles fine. I repeated the switch several times with the same result.

I measured the remaining headroom on a smaller stack: SHS 1.2.1 plus the nine mods of reproduction B ([list the nine mods]). Adding one static array of N string elements compiles up to N = 335 and fails from N = 350, and within this stack each further element adds about one error line (8 at 350, 23 at 365, 38 at 380). With SHS 1.2.2 instead, the same stack fails by a single line, and removing any one of the nine mods fixes it. So the growth of SHS 1.2.2 costs about as much as 340 string elements, about five per new constructor entry, which is just what that stack had left. I do not think the addon is at fault. It needed a larger table, and the stack had no room left for it.

Other servers with many more mods can start fine, because what matters is not the number of mods but the total size of their static initializers. I ran the mod list of one such server (about 160 addons, including SHS 1.2.1 as pinned there, WCS_Armaments, RHS and ACE; the other mods at their latest versions). It starts. By the same unit it totals about 2,480 (624 for the mods, 1,852 for vanilla), against about 2,820 for mine. The difference is SHS 1.2.2 (213 more than 1.2.1) plus several mods that I run and that server does not (2HGZ-LoadoutManager, WCS_Interface, 2HGZ-AutoArsenal, CRX Enfusion A.I., Server Admin Tools).

Why this is hard to diagnose

1. The error lines point at unrelated files, including vanilla scripts, and across different mod sets the number of error lines does not reflect how much a mod contributes.

2. Load order changes neither the result nor the threshold; I tried four orders.

3. Removing other mods often does not help: the mods I could remove were too light to cover the overshoot, and the heaviest ones came back as dependencies of other mods.

Admins and mod authors cannot tell which addon is using the budget. An update to a single mod or to the engine can break an unchanged, previously working modpack, and the only remedies are pinning versions or removing mods by trial and error. As vanilla and mods grow, more community servers will be affected.

Workaround for mod authors

Initialize lazily: declare the static member without an initializer and create it on first use in an accessor. One addon had 13 such initializers; converting them brought its contribution to zero with no change in behavior.

Requests

1. Use per-class or per-addon initialization functions instead of a single global one, or raise the limit significantly.

2. Report which addons and classes contribute to the budget (for example, a per-addon total at the point of failure) instead of pointing at unrelated vanilla lines.

3. Log the current total usage against the limit at compile time, so admins can check the remaining headroom before adding mods.

4. Document that static and static const arrays and objects count against the budget according to their size.