Difference between revisions of "Compatibility"

Revision as of 09:06, 26 March 2010

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. The same problem can occur if a builder has intentionally placed content in the packages\override folder.

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.

What if my mod extends both Single Player and Awakening?

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.

Normally, it's not a good idea to make new core resources.

Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource - but that affects all campaigns, of course.

Placing resources in the packages folder should be avoided (unless you have a very good reason), because once a player has installed those resources, they persist, even when your add-in is disabled.

Unfortunately, the packages folder has to be used for resources that won't load from the addins folder, namely

• Tintmaps
• Resources which are required for the standalone Character Creator program

Art resources posted to local are always sent to the module's 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.

See String ID main article for a discussion of how this impacts sharing between Builders.

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 undesirable 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.

FAQ

What if my mod extends both Single Player and Awakening?

Just create two dazips for your module. Name one yourprefix_yourmodule_version and the other yourmodule_yourprefix_EP1_version.

Edit the Manifest.xml file inside yourmodule_yourprefix_EP1_version.dazip.

Change the line

<AddInItem UID="your_module" Name="Your Module Name" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1">

to

<AddInItem UID="your_module" Name="Your Module Name" ExtendedModuleUID="DAO_PRC_EP_1" Priority="100" Enabled="1" State="2" Format="1">

How can I import an item with my existing character to a new campaign?

The Awakening expansion allows an existing character to be imported from one campaign to another.

There are two methods of ensuring that an item in the player's inventory is imported successfully:

• Make the item a core resource
• Include the item template in separate add-ins to both campaigns (see Awakening example above)