Version, build, and “product” info

MOUL clients have multiple different bits of version info and other metadata compiled into the executable. I’m explaining it here, because some of this information is either sent to the server or indirectly affects how the client behaves.

Most of this information is displayed to the user as the “product string”, which might look like “UruLive.Live.1.918.OpenUru#205 - External.Release” for example. The product string consists of the following parts:

Below is a list of all different kinds of version/build/product metadata, including some bits that aren’t displayed in the product string.

Core name, short name, long name

The name of the game is stored three times, in slightly different formats. Apparently the core name was meant to be an internal identifier and the short and long names for display to the user, but actual usage is all over the place.

None of these names are sent over the network. They have almost no functional effect on the client. A notable exception is that the long name is used as the name of the user data folder (where settings, logs, KI pictures, etc. are stored), so two clients with the same long name will share their settings.

For Cyan MOULa and Minkata clients, as well as default OpenUru and H’uru builds, the core and short names are “UruLive” and the long name is “Uru Live”. Many shards change this — for example, Gehn uses core name “UruGehn” and long name “Uru - Gehn Shard”, and TOC-Moul uses core name “TOC” and long name “The Open Cave”.

Product ID (UUID/GUID)

A UUID/GUID identifying the game. All MOUL shards that I know of use the UUID ea489821-6c35-4bd0-9dae-bb17c585e680. This value is sent to the server during connection setup. It has no other effect on the client.

Build type

Indicates the stage in the release cycle for which the client was built. The open-sourced client code defines the following build types:

  • Dev = 10

  • QA = 20

  • Test = 30

  • Beta = 40

  • Live = 50

Build type Live is typically used for production builds distributed by shards. It is also the default build type for H’uru clients built from source. OpenUru source builds default to build type Dev instead. The other build types are practically unused.

This value is sent to the server during connection setup. For OpenUru clients, each build type uses its own separate user data folder, and build type Dev enables a few extra assertions. For H’uru clients, the build type has no functional effect on the client.

Branch ID

Has always been 1 for most shards, including GameTap MOUL, Cyan’s MOULa, Minkata, and Gehn. OpenUru and H’uru builds also default to branch ID 1. TOC-Moul currently uses branch ID 2.

This value is sent to the server during connection setup. It has no other effect on the client.

Build ID

This is meant to be a build number that is increased with every update. This value is sent to the server during connection setup. Cyan’s server software and DIRTSAND check this value to ensure that the expected client version is used, but MOSS does not.

All updates to Cyan’s MOULa shard since June 2013 have used build number 918, to allow updating the client without also having to rebuild the server every time. (The actual build number is now indicated by the factory ID.) For compatibility, both OpenUru and H’uru clients also use build number 918 by default. Other shards not coupled to Cyan’s MOULa, such as Gehn or TOC-Moul, may use different build numbers that change on updates.

Cyan MOULa build IDs

Note

There are probably some builds missing between 1.866 and 1.897, because during that period Cyan didn’t post detailed update notes on the forum.

Factory ID

Contains the real build number of OpenUru-built clients (for Cyan’s MOULa shard and Minkata), since the main build ID has been fixed at 918. Clients built from the OpenUru codebase won’t have a factory ID by default — this information is patched into the product string by the OpenUru build servers.

H’uru clients don’t have a factory ID, but H’uru’s CMake build inserts the current Git tag or commit hash into the product string, which serves a similar purpose.

This value is not sent over the network and has no other effect on the client.

Internal/external client

MOUL clients can be built as either “Internal” or “External”. Internal clients have a number of extra features over external clients that are not meant for use by normal players, such as increased logging, a developer console, and the ability to use custom data files. For most shards, the pre-built clients distributed to players are external clients.

Note that this setting is independent of the build type — you can build an external client with build type Dev or an internal one with build type Live.

For the most part, if the player doesn’t invoke any internal-only features, internal clients behave like external ones and don’t explicitly tell the server that they are internal. The main exception is when updating through the file server, where internal clients will request different manifests than external clients.

Debug/release build

This corresponds to the standard debug/release setting in Visual Studio and CMake. Clients built in debug mode have many additional assertions and some extra logging enabled (in addition to the standard compiler option changes).

This setting is not sent over the network and should have no visible effect on the client.