Compatibility

DAO has an active modding community. Over time, players will accumulate many new campaigns and game mods. So, as a courtesy to players and other builders, it's helpful to try to make our mods mutually compatible.

From time to time, Bioware may well issue new releases, so it's good to reduce the risk of conflict in that respect, too.

Disable Add-Ins

If the player disables all other add-ins on the in game DLC screen, no conflict should occur between them. Tedious, but effective.

This should rarely be necessary if the compatibility guidelines listed here are observed.

Exception : there is a toolset bug which produces content that persists in game, even when the add-in is disabled, unless the builder cleans it out before making the Builder-to-Player file.

Module Scope

Setting the Extended Module in Module properties to "Core Game Resources" means that the add-in will change every campaign in game. If that's not intended, select the campaign you're trying to extend e.g. Single Player for the official campaign, (None) for a new standalone campaign.

Resource Scope

The Owner Module resource property has a similar effect on individual design resources. It's easy to make a new core resource accidentally when copy-editing an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your module's core folder, where it will impact every campaign in game.

Art resources posted to local are always sent to the core folder.

Resource Conflict

Resource names need to be unique within type. For example, genpt_party.plt and genpt_party.nss are different resources, becasue the type is different. However, if two modules both have resources called genpt_party.plt, only one will load in game, following the Source directory priorities.

Within the toolset database, duplicate resource names are forbidden, but there's nothing to stop different builders making resources which accidentally conflict, so it's wise to choose a unique range of names. Each builder can register the prefix they require. See Resource Naming Convention.

It is possible to override a core resource intentionally, by editing a copy, exporting it, and renaming it in the export folder to the same name as the original. However, almost invariably there is a cleaner way of doing this - for example, by changing the 2DA which identifies which resource to use.

2DA Conflict

Conflict between 2DA mods can be reduced using the M2DA mechanism and reserving ID ranges.

String Conflict

When a new module is created, its properties include a string id range which starts at a very large random number. This makes it very unlikely that text created by one add-in will override another.

Copying (or copy-editing) module.cif files is bad practice, because that might duplicate the string id range across two modules. So, for example, two builders working on the same project should create their modules independently, then use the Builder-to-Builder mechanism to share resources.

Core Script Integrity

See Event for a typical event-handling script which avoids overwriting the official core scripts.

Bear in mind that an add-in which impacts all campaigns could have unknown consequences if it changes scripts or event-handling, given that custom campaigns may well have made changes of their own. If in doubt, consider modding the Single Player campaign only.

Plot Property

Scripts that impact all campaigns should respect the plot property on resources. For example, if a campaign author has flagged an NPC as plot, it might not be helpful to change the creature AI.