No announcement yet.

Addon/Mod Compatibility Overview

  • Filter
  • Time
  • Show
Clear All
new posts

  • Addon/Mod Compatibility Overview

    Addon and Mod compatibility is a frequent topic of conversation so I thought I would give some general background on why some mods are compatible and why others are not as well as overall efforts in the ArmA editing community to enhance compatibility. I am far from an expert in the topic but have come across enough information to shed a little light on the matter. Before diving into into compatibility issues I want to give a quick overview of how addons and mods work. For those who already have a good idea of what addons and mods are skip ahead to Addon & Mod Compatibility Issues.

    What are Addons and Mods?

    Addons and mods are additions/changes made to game content. There is no stock definition of what differentiates an addon from a mod. As far as the game itself is concerned all changes to game content are addons. But, in "general" the ArmA editing community uses the term addon for individual or limited content changes (new weapons or vehicles or changes to individual weapons or vehicles) and the term mod for large-scale changes to game content usually along an era, region, community/interest or other type of "theme". There are two ways to how new content is introduced into ArmA. Via the ArmA\Addons folder or a custom mod folder . Custom mod folders are the preferred method as they are much easier to organize, track, and diagnose for compatibility issues.

    Various types of changes to game content can be introduced: Physical appearance (Changes to or new models and textures of vehicles, weapons, persons, etc.) physical characteristics (How a vehicle or person functions like speed, accuracy, etc.) visual and sound effects (weapon sounds, tracers, smoke, explosions, etc.), user interface (game menus, colors, displays, etc.) among others. The changes are implemented by replacing certain types of data files (models, textures, sounds, etc.) and/or by making changes to configuration files that translate/transfer the data into the game. To get into the how's of addon/mod editing goes well beyond the scope of this thread but in general for those familiar Addon/mod editing is heavily based on the principles of object oriented programming such as classes, properties, inheritance, etc. As relevant to this thread, inheritance is one of the most frequent causes of addon/mod incompatibility. Almost all addon/mod content is based on something originally introduced by BIS in ArmA and inherits most of their properties from the original content. There are tracers in ArmA, so tracer mods change the properties of the original tracers. There are helicopters in ArmA so new helicopters addons inherit most of their properties from original ArmA helicopters and so on. If new addons and mods do not properly configure this inheritance the properties of one addon/mod can overwrite the properties of the original game in a detrimental fashion or conflict with other addons/mods.

    Finally regarding addons/mods in general, most of the content added in an addon/mod only affects the computer where the addon/mod is installed but the effects of what other players do can still be seen/heard on your computer even if they do not have the same addons/mods installed. If I have a tracer mod installed and another player doesn't when that other player fires a weapon I will see the modified tracer but he will not. This is because much of the graphical game world is rendered/controlled on your computer based on info passed to it by the server or other computers (e.g. The server tells my computer a shot was fired but my computer determines what the visual/audio effects of the shot looks like). There are some addons/mods that are only for clients (individual player machines), some that are for servers only, and some that must be installed on both to work (or be fully effective).

    Addon & Mod Compatibility Issues

    There are three major areas of addon/mod compatibility: Compatibility with the game itself, compatibility with various game modes (single player, multiplayer, dedicated server, etc.), and compatibility with other addons mods.

    Compatibility with the Game Itself

    If an addon/mod is not configured properly it can seriously affect the game. For example an issue that arose in with Arma version 1.08 that caused all rifles to be missing. that was caused by some custom addons. There is little a player can do to resolve issues like these themselves. Compatibility has to be resolved by the addon/mod maker. All the player can do is not use the addon/mod.

    Compatibility with Various Game Modes

    ArmA can perform very differently in various game modes (Editor, Singleplayer, LAN/Hosted Server, Dedicated Server). Again depending on how a mod is configured or even installed and affects the server and/or clients can cause error messages, client crashes, or server crashes. This was a problem when the XAM mod was first introduced (I believe issues with the XAM mod has since been remedied). Again, there is little the player/server admin can do to remedy any of these types of issues except not use these addons/mods.

    Compatibility with Other Addons & Mods

    Because much of the content added/modified in an addon or mod inherits its basic properties from the default ArmA properties, if an addon/mod is not properly configured, multiple mods can conflict with one another. The best example of this would be sound mods. You can generally only have one sound mod installed at a time because one will overwrite the other. If one mod changes the sound of a M16 firing from "Bang" to "Blam" and another mod changes the same M16 sound from "Bang" to "Kapow" the addon/mod that is loaded last will overwrite any changes made to the same properties by other addons/mods. With this type of issue, players can possibly help resolve issues by ensuring they have the most current version of an addon/mod, change the load order of the addon/mod, or not use certain addons/mods at the same time.

    Efforts by the Editing Community to Improve Addon & Mod Compatibility

    The overall ArmA editing community is composed a large number of talented and amenable modelers, scripters, and addon/mod makers. As such, several major addons/mods have worked together to resolve compatibility issues between their respective addons/mods when they are discovered. This is not universal but many often work together to ensure that the overwriting of properties required by each addon/mod has no or minimal effect on the other. In some cases these conflicts can not be avoided (sound mods, tracer mods, etc.) but those fundamental differences are also what give players the choice to use mods they prefer.

    If you find yourself dealing with/diagnosing addon/mod compatibility issues, you may come across the term "event handlers" or "extended event handlers". For those unfamiliar with ArmA event handlers I will give a brief explanation, why they can affect addon/mod compatibility, and recent efforts to eliminate/reduce any event handler related conflicts.

    ArmA Event Handlers

    Event handlers are triggers or interrupts that tell the game to do something when a specific type of event occurs (a weapon is fired, an engine turned on/off, a unit is killed, etc. A whole list is available here: ArmA Event Handlers. When an event handler is added to a vehicle or unit or object via an addon/mod, like other properties discussed above, if another event handler of the same type is added to the same unit (or class/type of unit) one will overwrite the other. So, if you have one mod that uses a "Fired" event handler to change a tracer fired from that weapon and another mod that uses a "Fired" event handler to change how the muzzle flash/smoke looks when that weapon is fired then the only one that will work is the one that is loaded last. The only way to overcome these conflicts used to be either not use both mods at the same time or if they mod makers cooperated to ensure both effects could occur (often difficult to do considering the numbers of vehicle, weapons, sounds, visual effects that had to be coordinated.

    However, an ingenious new addon called Extended Event Handlers created by Solus and Killswitch provided a method for addon/mod makers to avoid these conflicts all together. Extended Event Handlers (XEH for short) don't add any content to the game itself but provide a framework for addon/mod makers to assign multiple event handlers to an object and not affect other addons/mods that also use XEH. Many addon/mod makers have released updated versions of their mods/addons that use XEH and whenever a new addon/mod is released that makes use of event handlers there is always a strong push for those makers by the community to use XEH.


    Some addon/mod compatibility issues still exist and it is near certain that new ones will arise in the future as well but overall compatibility issues can usually be resolved with a little bit of user and community troubleshooting and editing community cooperation. One of the greatest features of ArmA is the ability to easily add new content to the game. This new content can really enhance the ArmA experience and usually without negative impact.

    Again, I am far from an expert, but if you have any general questions on addons, mods, or compatibility issues feel free to post them or share your knoweledge or experience with addon/mod compatibility.
    Last edited by loyalguard; 03-28-2008, 07:08 AM.

  • #2
    Re: Addon/Mod Compatibility Overview

    I have had a few people ask why some addons/mods need to be installed on the server and the player's computer (clients) in order to be fully functional so I thought I would add a little bit on that here.

    In the ArmA editing community the word "locality" is extremely important. Locality in ArmA refers to which computer owns and controls a particular game object (such as a unit or vehicle). For the player locality is mostly transparent in-game, but for content developers (mission makers, scripters, addon makers) it is a critical issue.

    In Arma some things are owned/controlled by the server and others by the player's client. Much of what happens with/affects an object only happens where the object is local and may or may not be transmitted to the server and/or other clients. Content developers must address locality issues in order to make sure the content they introduce is properly represented. It is locality that usually dictates whether a addon/mod must be installed on a server and clients to be fully functional. Here is an example that demonstates this.

    Durg's Vegetation Fix is a popular mod that changes how trees and bushes "appear" to AI (they don't see leaves and branches like we do - see the linked thread for details). In order for this mod to fully functional it must be installed on the server and clients. Here's why:

    1. Human player units are local to that specific player's client.
    2. AI units that are in a group whose leader is a human player are local to that specific player's client.
    3. AI group leaders are local to the server.
    4. AI units that are not in a group whose leader is another AI is local to the server.

    Durg's mod changes what AI see when they see a tree/bush. If the mod is only installed on a player client then only AI local to that player's client will see the changes so:

    1. AI units in the human player's group WILL see the modified trees bushes.
    2. AI units in another player's group will NOT see the changes if they do not have the mod installed as well.
    3. AI units not in any human player's group will NOT see the changes.

    if the mod is installed only on the server, only AI local to the server (not in any human player's group) will see changes. Hence, In order for every AI in-game to see the changes the mod must be installed on every client and the server because of "locality".

    Now, the requirement to install certain addons/mods on servers and clients to be fully functionl is not a fault of addon/mod makers, it is just a product of how "locality" functions in ArmA.

    Again, I hope you find this hopefull when trying to figure out the why's and how's of mod compatibility.




    TeamSpeak 3 Server


    Twitter Feed