It is recommended to always use the latest versions of Mods, as especially incompatibility issues tend to get fixed.
It is important to verify the correct working of the ACE mod, and all other mods that are used in combination.
Recommended is to start with only the ACE mods, then add a single mod at a time, and playtest several situations in MP.
Especially buggy scripts, can cause severe degradation of scripting performance, which in turn cause all sorts of malfunctions and delays.
By default, script errors are not shown on screen, this usually means most errors are overlooked.
Please see -showScriptErrors startup parameter
The ArmA 2 RPT is particularly useful in discovering issues. Delete the RPT, run the game without the mods, and run the game with the mods, compare!
Please see Compatibility for more info and Compatible mod for verified compatible mods.
Updating Base classes
This occurs once the config inheritance tree used by said addon, is different from the original.
By itself it is not a cause for alarm, however, if you make a so called 'override' config, or only want to inherit from certain classes,
it is important to keep the original class inheritance tree intact. Differences can lead to big problems in MP
Example:
Updating base class B_9x18_Ball->BulletBase, by hifi_sonic_cracks\config.cpp/CfgAmmo/B_9x18_SD/
This simply says:
The original config class defines:
class B_9x18_SD: B_9x18_Ball {
/// blablbalba
};
but mentioned addon changes the tree to:
class B_9x18_SD: BulletBase {
/// blablbalba
};
Redefining magazines, weapons or muzzles arrays
muzzles[], weapons[], magazines[] arrays, amongst other things, should never be touched by SoundMods.
Problem
All events (eventhandlers, display (key) handlers etc), and conditions (e.g FSM, trigger condition etc) in ArmA are unscheduled, but spawned script instances are scheduled, as well as the states in FSM.
Scheduling is disasterous for interactive features, like steering a vehicle (parachute) etc, on top of the fact that sleep time isn't a (reasonable) constant anymore, but in fact a variable,
that will need to be taken into account in the calculations of effects.
Still, for interactive systems, a combination of event-based (handling the interactivity), and loop (scheduled script instance, handling general processing), might be a solution to the problem.
Measuring
Enabling the diagnostics addon: In the main @CBA folder called: "cba_diagnostic_enable_perf_loop.pbo"
Copy the PBO to @CBA\Addons folder, start the game and run the tests you usually do.
Please let the mission run for at least 15 more seconds after testing is done, to make sure all log entries are written to rpt.
Then check the rpt and share it in a ticket, so we can read back the results.