Arma Reforger Tools / Workbench 1.8.0.13 (Windows). Dedicated server 1.8.0.13 (Windows) for comparison.

Any preset with more than ~2432 modded .c files

Summary
Workbench cannot compile the Game script module once the loaded mods take it past 8092 .c files. Nothing in the output names a limit. The errors point at unrelated vanilla and third-party files, so they read as a broken mod. A dedicated server compiles the same mod set at 8127 files without complaint. Workbench therefore cannot load the full mod set our server runs.

Steps to reproduce
1. Open a mod preset whose Game module compiles at exactly 8092 files. The startup log reads "Module: Game; loaded 8092x files; 16314x classes".
2. Add any one new .c file to any loaded addon. A file holding a single empty class (class X {}) is enough, and so is a file holding only a comment.
3. Restart Workbench.

Expected
The Game module compiles, or an error names the limit and the file that exceeded it.

Actual
Can't compile "Game" script module!, preceded by errors in files nobody touched:
- RHS_NightVisionComponent.c:477 Callbacks do not support overloaded methods 'ActivateAction'
- SCR_InventoryStorageBaseUI.c:989 Error in parameters, then Can't find variable 'changeMap'
- SCR_PlayerArsenalLoadout.c:324 Error in parameters, then Can't find variable 'sortSlots'
- SCR_FactionManagerSerializer.c:26 Error in parameters, then Can't find variable 'friendlyDefaultMapping'
- SCR_ModularButtonComponent.c:489 Error in parameters, then Can't find variable 'widgetEffectEventMasks'
- SCR_MapUIElementContainer.c:443 Incompatible parameter 'on delete'
- SCR_ScenarioUICommon.c:452 Can't find class Tuple2; SCR_SpawnLogic.c:298 Can't find class Tuple1
- SCR_ScenarioFrameworkGetCountEntitiesInTrigger.c:10 Can't find class SCR_ScenarioFrameworkParam
- SCR_SpinningWidgetComponent.c:25 Can't find class SCR_SpinningWidgetAnimation
No error names a file from the mod that was changed. The classes reported missing are defined in files that are present (Scripts/Core/tuple.c, SCR_ScenarioFrameworkParam.c), so it looks as though files past the limit are silently left out.

How we isolated it (startup compiles, same full preset)
- 8092 files / 16314 classes: compiles
- 8093 files / 16315 classes (new file, one empty class): fails as above
- 8093 files / 16314 classes (a file's class merged into another, the emptied file kept): fails as above
- 8092 files / 16314 classes (that emptied file deleted): compiles
So the trigger is the number of files, not the class count and not anything in the code.
- A 1500-line file that fails this way on the full preset compiles cleanly on a two-mod preset (5841 files).
- The same ATG source plus 35 comment-only files (8127 files) compiled cleanly on a local dedicated server.

This is not ARMD-85 / T200535 (the static-initializer budget). There is no "Too many instructions per function" line, and converting about 1,500 of our static initializers to methods made no difference.

Why this matters to modders
Server communities run large mod sets. The only reliable way to find conflicts between mods is to load what the server loads in Workbench, and edit and test against it. Our server's set reaches 8092 files with the base game accounting for 5660 of them. That leaves about 2430 files for every mod a community runs, combined, and the server itself has no such cap. Once a mod set passes it:
- one new script file in any mod (ours or a third party's update) breaks every modder's Workbench, with errors that point somewhere else entirely;
- we are forced to split our workspace into smaller presets that no longer match the server. Conflicts between mods that are never loaded together in Workbench then only appear on the live server.
Hours go into chasing the misleading errors before anyone suspects a limit. This penalises exactly the communities that build the most on Reforger.

Requests
1. Raise or remove the file limit in Workbench, at least to match the dedicated server.
2. Until then, report it plainly: an error naming the limit, the count reached, and the file that exceeded it, instead of the vanilla cascade.
3. Document the limit, and log the count alongside the headroom remaining.