Difference between revisions of "Exporting a module"

Revision as of 20:58, 29 January 2010

For the Game to load a Module and any Resources of it, it has to get exported from the Toolset first.

Overview

Exporting a Module is the process of exporting a single or all Designer Resources from the Database.

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

Art Resources and 2DA's are already present as files, which the creator has to put into into the respective Override Folder of the Module manually. ^{[Undocumented]}

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

Module structure

How the Module is set up, is an important factor how the game reacts to it. The Module's entry point into the game is made concrete with the Module properties.

A Module typically needs a starting condition, usually what will trigger new resources to appear in game. This can a Script tied to the module which puts the player in a starting Area, or by integrating one like a Sword into existing resources like a Vendor, with which the condition for the existing Vendor is already set.

Standalone Module

1. Select the module in the Manage Modules list
2. Click on the "Properties" button
3. Script will determine which script to run when the Module runs. This should either be module_core or a custom Script.
4. Starting Area and Waypoint will determine where the player start out. This can be any Area you created.

The Script will be run ,and determine any further actions once running the game. This will require to start a new campaign, and starts at the Area given.

Non standalone Module

1. Select the module in the Manage Modules list
2. Click on the "Properties" button
3. Script should be replaced with a blank script.
4. Starting Area and Waypoint should be left blank
5. Extended Module should be set to the Module which is being extended.

No starting condition is set by default, and it is up to the Designer to create something which influences the extended module. Like editting an existing Resource, which overrides original Content. However the most sophisticated method to call a condition is using PRCSCR Scripts, with which no content needs to be overwritten. This Script can then spawn Resources, new waypoints on the Map, and anything a Script is capable of. This is also what Bioware uses in their DLC. ^{[Undocumented]}

• Note that as of toolset version 1.01 and game version 1.02b, you should NOT use "module_core" as the script (as found in module properties) for an add-in that extends an existing module, otherwise you will encounter issues that may include slow-downs during conversations and attribute allocation. The exact cause of these issues is not yet known, but using a blank script with an empty main function will eliminate these issues.

• For a detailed explanation of the properties you will see here, See Module.

Exporting

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 Options

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.

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