Exporting a module
For the Game to load a Module and any Resources of it, it has to get exported from the Toolset first.
The toolset stores exported Resources as files in Folders that are unique to the Module a Resource belongs to, so that the Game which has no access to the Database can read them.
By default, the path is Documents\Bioware\Dragon Age\AddIns\(module name). Resources are normally exported to the module\override\toolsetexport folder, but any resources whose Owner Module property is "Core" are exported to core\override\toolsetexport. The difference in game is that core resources affect all campaigns as long as the add-in is enabled, whereas module resources only affect the module's campaign.
Exporting is done 'per resource' on a single by single basis, however you can tell the toolset to export all at once, or a single resource with all dependend resources. Dependand Resources are those which are required for a Resource to work correctly, like a Vendor who sells a Sword is dependant on the Sword Resource. The Toolset will see the dependency automatically.
All of the Resources can then be packaged into a "Builder to Player" package, once the Module is finished. This will collect all those loose files, and put it in a single downloadable file. Which is known as "DAZIP".
Exporting by single Resources is done to test single resources in game during development. During Export, the toolset extends the "Addins.xml" file, which enables the Module to be seen from the Games Menu.
- Export with dependent resources: This will export the currently selected resource, as well as any other resources that it depends upon. For instance, if you have created an area with a creature in it, this option will export the area, the creature, the creature's inventory, the scripts, etc. It would then grab any dependencies for the creature, inventory, or scripts and continue until it exhausted all of their dependencies. Doing this is a good way to make sure you get all of the needed pieces for any particular resource, but it can also quickly multiply to the point where it is picking up half of the module.
- Export without dependent resource: This will only export the currently selected resource. This is a quick and efficient way to update your module when you have modified parts of a resource that only affect that resource.
- Export all resources of type: This will export every resource of the same type as that which is currently selected in the palette. For instance, if you select a creature and choose this method, it will export all creatures in the module.
- Full export: This option exports every resource associated with the module. It is the most comprehensive, and takes the longest to run.
Testing an Area by overriding the starting area
Area Resources can be tested in a very convenient way. If you just want to give it a test run you can override the module's start area on an export-by-export basis.
- Save the Area you are working on
- Navigate Tools/Export/Export Options
- Activate "Override campaign export settings"
- Choose the Area, and a Waypoint with it
- Export the Area with or without dependand resources as needed
Once the export has completed you should be able to start a "New Game" (if editing the main campaign) or select your module under "Other Campaigns" (for stand-alone content). You should start in the level that you have exported at the waypoint that you have set as your starting point. You need to have an custom module setup as Standalone, see above.
Creating a downloadable Package
All of the Resources which are exported are only loose files in your Filesystem. However to create downloadable and installable packages the toolset is capable of creating so called Builder to player packages, to create "DAZIP" installable Filetype.
- See Article: Builder to player
Exporting resources to other Modders
Normally the whole process will convert Resources into Gamereadable formats. Which excludes being able to edit them further with the Toolset. The source is however stored in the cloggy Database. Builder to builder is the mechanisms used by the toolset that allow packages of game resources to be shared between multiple collaborating builders.
- See Article: Builder to builder
|English • русский