The user's install script will parse the xml file, which will fail if the file does not comply with the following DTD, which is part of the user's UruDistro installation:
- UruDistro DTD Show Spoiler
The script will then perform a sanity check on the distro, making sure all needed files are included, all target files exist in the Uru folder, and the data in the xml file is coherent.
Here's an example xml file:
- Example UruDistro.xml file Show Spoiler
The first part of the file describes the distribution. This information will be presented to the user so he can confirm he wants to install it:
- confirmation dialog Show Spoiler
distro id
Each distribution should have a unique id number, although the system will work fine otherwise.
I don't expect hundreds of distros, so it should be easy to pick a unique number.
Numbers starting with "000000" should be reserved for internal testing.
version
The version number of your distribution.
name
A short name for your distro.
author
Author's real name or alias. Ideally, this would include your GoW alias for support purposes.
date
Date this version was released. No specific date format is required.
<description>This distro ...</description>
Include as much pertinent information here as you can. Especially, describe the changes enough so the user can make an informed decision about trying it or not. Also specifi if any previous version should be uninstalled before installing this one.
The rest of the file describes your changes for the install script.
<file>
One <file> node can exist in the xml file.
This node lists files to be deleted (delobj) or added (addobj) to the user's game folder. Files to be added MUST all be included in your distro or the install script's sanity check will fail and the script will refuse to perform any change at all. Normally a distribution should not delete files from the user's game folder, this is more for the uninstall script. The "type" attribute is important, as it tells the install script where to copy the file.
<sdl id="Fens" statedesc = "Fens">
Several <sdl> nodes can exist in the xml file.
Each node lists changes to one SDL file. The "id" parameter MUST be the name of an existing SDL file otherwise the install script's sanity check will fail. The "statedesc" attribute must exist otherwise the xml validation will fail, and should be the name of an existing STATEDESC section in the file, otherwise no change will be applied on the file. In all Cyan files, this attribute has the same value as the name of the SDL file. The install script will copy the last version of this STATEDESC block from the user's file, increment the version number and add or replace the SDL variables specified. Normally a distribution should not delete SDL variables, this is more for the uninstall script.
<age id="Fens">
Several <age> nodes can exist in the xml file.
Each node lists changes to one .age file. The "id" parameter MUST be the name of an existing .age file otherwise the install script's sanity check will fail. The install script will add the specified pages to the user's .age file, replacing them if they already exist. Normally a distribution should not delete pages, this is more for the uninstall script.
<fni id="Fens">
Several <fni> nodes can exist in the xml file.
Each node lists changes to one .fni file. The "id" parameter MUST be the name of an existing .fni file otherwise the install script's sanity check will fail. The install script will add the specified settings to the user's .age file, replacing their old values if they already exist. Normally a distribution should not delete settings, this is more for the uninstall script.
<prp id="Fens_District_mainRoom" scenenode="Fens_District_mainRoom">
Several <prp> nodes can exist in the xml file.
Each node lists changes to one .prp file. The "id" parameter MUST be the name of an existing .prp file otherwise the install script's sanity check will fail. The "scenenode" parameter must be included if any change is made to a plSceneObject.
-<delobj> The "id" and "type" attributes should reference a unique, existing object in the prp. The install script will try to delete the object by invoking the "PrpMod" libPlasma tool with those parameters. If "type" is "plSceneObject", then the "scenenode" attribute must contain the name of the prp file's plSceneNode object. Normally a distribution should not delete objects, this is more for the uninstall script.
- <addobj> The "id" and "type" attributes should reference a unique object in the prp. If the object exists it will be replaced. The "data" attribute MUST contain the filename and extension (but not the path) of a file included in the distro folder otherwise the install script's sanity check will fail. The install script will try to add the object by invoking the "PrpMod" libPlasma tool with those parameters. If "type" is "plSceneObject", then the "scenenode" attribute must contain the name of the prp file's plSceneNode object.