Difference between revisions of "Compatibility"

From Dragon Age Toolset Wiki
Jump to: navigation, search
(String Conflict)
(Module Scope)
Line 13: Line 13:
 
== Module Scope ==
 
== 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.  
+
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.
 +
 
 +
In the case of Awakening, chances are you will want to extend into core game resources. (This tip needs more feedback from toolset modders).
  
 
== Resource Scope ==
 
== Resource Scope ==

Revision as of 12:13, 25 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.

In the case of Awakening, chances are you will want to extend into core game resources. (This tip needs more feedback from toolset modders).

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.

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

  • Core item overrides (.uti)
  • 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.