Compatibility

From Dragon Age Toolset Wiki
Revision as of 11:16, 5 March 2010 by Proleric1 (Talk | contribs) (Created page with '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 ...')

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 can occur between them. Tedious, but effective.

This should rarely be necessary if the following guidelines are observed.

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. Period. Each builder can register the prefix they require. See Naming_conventions#Resource_Naming_Convention.

2DA Conflict

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

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_(dascript_type) for an approach which avoids overwriting the official core scripts.

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.