Supporting Network Updates

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" function used on this page will not work. Please be careful.

This section describes the settings and preparations necessary to support network updates.

In addition to ghosts, SSP can also perform network updates for shells, balloons, plugins, and headline sensors. These are included in the explanation.

Prepare a server

First, prepare the servers necessary for network updates.

Free hosting servers, such as those used to set up personal websites, are acceptable.

With hosting servers (especially with free services), network updates may be inconvenient due to restrictions or settings.

Pay particular attention to the following points when choosing a server.

  • The required file extensions can be uploaded.
  • Ads are not automatically included in text files.

If you are looking for a free hosting server, the following pages should be helpful.

The Daidebe wiki: where is the best place to distribute ghosts? (Free space version) (External site)

Set update URL

Generally, it is written in the descript.txt file.

Write the following line in descript.txt to set it up.

homeurl,http://xxx.yyy/myghost/

The url to be written here will be the url on the network to the folder containing the contents of the network update (the location where updates2.dau will be created later).

Therefore, what the url will be depends on the server. But suppose the root directory of that server is http://xxx.yyy/, and the folder of the ghost for which you want to support network updates (myghost) is like so:

+-root
  +-ukagaka
    +-myghost1
      +-ghost
      +-shell
      +-readme.txt
      +-updates2.dau
+-index.html
+-hogehoge.html
+-style.css
:
:

If the file is placed on a server with this arrangement, then the descript.txt file should contain the following information:

homeurl,http://xxx.yyy/ukagaka/myghost1/

If the content is a ghost, it is possible not only to specify the url in descript.txt, but also with SHIORI Resource's "homeurl"

The specific method of specifying homeurl using SHIORI Resource on the ghost side depends on the SHIORI, and is beyond the scope of this document. Please refer to the respective SHIORI documentation.

Remove unnecessary files

Next, remove the files that are unnecessary for the user. For example, files such as these.

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

In the case of SSP, developer_options.txt will be helpful if it is too much trouble to remove them manually every time.

For more details, please read the explanation below.

However, what should we do if we have released an update with these unnecessary files mixed in, or if a file we used to use becomes unnecessary (renamed)?

In such cases, simply deleting unnecessary files from the server will not delete the user's files.

This is because network updates involve overwriting files on the user side with files on the server, not synchronizing (mirroring) them.

To remove unnecessary files (that have already been distributed) during a network update, use delete.txt.

The delete.txt file is placed in the top level folder of the contents of the network update (for example, in the case of a ghost, where the ghost folder, shell folder, readme.txt, etc., are located. For other types, it is where descript.txt is located).

For a layout example, please see "Network Updates" in the File Structure section of the menu on the left side of the page.

Create updates2.dau

Next, create a file for network updates (updates2.dau).

This is a mechanism to detect anomalies such as corruption or falsification by checking for differences in file contents between the server side and the client side.

To create updates2.dau in MATERIA or CROW, you need to create an empty text file named updates2.dau in the top directory (for example, where the ghost folder, shell folder, readme.txt, etc., are located for ghosts). You will need to create this file in advance.

In SSP, it is created automatically.

Then start the baseware and drag and drop the folder containing updates2.dau and the files you want to update to the main unit.

Note that in MATERIA and CROW, if install.txt is included in the files, the creation of the nar file is prioritized and updates2.dau will not be created. So, do not include it.

After dragging and dropping the file, a file named updates2.dau should have been created in the folder, and something should be written inside it.

You can open updates2.dau with a regular text editor such as Notepad by right clicking on it, and check the contents that way (you don't have to understand the contents themselves).

Upload to server

Once you have reached this point, all you need to do is upload the files to the sevrer using FTP or other communication software.

However, please note that all files must be uploaded in binary communication mode.

If you upload in ASCII mode, network updates will fail.

For safety, you may wish to leave a "before network update" copy in your baseware and use it to confirm that the network update completes successfully after the upload is complete.

About developer_options.txt

When creating an archive or updates2.dau with SSP, you can set which files should be targetted by creating a file named developer_options.txt at the top level (where install.txt is placed when creating an archive).

See the section on developer_options.txt on the Install/Update Settings page for instructions and examples.

Note that this file only works when creating archives and updates2.dau with SSP, and is not valid when creating them with other baseware, or the Ghost Distribution Automation System described below.

About Ghost Distribution Automation System (GDM)

The Ghost Distribution Automation System (GDM) 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.

Ghost Distribution Automation System

Please also refer to the following site for detailed introduction and setup explanations (the contents of "1" are not necessary).

How to use the Ghost Distribution Automation System (GDM)

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 cases where ".dau" is rejected by the server

Depending on the configuration of your hosting server, it may not handle files with the unfamiliar ".dau" extension.

In such cases, updates.txt can be substituted.

For usage, replace all "updates2.dau" on this page with "updates.txt".