Creating Files for Distribution
Translated Document
This document has been translated from the original Japanese by members of the Ukagaka Dream Team community.
To see the original document, click here.
To submit corrections/updates, see our repository to open an issue or find where to contact us.
In SSP 2.3.00 or later, if the "Enable functions for developers" option on the "General" tab of the SSP Preferences (owner draw menu/right click menu → "Options" → "Preferences...") is not turned on, the "drop folder to create updates2.dau and nar" function used on this page will not work. Please be careful.
This page describes the procedure for creating a file (archive) for distribution.
In addition to ghosts, it also covers the creation of additional shells, balloons, and other ukagaka/SSP related content.
See also the "installation" page for the file structure.
Please note that this page does not explain how to make ghosts (or shells, or balloons).
This guide assumes that you have already completed that part of the process.
File preparation
First, prepare the contents to be included in the archive (in the case of a ghost, the set of files that make up the ghost).
If you are developing by directly editing content installed in the baseware※, you may want to copy the entire contents to another location, rather than the baseware itself, and then do the following to prepare it as a file for distribution.
For information on what files are needed, refer to "Overall Structure", and the respective pages such as "ghost" and "shell" in the "File Structure" category of the menu on the left side of the page.
Files such as install.txt, updates2.dau, and developer_options.txt will be prepared on this page later, so you do not need them now.
Then, remove files that are unnecessary for the user. Here are some examples.
- Save data files for the various SHIORI and other applications (unless required to set initial values, etc.)
- All profile folders (can be in both ghost and shell, these are automatically removed in SSP)
- Development tools (such as Satorite, RESTHIBA, etc., which are included with Satorite)
- (MATERIA only) profile.txt directly under the directory
- Windows-generated configuration files such as desktop.ini (These are automatically removed to some extent in SSP)
- Other dictionary files for development, configuration files, log files, etc.
For SSP, you may want to set up developer_options.txt.
See "About developer_options.txt" below for details.
Creation of initial updates2.dau
Next, create the initial file for network updates (updates2.dau).
This is a mechanism to detect abnormalities such as corruption or tampering, by checking whether there are any differences in file contents between the server side and the client side when performing a network update.
Therefore, if you do not plan to support the network update function, or if the content is invalid for the network update function in the first place (e.g., additional files for ghosts), you can ignore this and continue on.
Initially, it is not actually necessary to have a network update file in the archive.
However, creating them reduces the amount of work the baseware has to do on the user's side during the first network update.
It is especially helpful if the archive contains a large number of files.
First, when creating updates2.dau in MATERIA or CROW, you must create an file named updates2.dau in the top directory (for example, the location where the ghost folder, shell folder, readme.txt, etc., are located for this ghost). The file must be an empty text file.
In SSP, it is created automatically.
Then start the baseware, and drag and drop the folder containing updates2.dau and the files you want in the update onto the main unit.
At this time, in MATERIA and CROW, if install.txt is included in the folder, archive creation is prioritized and updates2.dau is not created, so be careful not to include it.
In the case of SSP, you can do the opposite by creating install.txt and then drag and drop the folder to create the archive and updates2.dau all at once.
After dragging and dropping, a file named updates2.dau should be created (and exist) in the folder, and some content should be written inside.
You can open updates2.dau with a text editor such as Notepad by right clicking on it, and check its contents (you don't have to understand the contents itself).
Preparation of install.txt
Next, prepare a file called install.txt, to describe and configure the installation.
In the top directory (for example, where the ghost folder, shell folder, readme.txt, etc., are located for ghosts), create a text file named install.txt and write it according to the directory's contents.
Please refer to the Install/Update Settings page for information on what to write, as it depends on whether the content you want to distribute is a ghost, a shell, etc. An example is also available there.
Archiving
We are now entering the archiving phase, and once we get to this point, there is not much left to do.
This is because the baseware has the ability to create an archive of folders containing install.txt when they are dragged and dropped.
Therefore, all we have to do is drag and drop the entire folder we have prepared so far onto the baseware (the ghost that is running on the baseware).
You will now have a file named "[folder name].nar※". This will be the archive file for distribution.
Then, upload this nar file to your server or uploader, and you are ready to publish.
About developer_options.txt
When creating an archive or updates2.dau with SSP, you can prepare a file named developer_options.txt at the top level (where install.txt is placed when creating an archive) to set files to be targetted.
See the section on about developer_options.txt on the Install/Update settings page for an explanation and example of how to write it.
About Ghost Distribution Automation System (GDM)
The Ghost Distribution Automation System is a support tool that handles creating updates2.dau, creating the ghost archive, and uploading it to the server all at once.
Once installed and properly set up, most of what is written on this page will be unnecessary.
It is currently distributed by the "Maintenance Team", listed below.
Please also refer to the following site for detailed introduction and setup explanations (the contents of "1" are not necessary).
Despite "ghost" being in the name, it can actually be used to upload archives and network update files for shells, balloons, and just about anything else.
You can also save settings for multiple targets (Ghost 1, Ghost 2, Shell 1, Shell 2, Shell 3, Balloon, etc.) for each operation, such as archive creation, network update, etc. You can select just the operations you want to perform at that time and execute them all at once.
This is very helpful if you are managing a lot of content.
The initial installation and setup are a bit difficult, but once you've done it, it is very easy to complete network update and archive updates for multiple items with a single click.
Not only that, it completely prevents md5 mismatch errors caused by mistakes such as modifying files after creating updates2.dau, or uploading with FTP communication set to ASCII mode.
Of course, proper settings can also be of great help in preventing unwanted files from being mixed in.
Note that the developer_options.txt file mentioned above is a configuration file that works when creating nar and updates2.dau through SSP's function, so it is not relevant when creating them through GDM.
However, GDM itself allows you to configure which files should be uploaded or not, so it is essentially unnecessary.
About refreshinstall
If install.txt contains the following description, it will be a special installation.
refresh,1When this is specified, if there are already files in the folder where the item is being installed, they will all be deleted before the item is installed (rather than being overwritten).
Use this function if you change the folder/file structure, etc., and end up with unnecessary files after the changes are made.
However, please note that a refresh installation will also erase save data, etc.
You can specify the files you want to keep during a refresh installation as follows.
refreshundeletemask,save1.txt:save2.txtSee also the Install/Update Settings page for details on the formatting and other information.
Distribution of balloons and other items included in the package
By writing in install.txt and configuring the necessary files, you can bundle and distribute balloons with ghosts.
In addition to balloons, SSP allows plugins and headlines to be included, and even allows them to be included in the shell rather than in the ghost.
Consider the following example of bundling a balloon with a ghost.
The fule structure will look like this:
+-(myghost) +-install.txt +-developer_options.txt (SSP only) +-ghost +-shell +-(myballoon) +-descript.txt +-balloons0.png : :
At this time, if you write install.txt as follows, you can install the balloon at the same time as the ghost.
charset,UTF-8 type,ghost name,Ghost Name directory,myghost(※Ghost folder name (alphanumeric)) balloon.directory,myballoon(※Balloon folder name (alphanumeric))
In this case, install.txt is not required on the balloon side.
※Even if it exists, it will be ignored. You may include it in anticipation of a stand-alone distribution.
Also, if the balloon folder name after installation is to be different from the folder name when distributed, do the following.
charset,UTF-8 type,ghost name,Ghost Name directory,myghost(※Ghost folder name (alphanumeric)) balloon.directory,hoge_balloon(※Name of the balloon folder after installation (alphanumeric)) balloon.source.directory,myballoon(※Name of the balloon folder in the archive (alphanumeric))
Now, the balloon folder "myballoon" in the example above,
will be named hoge_balloon after the actual installation.
The refresh settings for the included files are as follows.
balloon.refresh,1
balloon.refreshundeletemask,hoge.png:huga.txt:...When bundling items other than balloons (only available for SSP), the "balloon" part in settings such as "balloon.directory", "balloon.source.directory", "balloon.refresh", etc., should be replaced with the type of content you want to bundle, i.e.
- headline
- plugin
- calendar.skin
- calendar.plugin
Change it to one of these, and include the file in the same way as the balloon example above.
About additional files for ghosts
If you want to create an archive of additional files (supplements) to a ghost, create an archive that includes only the files you want to add, while keeping the original folder structure of the ghost.
For example, if you want to add a file called "dic_supplement.txt" to ghost/master, it would be like this:
+-(mysupplement) +-install.txt +-developer_options.txt (SSP only) +-ghost +-master +-dic_supplement.txt
The contents of the install.txt file will look like this.
charset,UTF-8 name,Additional talk patch type,supplement accept,Name of the main side of the target ghost
About multiple installation packages
This method is for SSP only.
By creating an archive with the following file structure, you can create a package to install multiple items at the same time.
+-(mypackage) +-install.txt (for package) +-(myghost1) +-install.txt (for myghost1) +-developer_options.txt (SSP only) +-ghost +-shell : +-(myghost2) +-install.txt (for myghost2) +-developer_options.txt (SSP only) +-ghost +-shell :
Prepare an install.txt file for the package in a folder, and put each of the items in that folder.
Each item has a separate install.txt, and is a normal installation structure that can also act as a stand-alone archive.
It may be easier to think of it as "packaging" a number of items in a folder and adding a separate install.txt for the package as a box.
The install.txt for the package in the top level folder should be written as follows.
charset,UTF-8 type,package name,Package Name
The individual install.txt files should be written as usual (see Install/Update Settings, etc.).
When using developer_options.txt, note that it should not be provided in the top-level folder, only in the folders of each individual item.
The above file structure is an example of two ghosts, but of course it can actually contain any content that is valid as an archive, not just ghosts.
However, be careful not to put together items that specify "accept", such as type,shell and type,supplement, if they have different recipients.