Builder to builder

From Dragon Age Toolset Wiki
Jump to: navigation, search


Module topics

"Builder to builder" is a general term for the process of exchanging game resource information between builders, for example between several people who are collaborating on building a module. See builder to player for the process of packaging up finished works to distribute to players.

There are three basic sorts of game resources that might need to be exchanged in this manner:

  • Art resources
  • 2DAs
  • Database resources

Art resources are self-contained files stored in the computer's file system in the standard way, and so are straightforward to share between builders. 2DAs are generated from Excel files that are also straightforward to share, especially when the capabilities of M2DAs are taken advantage of (see the 2DA page for more detail).

Database resources are trickier. Almost every computer user is familiar with how to manipulate files in their filesystem but fewer are familiar with databases, and there are many interdependencies within Dragon Age's database resources that need to be taken into account when making any edit. To simplify this process the toolset has the ability to save and load selected database resources and their dependencies into XML files, which are then bundled up into a single archive file for convenience.

Note: This is a different sort of export procedure than what's needed to make resources available for use in the game itself, either for testing by yourself or for distribution to players. For information on that see resource palette.

Creating resource files for transfer

To create a resource file archive, select the resources in the resource palette and then in the right-click menu select the "builder to builder create" command:

B2B create menu command.png

You'll be presented with a list of the resources to be exported:

B2B create panel.png

Normally, you'll restrict the selection to your own module (unless you have a specific reason for exporting core resources).

Once you're done reviewing your selection, click "Ok" to export. You'll be prompted for a filename to put the resources into.

You can select multiple resources before doing builder to builder creation and they'll all be included in the B2B package.

Also, you can open a builder to builder creation window with all of your available resources in it by going to the Tools menu and selecting Builder -> Builder to Builder Create.

Builder to builder create via tools menu.png

As noted above, this only exports design resources from the database, so in addition to sharing the .dadbdata file created in this process, builders also need to exchange any simple files containing 2DAs and art resources.

Importing database resources

See also Copying a Module.

Importing resources is done via the "Builder to Builder Load" command under the "Tools" menu (there's also a B2B create command here, the same that can be reached via the palette right-click menu):

B2B load menu command.png

Again, note that this is a different set of commands than the main "export" commands.

You'll be prompted to select a database resource file generated by a previous export. When you do, you'll be presented with an options pane listing all of the resources present in the file:

B2B load panel 973.png

You can choose to import or not to import specific resources from this panel with the leftmost checkbox. Note that if you only import some of the files you may break dependencies. However, many of the dependencies in any significant export are likely to be core resources that you already have in your database and it's wise to avoid re-importing such resources unless you have a specific reason to.

You have the option to assign new string ids, or retain the original string ids, which allows you to maintain integrity of reference to the talk table. There seems to be a bug with "Use Theirs". See String ID for a discussion of sharing issues.

ResRefID is the identifier that the resource had in the database it was exported from. ResRefIDs must be unique within any given database, so these numbers will be reassigned automatically during the import process.

Resource name conflicts

The "Exists/New" column indicates whether a resource with the same name already exists within the destination database. This is a good way to identify common core resources that were included as dependencies on export but that you don't want to re-import.

In the event that you import a resource with the same name as an existing resource within your database, the default behavior is for the old resource within your database to be overwritten by the new resource coming in from the import. The last column, "create new", allows this behavior to be overridden. If you enable "create new" for such a resource, the imported resource will be renamed with "_1" (or a higher number as needed) and the old resource will be untouched. Any other new imported resources in the file that depend on the renamed resource will have their dependencies updated to refer to the new copy of the resource.

Note that if use "create new" when importing a resource's dependencies and then you later re-import the same resource the importer won't know that its dependencies have been renamed in this manner. It's best to avoid this situation as hard-to-debug problems can potentially result.

Resources with the same name that already exist in the destination database and that are checked out by other users aren't editable, so the "checked out" column will warn you of any resources that the import process will be unable to update. This is unlikely to be a concern when only a single user (yourself) has access to your database but may become significant in a more sophisticated multi-user collaborative environment.

Copying a Module

You might want to copy a module to a new machine, a new data base, or another builder's data base.

Builder-to-Builder Create is a good way to backup your resources for transfer or recovery.

When you want to make a copy, create a new module in the target data base, entering the resource name and Name property manually.

If you have VO, you'll want to ensure string ids don't change during load (otherwise you'll have to rename all the VO files).

If you know what string range was defined for the original module, change the new module to the same range.

If you've lost the original module and have no independent record of the string range, you need to ensure that all the strings in the .dadbdata file are in range. Temporarily, you can set the start of the range to 1, and the end of the range to a very high value.

Now do the Builder-to-Builder Load, with the Use Theirs option for string ids.

If you have a temporary string id range, examine the new module in the String Editor to discover the lowest and highest string id values. Set the range start to the lowest, range next to one higher than the highest, and range end as high as you like.

Finally, change the other module properties, such as the start area / waypoint and the module script. That has to happen last, because you select from the resources you just loaded.

Sharing a live database

If passing bundles of files around between builders proves to be a cumbersome means of collaborating, a more advanced alternative exists: sharing a single database repository.

With a default installation of the toolset on a user's computer, a database is installed on that local computer for that toolset's use. Using the toolset's configuration tool, however, it is possible to tell the toolset to use some other database instead - possibly on another machine entirely, provided it's accessible over a network. This is the collaboration mechanism that was used internally at BioWare during the development of the Dragon Age single-player campaign, along with a more traditional file repository for the art resources and 2DAs, and is the principal reason why the toolset supports the concept of "checking out" database resources for editing.

General considerations you'll need to take into account:

  • Firewall and router issues - The computers of all the various collaborators will need to be able to contact the central database. This may require port forwarding and other potentially tricky configuration settings.
  • Availability - If all work is being done on a single database, nobody will be able to do anything when that database is unavailable. It may be a good idea to set up a machine dedicated solely to running the database.
  • Security - You'll be exposing your database to potential intrusion attempts from the outside world, so make sure you understand the risks and the steps that can be taken to ameliorate them.

Though this is fully possible in principle with the existing toolset, the specifics for how to accomplish this outside the BioWare intranet haven't been tested yet so we don't have documentation for it yet.


Language: English  • русский